MPC5777C Flash optimization causes IVOR1

[darq]

Hello,

I have added part of the code responsible for optimization of flash from AN5191 Software Initialization and Optimization. After flashing this software i see that it ends up in an IVOR1 handler function. The status of registers looks like it failed after trying to copy first byte of flash_opt routine. The code sample mentions that those settings are for 132MHz platform clock and we run it at 150MHz which according to datasheet of this micro should be ok. The register content when i attach to running target is below.

General Registers General Purpose and FPU Register Group
r0 0
r1 -16
r2 0
r3 -1610609011
r4 40
r5 1073741825
r6 112
r7 0
r8 0
r9 0
r10 0
r11 0
r12 0
r13 0
r14 0
r15 0
r16 0
r17 0
r18 0
r19 0
r20 0
r21 0
r22 0
r23 0
r24 0
r25 0
r26 0
r27 0
r28 0
r29 0
r30 0
r31 -16
pc 0xc80c
msr 0
cr 0
lr 0x40000000
ctr 39
xer 0

Exception registers are in the attached picture. The software ends up in exception handler function from address 0x40000000 which is empty at this point. It should end up at this address only after copying all the data from routine. When i try to debug the software everything runs ok and no exception occurs. Only when not debugging, the issue occurs which makes it a bit hard to analyze. There are no initialization scripts specified for the debugger in debug configuration. We use S32DS and PE-micro Universal debugger. 

Also when connecting to running target i can see a bunch of data in SRAM (0x40000020) which should be cleared at this point. Not sure where is this data coming from.

The two issues that i would like to solve is IVOR and different behavior when debugging and not.

Any ideas how to solve this?

[davidtosenovjan]

The mentioned code is expected to be a part of init routine before main application is started. It executes code from SRAM where it is copied before, so nothing valid should be on that address range.

But you can reconfigure it even from runtime, but in such case I would recommend to use procedure as described in the section 26 in the AN2865:

https://www.nxp.com/docs/en/application-note/AN2865.pdf

[darq · Accepted solution]

Hello,

The issue was that the RAM used by the code snippet provided in the documentation was not initialized by writing 0s. Application and bootloader initialized their own dedicated RAM sections but the "common" section was not initialized by any of them.

The issue with different behavior was that s32ds was using some script to initialize RAM even though no script was specified to initialize it. It used beginning of RAM in some way, that is why there was data in this part of RAM.

Best regards