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 Reply Children
  • Exactly. I finally got GDB running, no thanks to the Nordic GCC environment document. The Nordic app note tells you how to get GDB working, but the app note says to put mon speed 10000 when it should actually be mon speed 1000, only a slight order of magnitude different (in the wrong direction). Once I got that changed, I was able to get GSB to actually get to "main", but then the first routine enables the uart interrupt (I think going through softdevice using : NVIC_ClearPendingIRQ( UART0_IRQn ); NVIC_SetPriority( UART0_IRQn, APP_IRQ_PRIORITY_LOW ); NVIC_EnableIRQ( UART0_IRQn );

    Once I do that, the very next thing is to put a character into the NRF_UART->TXD and that's all she wrote. The next thing is "0xFFFFFFFE" world. I can't live with this. If I can't debug with reasonable tools, I'm back to the stone ages again. I'm sure Keil wouldn't have this problem, but my boss isn't happy about the price. We've used Keil for test programs and that is fine, it works with softdevice, but my app is much more than the 32k limit. My code is more like 232k (maybe more) so it's big bucks for Keil or no bucks for GCC. But if the tools work (or don't work), the big bucks wins and I consider that sad.

Related