• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 1029 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 246593
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Softdevice 7 does not boot unless flash space gap is filled 0xFF

hjz

Recently tried to upgrade the NRF SDK from 14 to 16 on our project, and also upgrading Softdevice from 5.0.1 to 7.0.0.

While trying to bring up Softdevice 7.0.0, we noticed that the main FW will NOT get booted unless all the gaps in the flash space filled with 0xFF instead of 0x00.

We discovered this because in our flash script we merge the hex files of softdevice and main FW, and then convert them to a binary file using arm-objcopy, and by default arm-objcopy fills any gap space from the hex file with 0x00.

This process worked fine on Softdevice 5.0.1 with NRF SDK 14, but now fails with Softdevice 7.0.0 and NRF SDK 16. Only when arm-objcopy used with gap-fill 0xFF option did Softdevice and main FW boot up properly.

We just want to confirm this is the desired behaviour, and wondering what changed since SDK 14 and Softdevice 5.0.0 that caused this behviour?

Parents
  • 0

    Just to be very explicit, our build system does the following:

    1. Compile and link our application into an elf file.

    2. objcopy the application elf file to a hex file.

    3. mergehex (nrf command line tool) the SD hex file and the application hex file.

    4. objcopy the merged hex file to a bin file.

    Step 4 is what we're talking about here, where the gap-fill value causes SoftDevice to crash on boot before coming near the application code.

    We'd love an explanation if you have one, but the most important piece of information we need is whether or not SDK14.0.0 + S132v5.0.1 are resilient against this approach. We didn't see any errors when testing but that's a weak hypothesis compared to a root cause analysis.

Reply
  • 0

    Just to be very explicit, our build system does the following:

    1. Compile and link our application into an elf file.

    2. objcopy the application elf file to a hex file.

    3. mergehex (nrf command line tool) the SD hex file and the application hex file.

    4. objcopy the merged hex file to a bin file.

    Step 4 is what we're talking about here, where the gap-fill value causes SoftDevice to crash on boot before coming near the application code.

    We'd love an explanation if you have one, but the most important piece of information we need is whether or not SDK14.0.0 + S132v5.0.1 are resilient against this approach. We didn't see any errors when testing but that's a weak hypothesis compared to a root cause analysis.

Children
No Data
Related
Terms of service