SES Debugger not attached NRF52840/NRF52832

[mjeromin]

Hey there,

I am trying to develop with the Bluetooth Mesh SDK for NRF5.

We have two chips, NRF52840 and NRF52840/NRF52832and are using the light_switch example from the bt mesh sdk.

We can have breakpoints while debugging on the NRF52832, but we cannot get it to debug with the NRF52840. It seems to flash fine, and also seems to run, but does not stop at breakpoints.

IDE: SES, we generated all emProjects using the CMAKE call at mesh-SDK root. That worked (except of doxygen missing, which should not be relevant?).

CMAKE Options: -DPLATFORM=nrf52840_xxAA -DSOFTDEVICE="s140_6.1.1" -DSDK_ROOT="../nRF5_SDK_15.3.0_59ac345" -DEXPERIMENTAL_INSTABURST_ENABLED=ON -DTOOLCHAIN=gccarmemb

OS: Win10

Flash: via JLink Flasher and JFlash 6.52a.

We checked so far:

* debug build is selected (dropdown field on top of the project explorer)

* softdevice s140 seems to be configured correctly (?)

* clean project and build fresh

* different programmer/flasher

[tesc]

Hi,

Are you testing this with DKs, or is it a custom board?

Are you debugging through SES, or do you use a separate debugger (and if so which one)?

Regards,
Terje

[mjeromin]

we are using the develoment kit and a USB stick version (fanstel BT840F)

as it seems, there is a bootloader preinstalled.

The flasher seems to place the compiled code at the correct spot.

Our current guess is that we are hanging in the bootloader, s.t. the PC does not reach our own code.

[tesc]

HI,

If they have done anything like what we did on our nRF52840 Dongle (PCA10059) then there is a bootloader preinstalled, yes. There might also be differences in VDD, crystals, etc. from what you would find on a DK.

It looks like the BT840F is influenced by the design of our nRF52840 Dongle, and so the nRF52840 Dongle Programming Tutorial might be of help for identifying possible pitfalls, and in particular the subsections under the "Using an external debugger" section of that tutorial. All of that may apply to a third-party module without on-board debugger, so you should check with documentation for the BT840F from Fanstel to see if properties of that module is the same as for our Dongle.

Regards,
Terje

[mjeromin]

hey,

that tutorial actually helped to clear some questionmarks. We have more infos now:

1. the Programmer App sais that:

"DFU failed: Error message for known extended error code from DFU target: The init packet does not contain a signature. This bootloader requires DFU updates to be signed."

how would we add such a signature? We have no Pki running?

2. if we erase the chip and flash the firmware only (without DFU), our breakpints get triggered. With DFU Bootloader, it seems to be caught in the bootloader. We can pause code execution and see the disassemby, but we have no matching sourcecode. PC address is in bootloader range. May the bootloader hand over to our firmware? possibly because of the missing signature?

[tesc]

Hi,

The default firmware for the nRF52840 Dongle is the Open Bootloader with DFU, which only uses signing for updating the bootloader itself. Were you trying to update the bootloader?

I do not know what Fanstel has done with their module, though, so they may be using the Secure Bootloader (which requires signing for all updates).

You may of course build your own version of the bootloader if you want to, with your own key pair for signing. You may have to check with the BT840F specifications and/or Fanstel to see if there are any HW differences that you must handle. (Similar to when building firmware for the nRF52840 Dongle.)

Note that the Bootloader checks the CRC of the application before jumping to it, and if the CRC does not match what the Bootloader has previously stored in its Bootloader settings page it will not start the application. This is most likely the issue you are seeing in 2. See Generating and displaying bootloader settings for how to generate a bootloader settings page for a given application using nrfutil.

Regards,
Terje