I'm road testing the Ultra-Low Power Arm Cortex-M4 Darwin MCU EVM. During my tests I had difficulties with the FreeRTOS example that comes with the SDK. It showcases tickless operation, and that does not work for me. The example doesn't wake up after enabling tickless mode. It's supposed to wake up when clicking the user button.
|
Let's Get it Working First
Out of the box, this example has a few errors. Let's get it working first.
You can tell the example to go into tickless mode. This is a mode that puts the controller in a sleep with a vastly reduced clock.
The way to put it in tickless is by sending it a command via telnet (tickless 1).
The controller is expected to wake up when you press the user button on the evaluation kit. But it doesn't.
I raised a support case with MAXIM.
That case was closed after 4 weeks (two weeks factory close for new year included). Without a resolution. I did not have the impression that the support analyst analysed it.
edit: As you can see in the comments below, the issue was a code issue in the example.
The MAXIM FreeRTOS port is ok, but the example is wrong in a few places. I think it's ported from another board and not adapted to the actual hardware on the evaluation kits.
An analyst familiar with the device would have found it.
See the comments below for the progress and resolution.
What Does this Example Show?
It's a fine RTOS showcase that has a few competing threads, a slow runner, and a task that gets woken up by an interrupt on the UART.
The two competing ones are two led flash task. They show very simply how to reserve resources using mutexes.
Then there's a slower task that reports the uptime and some settings.
And there's also an interesting command line interpreter test. The interpreter is part of FreeRTOS+.
It's worth looking at the tickless demo part of the example.
When you submit tickless 1 to the command line interpreter, it allows the controller to go in a lower power mode.
All the time, FreeRTOS keeps managing resources and scheduling tasks. But as soon as it knows it has enough idle time ahead, it sets a timer interrupt and goes to sleep until that idle time finishes.
(the scheduler has enough info to know when a next task has to be activated. And the firmware has the option to decline the permission to sleep when it's doing something that needs the controller active.)
There's a GPIO interrupt handler that waits for you to push the user button. Thta interrupt works in the low power mode. It switches the application back to active.
When you test the application, you'll see that the LED tasks keep running, and the task that reports the uptime over UART runs too.
The UART listener, however, and the FreeRTOS+ command interpreter, are inactive.
How Can You Debug?
Applications with sleep modes are hard to debug. That's a fact of life with embedded development.
You can temporary configure FreeRTOS and your app not to go in these modes.
For that, you take care that, in the application specific FeeRTOSconfig.h file, you define configUSE_TICKLESS_IDLE to 0.
#define configUSE_TICKLESS_IDLE 0
The controller will stay awake and you can debug your firmware.
Don't forget to reset this define later if you want to take advantage of the various power saving schemes of FreeRTOS.
Top Comments
-
DAB
-
Cancel
-
Vote Up
+2
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
-
Jan Cumps
in reply to DAB
-
Cancel
-
Vote Up
+1
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Comment-
Jan Cumps
in reply to DAB
-
Cancel
-
Vote Up
+1
Vote Down
-
-
Sign in to reply
-
More
-
Cancel
Children