• State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 73 subscribers
  • Views 1271 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 249156
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

The sdk 16 - bootloader positions s140 softdevice V. 7.0.1 wrongly in nrf52840.

PeterLeicht

The sdk 16 - bootloader positions s140 softdevice V. 7.0.1 wrongly so that it is acknowledged as Application and does not work with nrf52840.

As you can see at the picture, that whenever the sdk 16.0.0 bootloader is involved, the Softdevice ist not put at the Address 0x1000, like with sdk 15 bootloader, but at 0xff8. Then the softdevice is marked green like an applikation and the whole app does not run. I used the nrf connect v. 3.3.3 (newest), and also when I program the soc with the Segger Embedded Studio, it does not work.

I also tried different versions and variants of the bootloader (open, debug, with or without merged settings hex)

How can I avoid this problem? Thanks for help!

Parents
  • 0

    Hi,

    The SoftDevice always start at 0x1000, but the nRF Connect Programmer app misinterprets this when it reads the flash since the last words of page 0 (MBR page) are not empty. So what you see in nRF Connect Programmer is incorrect and not related to the problem you are seeing.

    From what I understand, the problem is that the application is not started. Can you upload the log from the debug bootloader? Tha twill most often points to the problem in these cases. The most typical reason for not starting the application is if the bootloader does not know that a valid application is present. This is typical if you have programmed the bootloader, application, and SoftDevice, but did not program a valid bootloader settings page. If so the bootloader will enter DFU mode instead of starting the application. We will see if this is the case or not by looking at the RTT log from the debug bootloader.

    In addition to the log, can you show in detail what you have done, including how you generated the bootloader settings page, and how you programmed the various hex files (including the correct order, and any erases you have done during the process etc).

Reply
  • 0

    Hi,

    The SoftDevice always start at 0x1000, but the nRF Connect Programmer app misinterprets this when it reads the flash since the last words of page 0 (MBR page) are not empty. So what you see in nRF Connect Programmer is incorrect and not related to the problem you are seeing.

    From what I understand, the problem is that the application is not started. Can you upload the log from the debug bootloader? Tha twill most often points to the problem in these cases. The most typical reason for not starting the application is if the bootloader does not know that a valid application is present. This is typical if you have programmed the bootloader, application, and SoftDevice, but did not program a valid bootloader settings page. If so the bootloader will enter DFU mode instead of starting the application. We will see if this is the case or not by looking at the RTT log from the debug bootloader.

    In addition to the log, can you show in detail what you have done, including how you generated the bootloader settings page, and how you programmed the various hex files (including the correct order, and any erases you have done during the process etc).

Children
  • 0 in reply to Einar Thorsrud

    Dear Einar,

    thanks for your answer. After running the ble debug bootloader of sdk 16.0.0 with the ses the RTT Log does not work, although the bootloader is running. Without the bootloader my application prints out the RTT Log, but with the bootloader also no output. Would it be necessary to merge the debug bootloader to a correct settings page in order to receive the RTT Log ? Is it wrong to run the bootloader with ses and the jlink USB debugger box in the relase-configuration, in which it comes by default? Do I have to adjust something in order to receiva an RTT output? In the configuration wizard the config file seems to be rightly configured for RTT output from the nordic team allready.

  • 0 in reply to PeterLeicht

    Hi,

    PeterLeicht said:
    After running the ble debug bootloader of sdk 16.0.0 with the ses the RTT Log does not work, although the bootloader is running. Without the bootloader my application prints out the RTT Log, but with the bootloader also no output. Would it be necessary to merge the debug bootloader to a correct settings page in order to receive the RTT Log ?

    Yes, you will have problems when RTT logging is enabled in both the bootloader and applications (since the RTT viewer may find two RTT blocks in RAM and won't know which to use when). In this instance, we are first interested in the RTT log from the bootloader, and the simplest way to fix it is to just disable RTT logging in the application. Then the RTT log from the debug bootloader should show up in RTT Viewer without any problems. Can you test that first and upload the bootloader RTT log here?

    PeterLeicht said:
    ? Is it wrong to run the bootloader with ses and the jlink USB debugger box in the relase-configuration, in which it comes by default?

    No, that is correct. Use the bootloader project ending with _debug as is, which is release configuration (with optimization), but with RTT logging enabled.

    PeterLeicht said:
    I have to adjust something in order to receiva an RTT output?

    No. The _debug bootloader projects all have RTT logging enabled (that is basically the only difference). But you should make sure that you disable RTT logging in the application as described above to avoid any problems.

  • 0 in reply to PeterLeicht

    Hello Einar,

    I could solve the problem by simply using another laptop. Even exchanging the SDK or the ses could not help, but replacing the laptop helped, everything worked smoothly then. I guess something in the windows configuration was not ok. Thanks for your effort.

Related
Terms of service