FreeRTOS & Sleep modes

Hello Matthew,

I have forwarded your question to one of our experts and they will respond soon.

Hi Mat,

Could you send us the sample code/project?

Hi Prathap,

I've attached the CCS project to my files area - can you access here? Apologies, its a bit big - but does include both the CCS project and HALCoGen setup files.

Mat

Sorry Mat, I Could not find the attachment.
Zip your Folder, Choose Insert File, Browse for your Zip and Insert. before posting.

ok, sorry about that, attached it into my profile, not this message.

I've just thrashed together a smaller project to demonstrate the problem. I'm running with custom hardware, but it should work fine on a dev board too (alas, I can't find ours). The application simply does:

1. initialises HALCoGen routines

2. creates a FreeRTOS task which:. toggles an LED, prints to the UART, sleeps for a second.

3. starts the scheduler

As I've just discovered, the problem isn't actually that the processor remains asleep, but rather putting it to sleep seems to kill the UART forever more - wierd!

4466.TargetWithUART.zip

Any ideas whats happening to the UART after the sleeps gone? I would much prefer not to run the UART off VCLK, but there doesn't seem to be an option.

Mat

Hi Mat,

( I editted the Post , Sorry I made a mistake earlier. )

In Any low Power mode Sleep/Doze/Snooze VCLK domain is disabled.
Once you wake up ( I am assuming you are using RTI Interrupt as Wakeup) WakeUp clock source you configured kick's in, make sure PLL is choosen as clock souce, otherwise dafault OSC will be clock source and VCLK will be based on Oscillator which will messup your SCI baud rate configuration. Refer GHVSRC register ( configurations are done using GCM tab in HALCoGen)

I think following are your option
1) To Enter Low power mode call systemPowerDown(0x000F3F00)  --> This make PLL clock Active the whole Time. If you want PLL to be disabled to save power, enabling back will need lock up time.

Thanks for the suggestions Prathap, unfortunately they didn't work.

I am using the RTI for wakeup, which is embedded into the FreeRTOS TIck call (so not easily accessible).

Option 1 doesn't have any affect on what I'm seeing: things still fail to recover.

Option 2 exhibits a new problem. Because FreeRTOS has tied the RTI interrupt for its Tick routine, I enabled access to vApplicationTickHook(void) within HalCoGen and put the recovery in there. Unfortunately enabling this routine seems to screw up FreeRTOS and puts it into a recursive prvIdleTask() loop, never to return. This is a seperate bug within the HalCoGen FreeRTOS port which I've encountered before.

Hi Mat,

I did the changes which I mentioned ( sys_main.c and system.c) in the project you attached in earlier post.
Try replacing this file in the project and try. Attachment -->
2630.sys_main.c

4162.system.c

I made PLL as clock surce for RTI ( This can be done using GCM Tab in HALCoGen GUI ) and I kept PLL alive just to avoid PLL lock time. File Diff will give you details!

Hi Prathap,

I'll give these changes a whirl in the morning. However, I'm not sure this is really the solution: keeping the PLL running kind of invalidates the point of putting the device to sleep in the first place.

I agree it's better than nothing, but I really need to reach a point whereby I can put it into deep sleep during idle periods. This is actually to do with decreasing failure probabilities, rather than strictly power saving. We're going to subject the device to a very harsh environment, whereby single-event effects will impact active junctions. Hence, by lowering the number of active components, reduces the probability of failure substantially!

Hi Mat,

As I understand you chose to put the part into "Doze" mode, which keeps the main oscillator active and allows you to source the RTICLK1 domain with this oscillator clock.

Once a wake up condition is detected, each clock domain on the part becomes active automatically. The clock source to be used by each domain needs to be programmed before entering the selected low-power mode. The GCLK, HCLK and VCLK sources can be selected using the "GHVWAKE" field of the GHVSRC register.

For entry into doze mode, it is recommended to select the main oscillator as the source for the GHV clock domains after wake up.

Regards, Sunil

Thanks Guys, notes so far:

1). Keeping the PPL active at all times does allow recovery to normal operation. Hence, this solution works, it's just not very power efficient.

2). Selecting the OSC for wakeup does allow the CPU to wake up again, however its on an extreme go-slow: my 1sec LED toggle is nearer 4seconds now. This makes sense as I'm not actually switching back to the PLL at any point: mostly because I don't have the hooks to know when the core has become active again.

I think it's fair to say I now understand the problem. Ultimately, putting the device to sleep through FreeRTOS is easy due to the idle hook. However, waking it up afterwards is lacking the hook to put the wakeup code in. I don't suppose you could have a look into the vApplicationTickHook() HALCoGen implementation problem (although I admit this is probably a different ticket!)?

Thanks for your help!

Mat