i.MX RT1061 bootstrap code skipping a Thumb ldr opcode...?

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

i.MX RT1061 bootstrap code skipping a Thumb ldr opcode...?

625 Views
np
Contributor IV

I'm currently looking at a really strange problem in my RT106x bootstrap code. It seems that a single Thumb opcode is being skipped in a section of XIP code running from the 0x60000000 QSPI when run directly (for the first time), but not when being single-stepped.

The code looks like this:

np_0-1645805116991.png

The PC reaches this line with r2 = 0x1 and r7 = 0x2003fef0 (i.e. on the stack), while [r7, #12] holds 0x600200000 (a value that has been written a few instructions earlier).

If I break on this line (0x60007c9a) and single step it, it ALWAYS works correctly (i.e. the M7 reads 0x60020000 from [r7,#12] and puts it into r2. However, if I break on the following line (0x60007c9c), r2 is ALWAYS set to 0x1 - i.e. it's as if "ldr r2,[r7,#12] is being skipped the first time it's executed directly.

Note that this is in bootstrap code, shortly after booting up, so there are no processes, no threads, and no interrupts going on: basically, it's pure Thumb code (there's no RTOS active yet).

Also: if I break after the line (which fails to set r2), but then set the PC to the problematic line (i.e. 0x60007c9a) and run from there, it ALWAYS works perfectly.

Also: if I break on the following line and set r2 to 0x60020000 (i.e. pretending that the non-working line had worked), subsequent calls to the same function work perfectly.

Hence it seems that this error is only happening the very first time this piece of code is executed: subsequent calls to the same function always work perfectly.

Also: I've tried this on two different boards (manufactured nearly a year apart), and they both behave in the same way. So the problem seems unlikely to be a QSPI failure or a CPU failure (neither board has been worked particularly hard).

Also: it's a fragile error, because if I insert test code that moves the location of the line around, the problem disappears.

What on earth could be causing this to go wrong? I can't see any obvious mechanism at all.

It feels as though there's some kind of dirty data cache line or dirty AXI buffer being left over from the processor's boot-up, but I can't see how that could have been missed by NXP.

Is there some kind of obligatory startup cache clearing that all bootstrap code should run?

Labels (1)
0 Kudos
1 Reply

605 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @np ,

    Thank you for your interest in the NXP MIMXRT product, I would like to provide service for you.

   As I know the bootstrap is for the solutions code, eg, SLN-LOCAL2-IOT, or the face recoginize project.

   So, please tell me which code and board you are using now?

   Do you debug the directly SDK sample code on the related board, do you still have the issues or not?

  What's the IDE you are using?

 

Best Regards,

Kerry

0 Kudos