Thanks for great feedback, Simon. "monitor ti" is, as you correctly assumed, single step an assembly instruction. Here is more relevant output:
(gdb) monitor rd
D0 : 00000000 00000000 00000030 00000006
D4 : 00000018 a661a87d c40f9216 56d33015
A0 : 401d0002 44035a4c 200000fc 401d0024
A4 : 1d047492 667d0fa0 00000000 20007ff0
PC : 00010022 SR : 00002704
(gdb) x /4w 0x20007ff0
0x20007ff0: 0x00000000 0x00000000 0x00000000 0x401d0002
(gdb) monitor ti
Target state : debug mode
Debug entry cause : single step
Current PC : 0x00027fac
(gdb) monitor rd
D0 : 00000000 00000000 00000030 00000006
D4 : 00000018 a661a87d c40f9216 56d33015
A0 : 401d0002 44035a4c 200000fc 401d0024
A4 : 1d047492 667d0fa0 00000000 20007ff0
PC : 00027fac SR : 00002704
(gdb) monitor ti
Target state : debug mode
Debug entry cause : single step
Current PC : 0x00000466
(gdb) monitor rd
D0 : 00000000 00000000 00000030 00000006
D4 : 00000018 a661a87d c40f9216 56d33015
A0 : 401d0002 44035a4c 200000fc 401d0024
A4 : 1d047492 667d0fa0 00000000 20007fe8
PC : 00000466 SR : 00002704
(gdb) x /8w 0x20007fe0
0x20007fe0: 0x00000152 0x00000000 0x44082704 0x00027fac
0x20007ff0: 0x00000000 0x00000000 0x00000000 0x401d0002
(gdb) x /4w 0x27fa8
0x27fa8 <srand+16>: 0x4e750000 0x4e56fffc 0x2f02203c 0x00035550
(gdb) x /16w 0
0x0 <vector00>: 0x20008000 0x00000400 0x00000466 0x00000466
0x10 <vector04>: 0x00000466 0x00000466 0x00000466 0x00000466
0x20 <vector08>: 0x00000466 0x00000466 0x00000466 0x00000466
0x30 <vector0C>: 0x00000466 0x00000466 0x00000466 0x00000466
(gdb) monitor md 0 8
00000000 : 0x20008000 536903680 ...
00000004 : 0x00000400 1024 ....
00000008 : 0x00000466 1126 ...f
0000000c : 0x00000466 1126 ...f
00000010 : 0x00000466 1126 ...f
00000014 : 0x00000466 1126 ...f
00000018 : 0x00000466 1126 ...f
0000001c : 0x00000466 1126 ...f
(gdb) monitor md 0x27fa8 8
00027fa8 : 0x4e750000 1316290560 Nu..
00027fac : 0x4e56fffc 1314324476 NV..
00027fb0 : 0x2f02203c 788668476 /. <
00027fb4 : 0x00035550 218448 ..UP
00027fb8 : 0x0c802000 209723392 .. .
00027fbc : 0x0000672e 26414 ..g.
00027fc0 : 0x223c2000 574365696 "< .
00027fc4 : 0x04fc203c 83632188 .. <
(gdb) monitor md 0x20007fe0 8
20007fe0 : 0x00000152 338 ...R
20007fe4 : 0x00000000 0 ....
20007fe8 : 0x44082704 1141384964 D.'.
20007fec : 0x00027fac 163756 ....
20007ff0 : 0x00000000 0 ....
20007ff4 : 0x00000000 0 ....
20007ff8 : 0x00000000 0 ....
20007ffc : 0x401d0002 1075642370 @...
(gdb)
Exception decoding functions are not mapped to the vector table at this point (only a "default handler" containing a halt instruction). A minimalistic vector table in flash at adress 0 should be used. The C function I'm trying to run contains code to initialise a vector table in RAM and to set the VBR. I have no reason not to trust the "monitor md" output, as this was as expected when manually erasing flash blocks with the debugger (BDI2000). According to the stack, the exception should decode as follows:
- format = 0100
- fs = 0100 = error on instruction fetch
- vector = 00000010 = access error
I also tried to insert a
nop instruction before the
jmp, to check if the exception was not related to the
link, but the exception still occurred after single stepping the
link.
...so I'm a bit lost again.