STM32F072RB systick not firing

[michael239955]

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?

[Pavel A.]

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

-- pa

[Pavel A.]

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

[Tesla DeLorean]

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.

[michael239955]

​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. 

[michael239955]

​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.]

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

-- pa

[michael239955]

​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

[michael239955]

​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.