Finding function in project with some flash only functions

[CollinK]

So, it's great that CrashReporter exists and it is possible to see a stack trace of where the program crashed. However, there is a problem. The usual advice to use addr2line only seems to work well if you don't put any functions into only flash. Usually the address given by the crashdump then works with addr2line and you can figure out where the crash was. However, it seems if you use flash only functions then the way things are arranged gets all messed up and addr2line no longer is a reliable way to find the function. Some programs are much larger than the available RAM1 space and so there comes a need to keep some functions out of RAM.

Am I not doing something right or is this a real problem? Is there a good way to mitigate the issue so that complex programs that are comprised of a mixture between RAM and FLASH resident code can be debugged via the crash handler?

 

[KurtE]

Sometimes when I find that addr2line fails to find the crash. I use some of the other compiler generated files to see if it gives me
any clues.

In the same directory you find the .elf file in my case on my windows machine, I find all the cached builds are up at:
%temp%\arduino\sketches\<some ggenerated Directory name hex>\

The first file I might look at is the <sketch name>.sym (symbols). I open that up into my text editor and do a search for the address. Most of the time won't find it directly. So have the editor sort the lines. And then browse down to find addresses in that area, like in the area of where it
faulted. And hypothetically suppose the address is between the two functions in the symbol file like:

60001788 g     F .text.code    0000003c NT35510_t4x_p::setBitDepth(unsigned char)
600017c4 g     F .text.code    000001bc NT35510_t4x_p::setRotation(unsigned char)
60001980 g     F .text.code    00000060 NT35510_t4x_p::invertDisplay(bool)

And I also look at the file <sketch name>.lst (disassembly listing) and if the address that faulted was near setRotation above
you can look at the assembly listing

600017c4 <NT35510_t4x_p::setRotation(unsigned char)>:
    _rotation = r & 3;
600017c4:    f001 0103     and.w    r1, r1, #3
    switch(_rotation) {
600017c8:    2902          cmp    r1, #2
FLASHMEM void NT35510_t4x_p::setRotation(uint8_t r) {
600017ca:    b5f8          push    {r3, r4, r5, r6, r7, lr}
600017cc:    4604          mov    r4, r0
    switch(_rotation) {
600017ce:    f000 80c7     beq.w    60001960 <NT35510_t4x_p::setRotation(unsigned char)+0x19c>
600017d2:    2903          cmp    r1, #3
600017d4:    f000 80bc     beq.w    60001950 <NT35510_t4x_p::setRotation(unsigned char)+0x18c>
600017d8:    2901          cmp    r1, #1
600017da:    f000 80b1     beq.w    60001940 <NT35510_t4x_p::setRotation(unsigned char)+0x17c>
600017de:    f44f 73f0     mov.w    r3, #480    ; 0x1e0
600017e2:    f44f 7048     mov.w    r0, #800    ; 0x320
600017e6:    2500          movs    r5, #0
600017e8:    469e          mov    lr, r3
600017ea:    4606          mov    r6, r0

And hopefully figure out what it might be doing...