How to debug code when the startup already hangs in the reset handler?

Log in or register to post comments
Go To Last Post
8 posts / 0 new
Author
Message
synthie
synthie's picture
Level: Rookie
Joined: Sun. Apr 12, 2020
Posts: 26 View posts
#1
Posted by synthie: Mon. Mar 28, 2022 - 10:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

I have code that uses an interrupt routine. My while loop in the main() function heavily interacts with results from the interrupt routine, so I know I have to use volatile for a fairly large number of variables where either my interrupt routine or my code within the while loop of main() change variable contents that the other part depends on.

 

The execution time of the code is too slow if I turn optimization off but I know that it works if I reduce the interrupt period low enough so I can debug my code.

 

When using optimization, however, my code hangs in the reset handler (startup file startup_samv71q21b.c that is executed before main()). I have no idea how to find the culprit for the hangs.

 

What is the right approach to find out what's going on? Right now I have the situation that -O2 and -Os work, but -O3 does not. I say "right now" because sometimes even -O2 doesn't work. I've also had the situation where -O3 worked but -Os gave me better execution time.

 

I am using Atmel Studio version 7.0.2389 and the native gcc compiler. I have also the option to use later gcc compiler versions provided by ARM.

 

The µController is a ATSAMV71Q21B.

Tags:

Atmel SMART ARM-based MCUs and MPUs, Atmel Cortex-M MCUs
Last Edited: Mon. Mar 28, 2022 - 09:05 PM
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5412 View posts
Location: SF Bay area
Posted by westfw: Tue. Mar 29, 2022 - 01:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

my code hangs in the reset handler (startup file startup_samv71q21b.c that is executed before main()). I have no idea how to find the culprit for the hangs.

 There are various ways to debug the code that happens before main()

Probably easiest is to find your "Reset_Handler" function source and put a breakpoint there.  (for SAMD21 ASF projects, at least, this all gets copied into each project.  I'm not positive  that SAMV71 is the same, but it should be close...)

Once you have a narrower idea of where it "hangs", you'll have more hints as to debugging.

 

Top
synthie
synthie's picture
Level: Rookie
Joined: Sun. Apr 12, 2020
Posts: 26 View posts
Posted by synthie: Tue. Mar 29, 2022 - 05:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@westfw, that's what I did in the first place, otherwise I wouldn't have known that the code is already hanging before main() is executed.

 

When I turn off optimization, I see the following at the very beginning of the reset handler. Notice the proper entries for pSrc and pDest shown in the watch list:

 

 

 

 

With optimization set to -O3, the debugger stops at the breakpoint and says for both pSrc and pDest: "Unknown location":

 

 

When I continue debugging by hitting F5, the code will eventually hang and show me some area in the disassembler.

Last Edited: Tue. Mar 29, 2022 - 05:09 PM
Top
hs2
hs2's picture
Level: Rookie
Joined: Mon. Dec 10, 2018
Posts: 23 View posts
Posted by hs2: Tue. Mar 29, 2022 - 07:44 PM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not just debugging your startup code/application without optimization and the debugger and try running the optimized (RELEASE) version later ?

With optimization turned on things, well, get optimized away and you’ll have a much harder time to debug (and you need good understanding of assembler and ABI).

is your debug build running properly ?

Top
synthie
synthie's picture
Level: Rookie
Joined: Sun. Apr 12, 2020
Posts: 26 View posts
Posted by synthie: Tue. Mar 29, 2022 - 08:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand what you mean. As stated in my initial post, the code is working fine when not optimized. Now, when trying to optimize, the code is no more executing as, for whatever reason, the source and destination addresses appear to be missing in the reset handler.

Top
hs2
hs2's picture
Level: Rookie
Joined: Mon. Dec 10, 2018
Posts: 23 View posts
Posted by hs2: Tue. Mar 29, 2022 - 09:24 PM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry - I missed the info that the non-optimized build works.
Don’t get confused that some variables are optimized out and processor registers are used directly. This also can’t be handled by a debugger because the symbols of those variables are not longer there, 

Set some more breakpoints on the next functions called (finally it’s main) or step through the assembler code to narrow down where the problem occurs. Almost always crashing optimized applications reveal some broken code or undefined behavior.

Last Edited: Tue. Mar 29, 2022 - 09:30 PM
Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 5412 View posts
Location: SF Bay area
Posted by westfw: Wed. Mar 30, 2022 - 12:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the breakpoint and says for both pSrc and pDest: "Unknown location"

 That probably doesn't mean anything other than that pSrc and pDest have been optimized so that they are always in registers.

(although, the code I'm check on (for a SAMD21) says specifically "<optimized out>" rather than "unknown location.")

 

When I continue debugging by hitting F5, the code will eventually hang and show me some area in the disassembler 

Use F11 and/or judicious insertion of breakpoints to find which area of the binary is causing problems.

On my board, __libc_init_array() looks like the only pre-main function that doesn't have source code (and would drop you into the ASM listing.)

(which is ... bad, because I can't think of a reason that __libc_init_array() would fail.

Top
synthie
synthie's picture
Level: Rookie
Joined: Sun. Apr 12, 2020
Posts: 26 View posts
Posted by synthie: Wed. Mar 30, 2022 - 06:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The code hangs immediately with the first assignment in the for loop right after the breakpoint shown above in the picture. It is the same behavior as shown in this thread, but that was reported back in 2017.

 

I use a customized linker script samv71q21b_flash.ld where I split the FLASH into two segments, each 1 MB large. The first half is used for the firmware, the second half is used for configuration storage in flash, mimicking EEPROM using wear leveling. I've essentially used the original linker script and adapted it in two places:

 

/* Memory Spaces Definitions */
MEMORY
{
    rom  (rx) : ORIGIN = 0x00400000, LENGTH = 0x00100000 /* rom, 1048576 bytes                    */
    rom2 (rx) : ORIGIN = 0x00500000, LENGTH = 0x00100000 /* used for flash-based EEPROM emulation */
    ram (rwx) : ORIGIN = 0x20400000, LENGTH = 0x00060000 /* ram,  393216 bytes                    */
}

 

Further down in the script, I added

 

    .eeprom :
    {
        . = ALIGN(4);
        __eeprom_START__ = .;
        *(.eeprom)
        *(.eeprom*)
        . = ALIGN(4);
        __eeprom_END__ = .;
    } > rom2

 

I placed this section above near the end of the linker script, just before this final segment which says:

    . = ALIGN(4);
    _end = . ;
    _ram_end_ = ORIGIN(ram) + LENGTH(ram) - 1 ;

 

(I didn't want to copy the whole linker script into the post)

 

Last Edited: Wed. Mar 30, 2022 - 06:09 PM
Top