cancel
Showing results for 
Search instead for 
Did you mean: 

Hardfault Exception Debugging

Kim.Andy
Associate III

The Hardfault Exception sometimes occurs during system operation.

The register and stack values are as follows after the hardfault exception occurrence.

0693W00000WKbAkQAL.pngThe MSP 0x20003780 points to the stack area storing the register information(LR, PC etc) at the moment of the hardfault .

0693W00000WKbB4QAL.pngAccording to the above stack informations, the LR is 0x080085CD and PC is 0x04020000.

The Address 0x04020000 is not code area. ==> Hardfault Exception Occurrence.

The code of the LR 0x080085CD is as follows.

0693W00000WKbIjQAL.pngDid the hardfault occur as the instruction "POP {r4-r5, pc}" is executed?

The stack area of the above SP 0x2000377C is as follows.0693W00000WKbLJQA1.pngI guess that the 'pc' value of the POP instruction​ would be overwritted to '0x04020000'.

How can I solve this problem?(Why does the hardfault occur?)

Is it possible to set the breakpoint when the memory 0x20003784 is written to the value '0x04020000'?

5 REPLIES 5
FBL
ST Employee

Hello @AK.12.26im​,

> Could you please specify the application use case?

If measuring current for example in stop mode in STM32L0 product, please note that cortex M0+ is not clocked during low power mode. So, by default, debugging features are disabled and you cannot use debug mode.

> Have you configured DBG_CR register?

If not, please check section 32.9.1 Debug support for low-power modes in RM0376

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Kim.Andy
Associate III

Hello Belaid,

The application of our system is the LoraWAN's Sensor Node using CMWX1ZZABZ Lora Module.

The hardfault exception sometimes occurs during normal operation.

I don't any measuring nor using debug mode when the hardfault occurs.

I have checked the hardfault occurrence by uart(vcom) debug message.

I now checked that the hardfault exception occurs in the process of the Stop Mode(LPM).

(Always in the process of returning after executing the LPM_EnterStopMode())

You can check it in my first question message.

Thanks

I might look at what other interrupts might be firing as starts back up, that might have high stack usage, or expectation on pointers, instances, or other hardware.

Look at what Hardware or Peripherals are spun up as LPM_ExitStopMode() prepares to leave, and interrupts that enable or generate.

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

Hello Belaid,

I checked that the hardfault exception occurs during system operation by the debug message(uart port) like the following code.

void HardFault_Handler(void)
{
	PRINTF("HardFault Checked Reboot Device\r\n");
 
	while (1)
	{
		__NOP();
	}
}

I guess that this hardfault occurs at the moment of 'Stop mode Enter/Exit' process because the Link Register points to the memory address(0x080085CD) where the LPM_EnterStopMode() returns.

Please refer to the explanation in my first question above.

And I checked that the hardfault doesn't occur when the functions related to StopMode is commented like the followings.(Case 1 or Case 2)

<< Case 1>>

  • LPM_EnterLowPower() is commented
if((LoraMacProcessRequest != LORA_SET) && (AppProcessRequest != LORA_SET))
{
	#ifndef LOW_POWER_DISABLE
//	LPM_EnterLowPower();
	#endif
}

<<Case 2>>

  • LPM_EnterStopMode() and LPM_ExitStopMode() is commented.
void LPM_EnterLowPower(void)
{
	if( StopModeDisable )
	{
		/**
		* SLEEP mode is required
		*/
		LPM_EnterSleepMode();
		LPM_ExitSleepMode();
	}
	else
	{ 
		if( OffModeDisable )
		{
			/**
			* STOP mode is required
			*/
//			LPM_EnterStopMode();
//			LPM_ExitStopMode();
		}
		else
		{
			/**
			* OFF mode is required
			*/
			LPM_EnterOffMode();
			LPM_ExitOffMode();
		}
	}
 
	return;
}

How can I debug this problem in this case?

If it has unusable return values on the stack your task is the figure out why. Figure out which functions and interrupt get called as it restarts.​

This is where trace would be helpful, but instrumentation via characters to UART or GPIO signaling may be necessary to understand the flow.

Start by identifying all active interrupt that might awaken, or occur once it wakes.

Use ingenuity..​

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