Other Parts Discussed in Thread: MSP430-GCC-OPENSOURCE
Tool/software: TI C/C++ Compiler
I've spent the past day investigating a very strange error occurring in GDB.
Behavior
- program fails to reach main (usually, not always)
- occurs only on first run after launching gdb, all successive loads are error free
To investigate this issue, I examined the assembly step by step. Immediately after load we seem to be where we should be:
0xe0e8 <__crt0_start> mova #81920, r1 ;0x14000 0xe0ec <__crt0_init_bss> mova #7982, r12 ;0x01f2e 0xe0f0 <__crt0_init_bss+4> clr r13 ; 0xe0f2 <__crt0_init_bss+6> mova #132, r14 ;0x00084 0xe0f6 <__crt0_init_bss+10> clr r15 ; 0xe0f8 <__crt0_init_bss+12> calla #53686 ;0x0d1b6 0xe0fc <__crt0_init_highbss> mova #65538, r12 ;0x10002 0xe100 <__crt0_init_highbss+4> clr r13 ; 0xe102 <__crt0_init_highbss+6> mova #844, r14 ;0x0034c 0xe106 <__crt0_init_highbss+10> cmp #0, r14 ;r3 As==00 0xe108 <__crt0_init_highbss+12> jz $+6 ;abs 0xe10e
The registers also appear to be correct (though I suspect these don't get updated before running) :
(gdb) info registers pc 0xe0e8 0xe0e8 <__crt0_start> sp 0x14000 81920 sr 0x0 0 cg 0x0 0 r4 0xffff 65535 r5 0xffff 65535 r6 0xffff 65535 r7 0xa55a 42330 r8 0xffff 65535 r9 0x112 274 r10 0x1af8 6904 r11 0xffff 65535 r12 0x4 4 r13 0x1113 4371 r14 0x1a1a 6682 r15 0x4400 17408
Then after entering a single "stepi" instruction, the $pc is suddenly pointing at the beginning of HIFRAM:
(gdb) stepi 0x00010004 in cosmosStrP.2845 () Instructions at this address: 0x10004 <cosmosStrP.2845+2> and.b @r15+, -1(r15) ; 0xffff 0x10008 <cosmosStrP.2845+6> and.b @r15+, -1(r15) ; 0xffff 0x1000c <cosmosStrP.2845+10> and.b @r15+, -1(r15) ; 0xffff 0x10010 <cosmosStrP.2845+14> and.b @r15+, -1(r15) ; 0xffff 0x10014 <cosmosStrP.2845+18> and.b @r15+, -1(r15) ; 0xffff . . .
As you can see, the program counter is in the weeds:
(gdb) info registers pc 0x10004 0x10004 <cosmosStrP.2845+2> sp 0x14000 81920 sr 0x101 257 cg 0x0 0 r4 0xffff 65535 r5 0xffff 65535 r6 0xffff 65535 r7 0xa55a 42330 r8 0xffff 65535 r9 0x112 274 r10 0x1af8 6904 r11 0xffff 65535 r12 0x4 4 r13 0x1113 4371 r14 0x1a1a 6682 r15 0x4400 17408
According to the map file, this is the location of upper.data:
.upper.data 0x0000000000010000 0x2 load address 0x00000000000058de
0x00000000000058de __upper_data_init = LOADADDR (.upper.data)
0x0000000000010000 0x2 SHORT 0x1
0x0000000000010002 __high_datastart = .
*(.upper.data.* .upper.data)
0x0000000000010002 __high_dataend = .
0x0000000000000000 __rom_highdatacopysize = (SIZEOF (.upper.data) - 0x2)
0x00000000000058e0 __rom_highdatastart = (LOADADDR (.upper.data) + 0x2)
So that's very strange and I don't see how $pc can be set to 0x10000 on the initial load. I was unable to find clear information on how the CPU registers are set. Now if we do a "load" the registers appear to be back to normal:
(gdb) info registers pc 0xe0e8 0xe0e8 <__crt0_start> sp 0x14000 81920 sr 0x101 257 cg 0x0 0 r4 0xffff 65535 r5 0xffff 65535 r6 0xffff 65535 r7 0xa55a 42330 r8 0xffff 65535 r9 0x112 274 r10 0x1af8 6904 r11 0xffff 65535 r12 0x4 4 r13 0x1113 4371 r14 0x1a1a 6682 r15 0x4400 17408
And indeed, we can run with no issues:
(gdb) stepi 0x0000e0ec in __crt0_init_bss () 0x0000e0f0 in __crt0_init_bss () 0x0000e0f2 in __crt0_init_bss () 0x0000e0f6 in __crt0_init_bss () (gdb) b main Breakpoint 1 at 0x5a32: file src/main.c, line 13. (gdb) c Continuing. Breakpoint 1, main (argc=0, argv=0x0) at src/main.c:13
Debugging
- This behavior is repeatable
- I've been using the same debug stack for the past two weeks and the problem only started yesterday, so I assumed this was a code problem
- The most likely cause seemed to be the linker file. I pointed the stack at the top of HIFRAM and changed the length of HIFRAM to be 0x4000 instead of 0x3FFF to align $sp. Even though this is technically 1 address past the end of the allowable address range, my understanding is that $sp is always decremented (into an allowable address) before being used. This has been working for days but just to be safe I tried restoring the linker to its original configuration
- I used old code that never encountered this problem and is also ~12kB smaller
- When I power cycle the board without gdb running, the board restarts and the code executes normally
- I tried disconnecting my analog ADC signals
- I tried using another MSP device
- I restarted the lab machine it's running on
Without knowing more about how the core CPU registers are set and how to probe them before executing, I'm out of debugging ideas
