2017-05-30 06:52 PM
Hello.
I seem to have a hardfault exception problem and it doesn't make sense to me.
I am using ThreadX and it has to do with how long it takes to startup.
So here is my startup code:
/* Enable I-Cache-------------------------------------------------------------*/
SCB_InvalidateICache(); SCB_DisableICache(); SCB_EnableICache();/* Enable D-Cache-------------------------------------------------------------*/
SCB_InvalidateDCache(); SCB_DisableDCache(); // SCB_EnableDCache();// enable Usage-, Bus-, and MMU Fault
SCB->SHCSR |= SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk;platform_init_system_clocks();
platform_init_mcu_infrastructure();my_wiced_init(); // setup wiced uart callbacks, MUST be before platform_init_external_devices() platform_init_external_devices(); // inits gpio and serial /* Initialize all configured peripherals */ LocoGPIOInit(); MX_QUADSPI_Init(); nvram_init();/* Enter the ThreadX kernel */
tx_kernel_enter(); // next routine will be WicedAppThreadMain()while (1)
{}
This code has been working great until I added more code in the
platform_init_mcu_infrastructure(). I spend a little more time in there doing some setup for a power saving feature that I'm implementing.
I think one of the timers is firing off (there is a HAL_InitTick(TICK_INT_PRIORITY))
stm32f7xx_hal_conf.h has TICK_INT_PRIORITY defined as ((uint32_t) 0U)
The error I'm getting is a SCB->CFSR & SCB_CFSR_UNALIGNED is set. Now I'm not sure why that bit is set because if I step through the assembly I see that there is a bad reference in the tx_timer_experation_process. Which makes sense because it hasn't been setup yet.
However, this just may be a red herring.
I have seen lots of posts about unaligned data and the like but I really think it is the timer. I just don't know how to find out exactly.
Any pointers?
Thanks in advance.
-stv
#hardfault #stm32f77x #threadxSolved! Go to Solution.
2017-06-26 10:49 AM
This problem was solved. The issue was that there was a timer that my client started up early on in main.c that 'acted' as a systick.
Then when the RTOS (ThreadX) started the SysTick handler, it did that before the OS was ready and it would crash the second that SysTick would fire off.
I fixed it by putting a global in the SysTick IRQ Handler that would get cleared after the RTOS was ready.
2017-06-26 10:49 AM
This problem was solved. The issue was that there was a timer that my client started up early on in main.c that 'acted' as a systick.
Then when the RTOS (ThreadX) started the SysTick handler, it did that before the OS was ready and it would crash the second that SysTick would fire off.
I fixed it by putting a global in the SysTick IRQ Handler that would get cleared after the RTOS was ready.