This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Why does a do-nothing main.c HardFault when run with a softdevice?

If you have the most trivial main.c possible, with a main() which does nothing at all, compile, link and load it at 0x00000000, it runs fine and does nothing .. that's basically the main.c from the template example.

If you build the same exact code, link it at 0x14000, load a 110 softdevice onto the chip and then flash the code at 0x14000, the device HardFaults. It HardFaults before it even gets to main().

Why is this? I assume that the Softdevice requires one or more of the low-level handlers to be defined and if they're not, ends up branching to nowhere and HardFaulting .. but which are they? It can't be anything which is actually done in main(), it never gets there, so it must be named, linked-in routines which handle interrupts while the Reset_Handler() code is running.

I've debugged it at length. The code always makes it into the Reset_Handler() [at 0x14xxx], it rarely gets out of it. Somewhere during the copy to RAM it HardFaults. If you single step it all the way through, which takes a good long while, it makes it to main(), but if you let it run, it immediately fails. I assume an interrupt the softdevice set up before it branched to the user code Reset_Handler() fires and fails to find something it needs.

The reason I'm trying to do something so stupid is to come up with the simplest template do-nothing main.c which works with or without a loaded softdevice. This is part of the, currently going fairly well, work I'm doing to build natively with Eclipse. I just need the simplest main.c I can which works with or without a softdevice as an example file.

Parents
  • The SIGTRAP with traceback 0xfffffffe when calling into the softdevice is exactly the issue I was having, albeit on Linux, not windows. I would suggest dropping to command line and with your arm-none-eabi-gdb do the following:

    
    $ arm-none-eabi-gdb program.elf
    (gdb) target remote :2331
    (gdb) load
    (gdb) mon reset
    (gdb) continue
    
    

    This should load the code locally, connect to the JLink device on TCP port 2331, flash the code, reset the device, and run.

    If this works, but eclipse still doesn't, then the issue is with the debug configuration eclipse is using. For me adding "mon reset" to the "Run Commands" at the very bottom of the "Startup" tab fixed it.

Reply
  • The SIGTRAP with traceback 0xfffffffe when calling into the softdevice is exactly the issue I was having, albeit on Linux, not windows. I would suggest dropping to command line and with your arm-none-eabi-gdb do the following:

    
    $ arm-none-eabi-gdb program.elf
    (gdb) target remote :2331
    (gdb) load
    (gdb) mon reset
    (gdb) continue
    
    

    This should load the code locally, connect to the JLink device on TCP port 2331, flash the code, reset the device, and run.

    If this works, but eclipse still doesn't, then the issue is with the debug configuration eclipse is using. For me adding "mon reset" to the "Run Commands" at the very bottom of the "Startup" tab fixed it.

Children
Related