sd_softdevice_enable never returns

[Fabien Comte]

Hello,

The sd_softdevice_enable never returns, how can I investigate please ?

With my Jlink probe, it's look halted at address 0x000008CC.

Configuration:

SDK 15.0.0, SD_132_6.0.0 with bootloader

[AmbystomaLabs]

I wouldn't mess with anything on the NVIC when using the SD even just to debug.  All manner of things can go wrong.

Invariably, the inability to enable the SD is virtually always clock related.  Normally people just mess up the LF clock config info the SD uses and usually this is because it is a custom board and they didn't place the crystal to save money or space.

It will halt in random places since it keeps chugging along until it realizes the LF clock isn't running.  All the addresses are inside the SD so impossible to say (except for Nordic) what is actually going on at that memory location.

Double check your clock config.

[Fabien Comte]

Hello,

It's not a clock issue for two reasons:

- I tried with RC clock without success.

- This board works with my code for SDK 13

I have a hardfault exception...

[Fabien Comte]

Hello,

It's a custom board. I will try with a DK ASAP

[Fabien Comte]

Hello,

My problem is confirmed with a DK board. Always a hardfault. Where can i found the memory layout of S132 for SDK 15 please ? Where in SDK are settings that i may have to change (addresses, sizes, ...)

[Fabien Comte]

I tried Nordic exemple "ble_app_multirole_lesc" for S132, (no bootloader, Segger probe and -Og at compilation) => same issue

[jev]

This happens in your debugger, no? Which one are you using?

You load the softdevice, than load the app, than press the start button in your debugger?

Check where the debugger starts. Most probably, it takes a start address from the vector table that is part of the application. However... that is not the same vector table that is used during reset. 

You need to tell your debugger it has to initialize PC and SP registers from the vector table at address 0. If you're using oZone, there's a discussion on the segger forum about this exact same issue (yeah, I'm in the same boat).

[Fabien Comte]

A Segger Jlink when using custom board, the onboard one when using DK.

Yes.

It starts correctly because i have a breakpoint in application main and i follow correctly until "sd_softdevice_enable" (the blocking function with hardfault)

Ok do you have a link please ?

Thank you for your help

[jev]

The softdevice needs to execute code pre-main. 

https://forum.segger.com/index.php/Thread/5252-oZone-IAR-ElfDwarf-problems-and-unexpected-break. It may look like the stuff in this thread is unrelated to the one you describe, but it shares the same problems. Note, the first issue I mention there about the Elf/Dwarf warning has nothing to do with this specific problem.

If you're using oZone, you need to modify the .jdebug file that is generated by oZone (provided you saved one!).

Start with simply opening your project in oZone and reset the target. In the console windows, you should see something like this:

Debug.Halt();
Debug.Reset();
J-Link: Reset: Halt core after reset via DEMCR.VC_CORERESET.
J-Link: Reset: Reset device via AIRCR.SYSRESETREQ.
Target.SetReg ("SP", 0x20000400);
Target.SetReg ("PC", 0x8E9);

Jot down the two addresses shown for future reference.

Then save the project, close oZone and open the saved .jdebug file in your favorite ASCII editor. Now search for the AfterTargetReset function and modify it to read:

void AfterTargetReset (void) 
{
	unsigned int SP;
	unsigned int PC;

	SP = Target.ReadU32(0);
	Target.SetReg("SP", SP);

	PC = Target.ReadU32(4);
	Target.SetReg("PC", PC);
}

Then search for the AfterTargetDownload function and replace its contents with the same code. Save the .jproject file and reload your project in oZone. In the Console window, you should see different start addresses from the ones you wrote down earlier.

If you're not using oZone but the one that is integrated in your development environment, things work differently. I use IAR, which is pretty simple: just make sure the debugger is started with the commandline option "--drv_vector_table_base=0x0" (in project options, go to "Debugger", select "Extra options" tab, enable "Use command line options" and enter the string "--drv_vector_table_base=0x0" in the text field).

If you're using another toolchain you're pretty much on your own - can't help you with those.

[Fabien Comte]

Thank you very much for your help. It's solved now !!!!!!!!!!!