Core M0+ (STM32WL55) - apparent wrong execution of a machine instruction?

[giocc]

While debugging an application on the M0+ core of a STM32WL55JC device, the debugger showed what appears the incorrect execution of an ARM machine instruction.

The codesnippet at the beginning of the execution is shown in Image #1:

(the original C code compiled is a trivial "switch" section, but this is irrelevant)

Everything proceeds as expected until the instruction shown in Image #2.

 

The execution of the "ldr   r3, [pc, #396] " instruction @0803845c, however, seems to yield an incorrect result (as shown in image #3):

expected -> r3 = 0x80385ec (as also reported in the comment placed by the compiler)

obtained -> r3 =  0x803a868

From the memory dump (image #4), the opcode of the instruction appears to be correct according to ARMv6-M Architecture Reference Manual (DDI0419D_ARMv6-M_arm.pdf), section A6.7.27, p. A6-127:

0x803845c -> 63 4B (= 4B63)

01001 LDR <Rt>, [PC, #<imm>]

011 <Rt> = R3

01100011 = 99; <imm> = 99*4 = 396

(The following instructions cause the fetch of a jump address at an uninitialized location and a wrong jump, but that's beyond the point.)

Additional context:

code compiled by gcc, toolchain: GNU tools for STM32 (10.3-2021.10), in

STM32CubeIDE 1.9.0

Has anybody ever encountered a similar issue?

Could any of you please advise about a possible explanation or what I might be missing?

Thanks

[Tesla DeLorean]

Memory dump from a contemporary session?

Corruption via IRQ, or stack context pop.​

Issue with flash wait states or prefetch path.​

[waclawek.jan · Accepted solution]

> The execution of the "ldr   r3, [pc, #396] " instruction @0803845c, however, seems to yield an

> incorrect result (as shown in image #3):

> expected -> r3 = 0x80385ec (as also reported in the comment placed by the compiler)

> obtained -> r3 = 0x803a868

(you have error in the line above, r3 is 0x803a838 as witnessed by the screenshot)

The [] indicates indirection, i.e. that instruction should load into r3 *content* of 0x080385EC - and it indeed does:

 

JW

[Giocc1]

@waclawek.jan Of course you are absolutely right, that's what I missed. Thanks for responding (and so quickly too)!