LPC822 execution stops suddenly

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC822 execution stops suddenly

363 Views
Elmar
Contributor II

Hi, 

I'm using LPC822 on my 2nd project and I remarked that suddenly the code execution of the MCU stops. It's not predictable but I often find the MCU stopped and an external reset is needed to restart the program execution. 

To remedy to this problem I call NVIC_SystemReset(); after the main loop but it doesn't resolve the problem.

I joined a screenshot of my code that executes a simple i2c code read and the logging of i2c communication externally that indicates the program stuck. Even RTT viewer doesn't receive any new print data.

Will you have any idea or prevention to apply in order to avoid this type of execution stuck?

Thanks.

Labels (1)
0 Kudos
4 Replies

341 Views
carstengroen
Senior Contributor II

What do you expect this to do (specifically, when do you expect the while(1) loop to end) ?

While (1) 
{
xxxxx
xxxxx
}

NVIC_SystemReset();

 

As Frank said, you need to debug. There is no way any can help you with the (lack of) information you have given.

0 Kudos

352 Views
frank_meyer
Senior Contributor II

> I'm using LPC822 on my 2nd project and I remarked that suddenly the code execution of the MCU stops. It's not predictable but I often find the MCU stopped and an external reset is needed to restart the program execution. 

While we can see even less than you, who is supposedly in front of the board, there are some common causes for runtime errors.

In most cases, it is either a stack overflow or an illegal address (no memory or not enable peripheral).

My first recommendation is, try to debug it. When ending up in the hardfault handler (most likely), check the call stack.

If that doesn't help, you can instrument your code, i.e. add log outputs you watch at runtime.

Determining the required stacksize for a project is mostly guesswork, and many toolchains just set an arbitrary default value and leave the rest entirely to the user. Without change, they invariably hardfault at the first try.

0 Kudos

336 Views
Elmar
Contributor II

Thanks for your replies.

Here is the solution that I applied to restart the program and keep running :

 

/**
* @brief	Get stack pointer address
**/
static __inline__ void *sp_get(void)
{
	void *sp;
	__asm__ __volatile__ ("mrs %0, msp" : "=r"(sp));
	return( sp );
}
	
/* Initialize the stack check */
uint32_t initialSPValue = (uint32_t)(sp_get());
	
    while (1)
    {
		
		if (initialSPValue != (uint32_t)(sp_get()))
		{
			/* Cause software reset on stack sanity check error */
			NVIC_SystemReset();
			for(;;)
			{
				; /* Nothing to do here */
			}
		}

...
}

 

 Is there any way to read the variables of scatter file such as Stack_size, ram_addr, etc from the c source code?

Thanks in advance for your feedback.

0 Kudos

320 Views
frank_meyer
Senior Contributor II

> Is there any way to read the variables of scatter file such as Stack_size, ram_addr, etc from the c source code?

No, because this is exactly what you not want. Having such system-dependant settings in the code is the opposite of portability.

These are linker settings. Usually, they are accessible by the project properties. 

> Here is the solution that I applied to restart the program and keep running :

Not a good idea either.

Check where the error happens, and fix the bug. Your method is a customer annoyance - I would not be allowed to take such shortcuts for my projects.

Check out this document : https://www.keil.com/appnotes/files/apnt209.pdf

I still think increasing the stacksize can fix your issue.

I have a Crossworks licence for private projects of mine. This toolchain sets a 256 byte stacksize by default. Any moderate complex code or semihosting output ends up in a hardfault hander with this setting.

0 Kudos