Debugging crashes at the middle of the program

[Radoslav Mar]

Posted on June 21, 2018 at 10:35

Hi All. 

I am using:

IDE: System  Workbench

Board: Nucleo L476RG

MCU: STM32F031G6U6

At first debugging starts without any issues. But then at some point in the program I get the error 

No source available for '0x1fffedba' 

I made a demo video to explain the problem better.: 

https://youtu.be/4edkXAFxYt0

[T J]

Posted on June 21, 2018 at 12:17

is the chip getting hot ?

can you hold your finger on ?

Start from cold, see how long it takes to get hot.

on my desk the F091 is reporting an internal temp of 37.7C, slightly warm to touch.

do you have cache turned on ?

is it a custom board ?

you could check the voltage on Vdda/Vdd/Vss pins, see if it is stable and fairly noiseless.

is Boot0 floating ? and NRST ?

[Tesla DeLorean]

Posted on June 21, 2018 at 13:30

Stack overflows or gets trashed and jumps into ROM?

[Radoslav Mar]

Posted on June 21, 2018 at 16:50

Thank you guys for reponding.

I troubleshooted the problem and discovered that when I comment one line, the MCU works just fine.

This is the code:

SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |

                                   /*SysTick_CTRL_TICKINT_Msk |*/

                                   SysTick_CTRL_ENABLE_Msk; /* Enable SysTick IRQ and SysTick Timer */

If I remove the comment from the line in bold, the micro hangs again just as in the video.

The original code is like this:

SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk |

                                      SysTick_CTRL_TICKINT_Msk |

                                      SysTick_CTRL_ENABLE_Msk; /* Enable SysTick IRQ and SysTick Timer */

The 

SysTick_CTRL_TICKINT_Msk 

is Bit-1 

SysTick Control and Status register. 

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0662b/Babieigh.html

.

I suppose that there is a missing function that handles the interrupt request.

So I defined SysTick_Handler  and now the code look like  this:

#include 'stm32f031x6.h'

#include 'main.h'

#include 'stm32f0xx_hal.h'

void SystemClock_Config(void);

static void MX_GPIO_Init(void);

volatile uint32_t vect = 0;

void SysTick_Handler(void)

{

HAL_IncTick();

vect++;

}

int main(void) {

HAL_Init();

MX_GPIO_Init();

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);

while(1)

{

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET);

}

/* Configure the system clock */

}

static void MX_GPIO_Init(void)

{

GPIO_InitTypeDef GPIO_InitStruct;

/* GPIO Ports Clock Enable */

__HAL_RCC_GPIOA_CLK_ENABLE();

/*Configure GPIO pin Output Level */

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_8, GPIO_PIN_RESET);

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET);

/*Configure GPIO pins : PA4 PA8 */

GPIO_InitStruct.Pin = GPIO_PIN_8 | GPIO_PIN_4;

GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;

GPIO_InitStruct.Pull = GPIO_NOPULL;

GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

}

But still the same error.

[Tesla DeLorean]

Posted on June 21, 2018 at 16:55

Suggests you're missing the handler, or linkage to the one in the vector table.

void SysTick_Handler(void)

{

}

Or calling it causes the stack depth to be exceeded due to stacking context, or call tree below the handler and callbacks.

[Radoslav Mar]

Posted on June 21, 2018 at 17:11

Please see the comment above I edited it. It is basically impossible to have a stack overflow. It may not be linked, but how would I know?

[Tesla DeLorean]

Posted on June 21, 2018 at 17:21

You could probably look at the .MAP or .LST listing file, or generate a disassembly?

Going to be expecting the Vector Table to be at 0x08000000, and one of the entries is going to be pointing to the handler.

Dump the 32-bit words at 0x08000000, and SysTick should be at 0x0800003C as I recall.

[Radoslav Mar]

Posted on June 22, 2018 at 10:16

Looking at the Reference Manual I see that the vector table for this chip starts from 0x00000000.

Then I checked the values of these addresses and saw nothing like 0x0800 ....

This is the debuggers view of these addresses:

It seems to me that the the vector table is nit initialized at all.