Hi,
I have a problem with the SVC_Handler for iMXRT1062 that I have written in assembler. It works perfectly through the debugger, but steps off to 0xdeadbeee (deadbeef with thumb bit dropped). I realise that the Thumb-mode test is probably unnecessary as the processor only operates in Thumb-mode.
.func SVC_Handler SVC_Handler: // This call follows the ARM Architecture Procedure Calling Standard (AAPCS) // which pushes the following onto the stack from the calling function. // {r0-r3}, r12, LR, PC, xPSR // The LR currently set is the EXC_RETURN value which will cause the stack to // be unwound and the registers set to the initial values. .syntax unified MOV r1, sp // stack contains r0, r1, r2, r3 which are used as function arguments LDR r3, [r1, #0x18] // excavate pc from stack MRS r2, psr // Get psr so we can check ASM state TST r2, #T_bit // Occurred in Thumb state? ITTEE EQ LDRHEQ r0, [r3,#-2] // Yes: Load halfword and... BICEQ r0, r0, #0xFF00 // ...extract comment field LDRNE r0, [r3,#-4] // No: Load word and... BICNE r0, r0, #0xFF000000 // ...extract comment field STMFD sp!, {LR} // push LR onto stack before call BL SVC_Handler_C // Call main part of handler LDMIA sp!, {LR} // retrieve LR from stack // Set PC to LR (which contains EXC_RETURN value), which will unwind the // stack and restore the registers BX LR .syntax divided .endfunc
This suggests that there is something else going on at the same time, but only one thread should be running. Please can you suggest how I can find out what is causing this problem and resolve it?
thanks
dan
Hi Sabina,
thanks for your reply.
I'm actually using our own board,but building it using the SDK_MIMXRT1060. We are using FreeRTOS as a library.
What is the best way of sending this to you?
thanks
dan
If it is possible for you to share on this post. Please attach it to the post. If not, please let me know so that I can provide further instructions.
Best Regards,
Sabina
Hello Dan,
Hope you are doing well.
I want to make sure that what I am seeing on my end is correct. It doesn't match your last comment that it calls a hard fault handler. Actually as soon as I press the debug it goes to the stuck status as shown below:
It does not stop at the main this is immediately after pressing the blue debug icon. Is this expected?
I see that in your project your debug configuration is for jlink. Can you please tell me which jlink debugger you are using so that i can do exactly as you are doing.
Best Regards,
Sabina
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Sabina,
I am using a Segger J-Link plus v 10.1.
I get an automatic temporary break point in main.
And if I step through, I get output on the serial line, but when I step over the PRINTF I get sent to hard fault.
thanks for your help.
Dan
Hope you are well. Thank you for providing the screenshots. I unfortunately was not able to reproduce this from my end, it is not stopping at the main function to be able to step through.
Please review this next document and verify point by point the recommendations provided.
https://community.nxp.com/thread/306244
I will continue to try to reproduce it with the code you have provided. If you come across any new information with the document please let me know.
Best Regards,
Sabina
Hi Sabina,
There are obviously some differences between our environments.
Please can you send me the binary that you have generated so I can see if it runs on my setup.
Please can you tell me which version of the SDK and MCUXpresso you are using? I am using MCUXpressoIDE_11.1.0_3209 with SDK_2.8.0_EVK-MIMXRT1060 (366 2020-07-21) and I also have MCUXpressoIDE_11.2.0_4120 with SDK_2.8.0_EVK-MIMXRT1060 (366 2020-07-21)
Also what board are you running this on. Is it the MiMXRT1060 EVK?
Thanks
Dan
Hello Dan,
In order for me to send the binary I will have to create an internal case. I will send you an email through the one provided for this case. The support will continue through the internal platform.
Best Regards,
Sabina
Hi Sabina,
I am unpacking some of the fault registers. CFSR = 0x00020000 which I think is the UFSR INVPC bit.
This suggests that there is a problem with the EXC_RETURN being set. When the HARD_FAULT Handler is hit,
LR is either 0xFFFFFFF1, or 0xFFFFFFE9. If it is 0xFFFFFFF1, then it suggests that an exception has been called within an exception.
In the attached screenshot, the PC value of 0xFFFFFFFF is concerning.
SCB->SHCSR = 0x00010080 Which is MEMFAUTLTENA(0x00010000) and SVCCALLACT (0x00000080).
SCB->ICSR = 0xe000ed00 Which is NMIPENDSET (0x80000000), Reserved 2 bits (0x60000000), VECTPENDING (0x0000e000) = 14 PendSV, RETTOBASE (0x00000800), Reserved 2 bits (0x00000400), VECTACTIVE (0x00000100)
Thanks
Dan
Hello Dan,
Hope you are doing well.
Is it possible for you to share a small example project leading to this behavior on the evaluation board. I'd like to check this from my end with detail as to what may be causing the fault.
Best Regards,
Sabina
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------