Softdevice hanging at startup

[Hugo Habicht]

Hi all,

I am having a problem with the startup of the software on an nRF52840. It works fine on an EVM but not on our own board. The software is hanging in the softdevice s140 before even reaching main() (on some boards only). I can see in the debugger when I stop the software that it is in address 0x2ff8 waiting for an external interrupt.  What is is waiting for? What are we missing?

And I have asked the question before without ever getting an answer: IS THERE ANY DOCUMENTATION OR SOURCE CODE OF THIS MAGIC BLACK BOX CALLED SOFTDEVICE AVAILABLE?

Any help would be appreciated.

Regards,

[Hugo Habicht]

Hi Jørgen,

I compiled the original unchanged example of your SDK HRS. Works on the Nordic EVM. Bur it does not even reach main() on our board. So that leads to the question:

WHAT CAN PREVENT THE SOFTDEVICE FROM CALLING main()?

What pin, signal, power supply, configuration etc. would do that?

And you did not answer my original question:

WHAT IS THE SOFTDEVICE DOING IN ADDRESS 0x2ff6? WHAT IS IT WAITING FOR? COULD YOU PLEASE FIND OUT?

Or should we be rather looking into the ESP32?

Regards,

[Jørgen Holmefjord]

Hugo Habicht said:

Also, does the hrs example include a boot loader?

No, the bootloader is a separate example that is built and flashed separately from the application.

Hugo Habicht said:

WHAT IS THE SOFTDEVICE DOING IN ADDRESS 0x2ff6?

This is WFE/sleep operation.

Hugo Habicht said:

So what (hardware input) makes the softdevice going into bootloader mode? Software is identical, so that cannot be the problem.

The bootloader will enter DFU mode under the following conditions:

• No valid application is present.
• SoftDevice is activated and a valid application is present. In that case, the bootloader expects that an application update can be requested by the host.
• Entering DFU mode is triggered by one of the optional sources:
  • Button (NRF_BL_DFU_ENTER_METHOD_BUTTON),
  • Pin reset (NRF_BL_DFU_ENTER_METHOD_PINRESET),
  • Special value in GPREGRET register (NRF_BL_DFU_ENTER_METHOD_GPREGRET),
  • Request from the application written to the settings page (NRF_BL_DFU_ENTER_METHOD_BUTTONLESS).

In addition:

If one of the following conditions occurs, the bootloader enters the DFU mode:

• no application is installed,
• the integrity check fails,
• there is no settings page.

If you did not build and flash the bootloader with the valid settings page for the application, the bootloader will enter DFU mode. If you did not intend to use the bootloader, please erase the chip using "nrfjprog --eraseall" command before flashing your application.

[Hugo Habicht]

Hi Jørgen,

I did not program any bootloader but it may have been in the module we are using and we certainly want to use it.

Can you point me to documentation where all what you mentioned above is described in detail?

Regards,

[Jørgen Holmefjord]

Here is a link to the Bootloader and DFU modules documentation. If the bootloader came with the module, you should check with the module manufacturer to make sure they are using an unmodified bootloader from our SDK, and which SDK version they have used. You can also erase the module and build your own from our SDK, see the DFU bootloader examples documentation.