cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F072RB systick not firing

michael239955
Associate III

I have an application running on an stm23F0-discovery the code is quite simple:

HAL_Init();

SystemClock_Config()

while(1);

The code is  built and debugged using IAR workbench 7.5

The discovery clock config uses the internal HSI 8mHZ clock source. I have a break point set in stm32f0xx_it.c at SysTick_Handler(). The break point get hit every ms as expected.

Move this code to our target board which is running the same exact micro and the SysTick_Handler never gets called. This really messes things up as you can imagine because Hal_delay() just hangs. Further experiments with Timer3 yields the same result. Timer3 fires on the dev kit but not on our target hardware.

any thoughts?

8 REPLIES 8
Pavel A.
Evangelist III

Debug, Maybe on the target board some error occurs and the MCU is spinning in an error handler.

-- pa

Pavel A.
Evangelist III

To help locating such errors by the cal stack, disable optimization. Else, smartass compiler knows that while(1) never returns, so it replaces call to the error handler functions with a jump, thus the return address is not available in the debugger call stack view.

-- pa

Make sure BOOT0 is pulled LOW

Check the memory visible at 0x00000000, make sure it is your Vector Table

Remember the CM0 parts do not provide a SCB->VTOR register to relocate the vector table.

SYSCFG can map the base of RAM, ROM or FLASH to zero.

Tips, buy me a coffee, or three.. PayPal Venmo Up vote any posts that you find helpful, it shows what's working..

​I have no optimization. The crazy thing is I can single step through code no problem, just no interrupt processing. Very perplexing to say the least. 

​Hi Clive, yep BOOT0 is low and NRST is high. SCB->ISCR->ISRPENDING = 1, SCB->ICSR->PENDST = 1, SCB->ICSR->VECTPENDING = 0x0f. Looks like the M0 core knows about the sysTick needing to be processed for what ever reason the Cortex core just will not execute the ISR. Crazy stuff, I can single step code no problem just no interrupt processing.

Pavel A.
Evangelist III

So: when you single step, are you in your while(1) loop? or in some error handler while(1) loop?

-- pa

michael239955
Associate III

​Solution found. As it turns out we had some noise on the NRST line during power-up that was causing issues. Just by chance I was able to capture said noise on an oscilloscope. That noise has been corrected and all is good in the world. Thanks to all

​PA,

While I was experiencing this issue I was able to single step through the "super loop" we have in main.c. Function calls, I2C reads/write, SPI..... everything worked as expected just no interrupt handling of any kind. That was what the puzzling part. I was expecting the debug environment to stop or restart if the NRST line went or was low.