Problems with erasing and programming PFlash on AURIX TriCore (tc0), TC277-DC

Update:

By using the UDE Starterkit Debugger by PLS, I can now see that the Infineon FlashDemo code is entering trapcontext() when attempting to modify the PFlash sector.

Some time after successfully erasing the PFlash sector (again, not completely zeroed, but mostly), the code then jumps into the trap 3 handler:

0xA00F6060: 91 00 00 E8 MOVH.A a14,0x8000
0xA00F6064: D9 EE B6 61 LEA a14,[a14]0x19B6
0xA00F6068: DC 0E JI a14

Which subsequently calls _trapcontext():


0x800019B6: 0D 00 00 02 SVLCX
0x800019BA: 00 A0 DEBUG
0x800019BC: 8F 0F 43 41 OR d4,d15,0x30
0x800019C0: 6D FF E8 F3 CALL 0x80000190
0x800019C4: 0D 00 40 02 RSLCX
0x800019C8: 00 80 RFE
0x800019CA: 0D 00 00 02 SVLCX
0x800019CE: 00 A0 DEBUG
0x800019D0: 8F 0F 42 41 OR d4,d15,0x20
0x800019D4: 6D FF DE F3 CALL 0x80000190
0x800019D8: 0D 00 40 02 RSLCX

etc.

But upon executing the first instruction in _trapcontext() (SVLCX) the debugger loses step-control of the processor. If I break-in again, I end up back in the trap 3 handler. A look at the callstack shows these 2 addresses, like they're being called recursively:

0x800019B6
0x800019B6
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xA00F6080
0xC0000068
0x80000920
0x800007E8
0x8000062A
0x80001A6A
0x80001988

So I'm now reading TriCore Architecture Volume 1, section 6.3.4 Context Management (Trap Class 3). But if anyone has any tips, I'm all ears.

-Rob