Changing Run / Power modes when using FreeRTOS

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Changing Run / Power modes when using FreeRTOS

Jump to solution
561 Views
roger5
Contributor III

I'm experiencing some strange problems while changing Run / Power modes whilst using FreeRTOS

The firmware needs to operate at 2 different speeds.

When receiving and decoding data, it functions fine with clock speeds as low as 40Mhz, but when encoding and transmitting data, the audio encoder takes a long time to process the signal and I need to increase the clock speed / Run mode to around 96Mhz.

 

However, I have a strange problem where when I change clock speeds / run modes, from 40Mhz to 96Mhz the RTOS seems to hang for enough time to cause the input buffer to overflow.

Strangely if I lower the clock speed when in receive mode, to 32Mhz, I can switch to 96Mhz without any delay in the RTOS.

When changing Run mode and clock speeds, I've tried updating the RTOS timer interrupt to use the new clock speed by calling  vPortSetupTimerInterrupt() 

But this doesn't seem to make any difference.

 

Is there something else i should be doing when changing clock speeds to ensure that the RTOS does not hang for a while?

0 Kudos
1 Solution
532 Views
roger5
Contributor III

Sorry Daniel

 

I thought I'd replied to all the issues I'd opened, saying they had now been resolved.

The problem was a coding bug, associated with a variable referenced by the Notification struct, which was declared as a local variable in a function, but the Notification struct was in global memory, and the local variable had gone out of scope and been overwritten.

The code has now been fixed

 

BTW.

I'm not using a development board, I'm using some hardware from a company in China which uses the MK22 as the main processor

 

Please can you close this thread as resolved.

View solution in original post

2 Replies
533 Views
roger5
Contributor III

Sorry Daniel

 

I thought I'd replied to all the issues I'd opened, saying they had now been resolved.

The problem was a coding bug, associated with a variable referenced by the Notification struct, which was declared as a local variable in a function, but the Notification struct was in global memory, and the local variable had gone out of scope and been overwritten.

The code has now been fixed

 

BTW.

I'm not using a development board, I'm using some hardware from a company in China which uses the MK22 as the main processor

 

Please can you close this thread as resolved.

538 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Roger:

Could you please let me know the hardware you are using and how to reproduce your issue on the EVK board?

 

Regards

Daniel

0 Kudos