• State Verified Answer
  • Replies 6 replies
  • Subscribers 68 subscribers
  • Views 1663 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 237247
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

Parents
  • 0

    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

  • 0 in reply to tesc

    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.

  • +1 in reply to mjeromin

    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

  • 0 in reply to tesc

    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?
  • +1 in reply to mjeromin

    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

  • 0 in reply to tesc

    thx for your help, we figured that out now Slight smile

    although, we decided to erase the bootloader for now and flash the firmware directly.

    however, for later iterations this is going to help a lot.

Reply Children
No Data
Related