Handling SVC generates fault

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Handling SVC generates fault

1,870 Views
dansmithers
Contributor III

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

Labels (1)
Tags (2)
0 Kudos
10 Replies

1,695 Views
dansmithers
Contributor III

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

0 Kudos

1,695 Views
Sabina_Bruce
NXP Employee
NXP Employee

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

0 Kudos

1,695 Views
dansmithers
Contributor III

Hi Sabina,

I've got a cut down project that shows the problem in a slightly different way. It calls the hardfault handler after a while. The culprit appears to be PRINTF called within the SVC call - which is probably not a great idea in the long run.

thanks

dan

0 Kudos

1,694 Views
Sabina_Bruce
NXP Employee
NXP Employee

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:

pastedImage_1.png

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!

----------------------------------------------------------------------------------------------------------------------- 

0 Kudos

1,694 Views
dansmithers
Contributor III

Hi Sabina,

I am using a Segger J-Link plus v 10.1.

I get an automatic temporary break point in main.

pastedImage_2.png

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.

pastedImage_3.png

thanks for your help.

Dan

0 Kudos

1,694 Views
Sabina_Bruce
NXP Employee
NXP Employee

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

0 Kudos

1,695 Views
dansmithers
Contributor III

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

0 Kudos

1,695 Views
Sabina_Bruce
NXP Employee
NXP Employee

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

0 Kudos

1,695 Views
dansmithers
Contributor III

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

pastedImage_1.png

0 Kudos

1,695 Views
Sabina_Bruce
NXP Employee
NXP Employee

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!

----------------------------------------------------------------------------------------------------------------------- 

0 Kudos