We implemented a full peripheral power management system, so we disable and enable devices multiple times and we also use a the usb use task feature. doing that we might have an unexpected behavior with the freertos heap allocation since deinit usb stack will destroy the internal msg queue and create it again and again. with the other devices we separated the memory resources from the rest so we allocate memory only one at the init time but in case of usb stack the sdk is responsible for allocating and destroying the queues.
The solution:
would be an external (from sdk) provided queue when calling the init code just like the usb use task macro.
A macro that envelops the create and destroy queue and when used we don't destroy the queue in runtime to keep the same queue all the time (I have already tested it and I can eventually submit a merge request if you want).
We implemented a full peripheral power management system, so we disable and enable devices multiple times and we also use a the usb use task feature. doing that we might have an unexpected behavior with the freertos heap allocation since deinit usb stack will destroy the internal msg queue and create it again and again. with the other devices we separated the memory resources from the rest so we allocate memory only one at the init time but in case of usb stack the sdk is responsible for allocating and destroying the queues.
The solution:
Thank you.