You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using cmsis_rtos_v2 or v1 implementation generated from STM32CubeMX execution asserts on "obtained from hardware parameter. I can't understand what causes this but it is certainly incorrect and manual variable modification helps this code to pass. This code works on real bluepill stm32.
File: port.c from cmsis_rtos_v2
#ifdefconfigPRIO_BITS
{
/* Check the FreeRTOS configuration that defines the number of priority bits matches the number of priority bits actually queried from the hardware. */ulMaxPRIGROUPValue=3; // qemu is broken here. was 4294967295configASSERT( ( portMAX_PRIGROUP_BITS-ulMaxPRIGROUPValue ) ==configPRIO_BITS );
}
#endif
I assume that ulMaxPRIGROUPValue is incorrect. Due to an error in NVIC register values.
This one probably
Hello @AleksandrVin, thank you for reporting this issue and providing details.
At the moment, I am not set up to troubleshoot this, and probably will not be able to help. Best of luck, and if you have any additional details, please feel free to post and/or submit a patch to fix the issue.
Thank you, and sorry I am not of more help.
When using cmsis_rtos_v2 or v1 implementation generated from STM32CubeMX execution asserts on "obtained from hardware parameter. I can't understand what causes this but it is certainly incorrect and manual variable modification helps this code to pass. This code works on real bluepill stm32.
File: port.c from cmsis_rtos_v2
I assume that ulMaxPRIGROUPValue is incorrect. Due to an error in NVIC register values.
This one probably
The text was updated successfully, but these errors were encountered: