Skip to main content
SBona.2
Associate
April 13, 2020
Solved

Using SysTick causes reset?

  • April 13, 2020
  • 3 replies
  • 3394 views

UPDATE: The issue has been solved. The nBFB2 option bit had to be enabled.

Hello, I am currently programming and STM32L152RE on a Nucleo development board. I am using SysTick as a .5s timer that ran a status LED. Everything was working up until recently when I noticed the LED stopped working, and the processor seemed to be restarting. Stepping through with a debugger showed it was able to run all the setup code correctly, but when I let it run to get to the SysTick_Handler(), it would instead go to the reset handler. I also verified it is caused by SysTick as the code does not crash when I do not use it. I also checked the RCC_CR register after the reset to determine the cause, and only the PORRSTF and PINRSTF bits are set, which didn't help me. Here is the code:

int main(void)
{
	clk_init();
	statusLedInit();
 // Turn status LED on
	GPIOA->ODR |= GPIO_ODR_ODR_5;
	usartInit();
	SysTick_Config(SYS_TCK_RELOAD_VAL);
	int val = 0;
	printStr("Hello World!\n");
	while (1)
	{
		val += 1;
	}
}
 
void clk_init()
{
	// Turn the HSI on
	RCC->CR |= RCC_CR_HSION;
	// Wait for it to be stabalized
	while ((RCC->CR & RCC_CR_HSIRDY) == 0)
		;
	// Set HSI to the sys clock
	RCC->CFGR = (RCC->CFGR & ~(RCC_CFGR_SW_Msk)) | 0x1;
	// If it was succesful, clock should now be HSI
	while ((RCC->CFGR & RCC_CFGR_SWS_Msk) == 0x1)
		;
	// Turn the MSI off
	RCC->CR &= ~RCC_CR_MSION;
}

I can include usartInit() and statusLedInit() if needed, but given it crashes regardless if they are there they don't seem relevant. I've also tried erasing the chip and reprogramming, but that did not work either. Thanks for any help.

This topic has been closed for replies.
Best answer by waclawek.jan

> It is still going to the bootloader

it's probably not sure to your code, but hardware (BOOT0 pin) or option bits settings. Look into AN2606.

JW

3 replies

berendi
Principal
April 13, 2020

What is in SysTick_Handler() ?

If you set a breakpoint on SysTick_Handler(), is it reached, or crashes before that?

Where does the stack pointer point to?

Compare the value of the SysTick vector at flash address 0x0800003C with the actual address of SysTick_Handler in the map file.

SBona.2
SBona.2Author
Associate
April 14, 2020

Here is what's inside systick handler:

void SysTick_Handler()
{
	counterVal += 1;
	GPIOA->ODR ^= GPIO_ODR_ODR_5;
}

If I set a break point on it, it does not reach it.

The stack pointer is at the top of my stack on the reset.

Here is the map file, and it appears the handler is at 0x0800028c:

0693W000000VkRoQAK.png

Could this be the issue?

waclawek.jan
Super User
April 14, 2020

> The stack pointer is at the top of my stack on the reset.

What's its value?

> the handler is at 0x0800028c:

Okay, and how does the vector table (starting at 0x0800'0000) look like in disasm?

JW

SBona.2
SBona.2Author
Associate
April 14, 2020

Actually I must've misread the stack pointer, it is nowhere near the top of the stack. It's at 0x20000f38, and the top of stack is 0x20004ffc. Which is odd considering all I'm doing before the systick exception is called is incrementing a value and printing text. I also noticed the LR is all F's, which is odd. I'm not sure of a circumstance that would happen. Here's a screenshot:

0693W000000VkuvQAC.png

The vector table looks like this (note the address of SysTick_Handler is different because I changed some other code a bit:0693W000000Vkv0QAC.png

The vector table has 0x0800028d, and the address of SysTick is 0x0800028c. 0x28d seems reasonable considering I'm compiling with thumb, which does 16-bit instructions if I remember correctly.

berendi
Principal
April 14, 2020

PC=0x1FF00348 means that it is executing the ROM bootloader, not your program. This explains the odd SP value, according to AN2606 the ROM uses the first 4K of the internal SRAM, i.e. 0x20000000 to 0x20000FFF. The question is of course why did it enter the ROM bootloader?

> the top of stack is 0x20004ffc

The MCU has 80k of RAM, 0x20000000 to 0x20013FFF. Are you using some custom memory layout?

All fault handlers except Reset and Systick are empty in the vector table, why?

Lots of unusual stuff. What kind of toolchain is that? Where does your startup code and vector table come from?

waclawek.jan
waclawek.janBest answer
Super User
April 15, 2020

> It is still going to the bootloader

it's probably not sure to your code, but hardware (BOOT0 pin) or option bits settings. Look into AN2606.

JW

SBona.2
SBona.2Author
Associate
April 15, 2020

Yup it was one of the option bytes! I had to enable the nBFB2 option and now its working. Thanks for the help!