Deadlock reboot - System Reset Problem

[Skira.17]

Hi ST community,

In my project I have created a task to post Data to AWC server.

the function call stack looks like below:

stack size is 70*12 words

AWC_Task()

{ GPRS_SetConnection() // establish connection

 PH2_exeAWCcmnds()

}

PH2_exeAWCcmnds() // executed but not returned due to deadlock

{

 ExecCommand() // below all functions are executing and able to POST data but after posting data I am getting System reset at this point(at the end ).

}

ExecCommand() //executed and returned

{

 PH2_SerialiseAckPostJson()

}

PH2_SerialiseAckToJson() //executed and returned

{

// allocating global buffer using malloc

PI_postCommandExec()

PI_postCommandExec()

free()//releasing malloc buffer

}

PI_postCommandExec() //executed and returned

{ 

GPRS_POSTdataInit()

GPRS_POSTdataChunk() //set the awc url settings to post data

if(possting of datachunk success)

GPRS_POSTdataTerm() //termoinate 

}

NOTE: Above function calls shows longest possible function call chain.

I have checked for Stack over flow(might be cause of Deadlock) for AWC_Task using the follow methods:

-> vApplicationStackOverflowHook function - as this functio is not executed, then there is no stack overflow

-> Increased stack size from 70*10 words to 70*12 - the deadlock problem not solved

-> uxTaskGetStackHighWaterMark() - at start i got 804 words free space(at start of AWC_Task Function) and  

when i printed the remaining stack size i got 602 words. 

I think the deadlock may not be due to Stack overflow.

I want to know what might be the other causes for deadlock?

Thank you,

Regards,

Sai Kiran

[Tesla DeLorean]

Use a debugger, determine where it is stuck.

Instrument the HardFault_Handler and Error_Handler so you can identify.

Instrument the code generally so you can pinpoint area of failure, and flow within the application.

Check areas where you have infinite loops, that timeouts are working, and there aren't any priority inversions, or issues with code being in interrupt or callback context, and then blocking.

Use volatile variables where appropriate.

[Skira.17]

Hi clive1, Thank you for your response.

I have instrumented the Hardfault_Handler by using a printout statement in it. The cause of the problem is Hardfault_Handler. It is occuring exactly at the return statement in PH2_exeAWCcmnds() function. I think now I can ruleout that the reset is not due to any watchdogs as it is due to hardfault interrupt. How can I trace the reason for the cause of hardfault interrupt?

[Tesla DeLorean]

Suggested routines I posted here

https://community.st.com/s/question/0D50X0000Az372YSQQ/stm32l412-hardfault-while-using-minimal-cubeide-example

You want to look at the registers with respect to the assembler code at or immediately prior to the fault.

Once you understand that code, match it to the C code, and pointers/structures in play.

If the failure point is consistent it is often related to memory corruption, issues with local/auto variables, or instances not properly initialized.