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

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

asifhn — Tue, 07 Jul 2015 23:30:31 GMT

Gdb "load" seems to mess up my nordic. Please see link on my findings.

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

Maurits van der Hoorn — Wed, 30 Apr 2014 21:18:41 GMT

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.

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

Ken A. Redergård — Wed, 30 Apr 2014 21:05:29 GMT

The gcc toolchain is not to blame here, ARM has people contributing to the toolchain. The gcc toolchain is a very good toolchain with a proven track record for Intel, AVR, etc.

The issue is that Nordic has not done any QA at all for the gcc POSIX part of the SDK. This proves it; from nrf51822/Source/templates/gcc/Makefile.common:

#ifeq ($(OS),Windows_NT) include $(TEMPLATE_PATH)Makefile.windows #else #include $(TEMPLATE_PATH)Makefile.posix #endif

This will never work, it works for Windows by luck, the lines starting with # are comments. Seems someone has misunderstood the syntax for makefiles.

And, the Makefile.posix file does not exist.

I hope Nordic finds resources to streamline the gcc POSIX part of their SDK; they are almost there, and a engineer at Nordic is trying to get a toolchain working on his spare time: github.com/.../nrf51-pure-gcc-setup

BR, -Ken.

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

Daniel Gochnauer — Wed, 30 Apr 2014 20:43:39 GMT

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.

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

Ken A. Redergård — Wed, 30 Apr 2014 20:32:40 GMT

Hi,

I'm experiencing the same with nrf51_sdk_v5_2_0_39364 and s110_nrf51822_6.0.0 with the same addresses.

Running gdb the program received SIGTRAP:

Program received signal SIGTRAP, Trace/breakpoint trap. 0xfffffffe in ?? ()

Has anyone been able to run the s110 + App with the gcc toolchain ?

BR, -Ken.

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

Daniel Gochnauer — Wed, 30 Apr 2014 18:55:56 GMT

I'm having very similar problems. The code I have actually get to main, where I have a breakpoint set. I then proceed to single step. The first routine enables the uart and uart interrupts. Everything goes well until I put a byte into the uart out register. This apparently causes an interrupt and GDB jumps to 0xffffffffe (mostly "f"s followed by 1 "e"). The code runs fine without the debugger. The code I need to debug is the main application that is not working, but I can't get past the uart interrupt not being handled properly. I was thinking that maybe there is a separate thread that could handle the uart interrupt without telling me (GDB non-stop mode?) but Jlink gdbserver says not supported. There has to be a way to properly hand;le interrupts without getting sigint? I'm running on windows with GCC, jlink, all latest revisions of software. I'm not getting anywhere.

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

Maurits van der Hoorn — Tue, 01 Apr 2014 01:20:19 GMT

I was having the same debugger problems (ooooold Eclipse on Ubuntu 12.04), so I tried using the raw gdb and no issues. I compared what JLinkGDB was logging for both sessions and the main difference was that eclipse wasn't resetting the device in the same way / time. I added "mon reset" to my debug configuration under "Run Commands" (very bottom of Startup tab) and everything fixed. It even fixed this weird issue I was having with ANT channels not resetting inbetween debug sessions.

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

Richard von Lehe — Wed, 29 Jan 2014 00:33:15 GMT

I am an idiot, I had one Eclipse workspace that didn't have the last line of initialization from AN-29 (mon reset 0). That step is listed in the pdf text, but is obscured in the picture of the eclipse window in that document. Anyway, adding that line to that Eclipse workspace really does improve things.

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

Richard von Lehe — Tue, 28 Jan 2014 23:16:50 GMT

The upper 8kB of RAM being off by default should be taken care of by using the SDK-provided gcc_startup_nrf51.s, correct?

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

Richard von Lehe — Mon, 27 Jan 2014 23:18:54 GMT

Is there another thread that deals with the seeming randomness described by the original poster when debugging? Very often I still see instead of hitting the default breakpoint at main, that the pc ends up at 0xfffffffe. If I manually step through the startup code where it copies the initialized data to RAM, it almost always works. It seems like some type of race condition, but I can't really explain why it's happening.

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

Richard von Lehe — Fri, 24 Jan 2014 15:51:48 GMT

Yes, I should have mentioned that the project does work. I might have been confused about the original poster's main problem. I thought the original poster was having problems using the debugger to simply hit a breakpoint and that's the problem I'm having as well. The behavior when run in the debugger mimics the original question.

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

Ole Morten — Fri, 24 Jan 2014 15:44:45 GMT

What exactly is the problem you're seeing with this? When just compiling it and flashing from the command line, everything seems to be working as expected, and I can't see any HardFaults.

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

Richard von Lehe — Thu, 23 Jan 2014 23:17:10 GMT

Here's the ble_app_lbs project that I modified all zipped up. It should include the eclipse project, the makefile it's built with, and all source except a few SDK includes. I'm using SDK 4.4 and BLE stack v5 for this one.

Let me know if there's anything else I can provide. This one has me a bit stumped right now.

The Makefile is hacked from another project and something is messed up with dependencies such that a clean is necessary. The following sequence works for me:

make clean make debug (or make release)

ble_app_lbs.zip

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

Richard von Lehe — Thu, 23 Jan 2014 23:10:33 GMT

I cam back to try command-line GDB connecting to the J-link GDB server today. I am able to connect, but I get similar problems:

(gdb) break main Breakpoint 1 at 0x14774: file barebones.c, line 265. (gdb) target remote localhost:2331 Remote debugging using localhost:2331 Error in re-setting breakpoint 1: Cannot access memory at address 0x14774 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x00000000 in ?? () (gdb)

I'll take you up on the offer to look at my project. What's the best way to share a project? Zip it up and attach it to one of these posts? I'll do that.

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

Richard von Lehe — Fri, 17 Jan 2014 17:52:36 GMT

I saw Jim's suggestion that worked for him, switching from the DSF to the Standard GDB launcher. I tried that and it reported "Error creating session". I was worth a try, I agree. I'll give the command-line gdb a try. Thanks

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

Ole Morten — Fri, 17 Jan 2014 16:50:15 GMT

Running gdb on the command line is easy, and shouldn't take you more than 3 minutes:

Start the GDB server, make sure to select the correct device, interface and interface frequency (nRF51822, SWD, 1000 kHz).
Open a shell of some kind.
Navigate to your project folder (i.e. where you have your .out/.elf file).
Start GDB, passing the file as an argument (arm-none-eabi-gdb _build/ble_app_hrs_s110.out or similar).
Once GDB has started, connect to the GDB server by writing "target remote localhost:2331" and pressing enter.

Also, did you try out the Eclipse trick I linked to above? Should be worth a try at least. :)

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

Richard von Lehe — Fri, 17 Jan 2014 16:42:01 GMT

I must admit that I've never used gdb on the command line - at least not in Windows. I'm going to come back to this a bit later after I make sure I understand the ble_app_lbs app a bit better and do some debugging via a scope. I hate to give up on using gdb for long, but the boss doesn't want to let me spend the time to get it working properly at this point. sigh

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

Ole Morten — Fri, 17 Jan 2014 10:21:26 GMT

Have you tried running gdb from the command line? I often find this a usable first step, since Eclipse often seems to complicate things. Also, you can try taking a look on this: https://devzone.nordicsemi.com/index.php/eclipse,-gdb,-macos-so-close

If you have further problems, can you please share the complete project you're working with, so I can test it here?

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

Richard von Lehe — Thu, 16 Jan 2014 23:21:00 GMT

I'm interested in this thread as I see the same thing (or something very similar) myself. When I let things run with no breakpoints, I see the debugger stop with a signal SIGTRAP 0xfffffffe in ?? ()

The call stack shows Reset_Handler(). The line that somehow changes the program counter to 0xfffffffe is the BLX R0, where the previous line is LDR R0, =SystemInit

It seems straightforward so I'm puzzled as to what's happening. The softdevice is loaded and the application is correctly linked such that it resides at 0x14000 and doesn't use RAM below 0x20002000.

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

Ole Morten — Fri, 03 Jan 2014 10:48:46 GMT

Could you please update your question and share the project and files that you're working with? I can't say I've seen this when I've worked with GCC myself, so I'm having some trouble understanding what might be the cause of it.

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

RK — Thu, 02 Jan 2014 14:51:28 GMT

Let me try to ask the question differently.

I have the template example from the gcc folder. The ordinary one, not the ble template which is really quite full featured, just the one with main.c, system_nrf51.c and gcc_startup_nrf51.s. Those three, from the SDK, nothing else.

If I compile that, link it and load it on a blank chip at 0x00000000, it runs, you can debug into main().

if I compile that same thing, link it up at 0x14000 (using one of the other templates in the SDK with the correct Flash and RAM settings), load on a soft device (110) and then load that code at 0x14000, it HardFaults.

I don't understand why. I have debugged into the Reset_Handler, it's running, it powers up the RAM, it starts copying, it's just running the Reset_Handler code in gcc_startup_nrf51.s as normal. If you single step it all the way (a 20 minute job) to main(), it gets to main(), normally. If you let it run, it doesn't ever get there, it ends up in the HardFault handler.

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

Ole Morten — Thu, 02 Jan 2014 14:36:14 GMT

You should make sure that you use the correct system files, for example from the official SDK. The upper 8 kB of RAM is off by default on the nRF51, so if you try to use it without first having enabled it, you'll see a HardFault.

Also beware that we have an application note showing how to work with Eclipse, and you may also have use in taking a look at this GitHub repository.