• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 311 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 282271
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

nrf52832 DFU successful update for SD (s132_nrf52_7.2.0) causes application to crash

user67544

Hi

I am using nrf52832  s132 with s132_nrf52_7.2.0, sdk17

so far have successfully updated application and bootloader with an adaptation of buttonless DFU, now I have an issue with the SD.

For updating the SD I create a .zip file using the following script (Batch file) :

nrfutil pkg generate ^
--hw-version 52 ^
--sd-req 0x0101 ^
--softdevice s132_nrf52_7.2.0_softdevice.hex ^
--sd-id 0x0101 ^
--key-file private.key ^
FW_52_SD_dfupack_r.zip

I upload via the nRF Connect, the app shows 100% finished, the verification is successful according to the logs, and afterwards when I verify myself with memread I see that the relevant (to SD, 0x000000 - 0x26000) memory sectors are the same.

After the DFU for the SD, The application start running normally but soon fails, according to the CallStack it seems to be invoked from the app_sched_execute()

I am not sure what change would cause that, I think the app memory did not get damage since I checked the memory areas where the application is allocated and could not find any difference between before and after the SD upload, so the image of the app and the SD both look ok. 

I did see a difference in the flash after the app data end and the second bank (from dual bank) of what seems to be the SD was stored during OTA.

Any suggestions to why something like this might occur?

Thanks!

Parents
  • 0

    Hi,

    As everything seems OK with the DFU procedure and you have verified the flash region of both the SoftDevice and application afterwards, there issue must reside somewhere else. Do you store any persistent data outside of the application itself, for instance using FDS or other library? If so, could it be that a corruption in these data could lead to the application misbehaving and hard faulting?

    As you commented that you say, the SoftDevice is temporarily stored at a higher address in flash before it is copied in place. This is in the region above the end of the application below the bootloader and any flash pages reserved for application data (see memory layout). If you did not reserve enough space in the bootloader configuration (NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h), that could cause corruption in the application data and is a possible reason for the issue you have seen.

Reply
  • 0

    Hi,

    As everything seems OK with the DFU procedure and you have verified the flash region of both the SoftDevice and application afterwards, there issue must reside somewhere else. Do you store any persistent data outside of the application itself, for instance using FDS or other library? If so, could it be that a corruption in these data could lead to the application misbehaving and hard faulting?

    As you commented that you say, the SoftDevice is temporarily stored at a higher address in flash before it is copied in place. This is in the region above the end of the application below the bootloader and any flash pages reserved for application data (see memory layout). If you did not reserve enough space in the bootloader configuration (NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h), that could cause corruption in the application data and is a possible reason for the issue you have seen.

Children
  • 0 in reply to user7377

    Hi Einar,

    Thanks for your answer, 

    user7377 said:
    . Do you store any persistent data outside of the application itself, for instance using FDS or other library?

    I am not using FDS, I verified it is disabled (#define FDS_ENABLED 0) on the sdk_config.h, 

    What kind of other libraries might you be referring to, Is there any other non volatile areas that might be relevant, and effected from SD update?

    user7377 said:
    If you did not reserve enough space in the bootloader configuration (NRF_DFU_APP_DATA_AREA_SIZE in the bootloader's sdk_config.h), that could cause corruption in the application data and is a possible reason for the issue you have seen

    As I said before, I compared the memory are of the Application and it identical between what programming directly and after SD update, so can it be the issue?

    * I have noticed that if I add RTT printing to the application the problem disappears.

    * I have verified that if remove the app_sched_execute() call the problem disappears.

    Any other ideas?

    Thanks!

  • 0 in reply to user67544

    Just to double check, you are updating to the same SoftDevice version, right? So when you read out the flash it is identical in the SoftDevice region and application region - that is still the case? So the issue must reside somewhere else. And if this issue persists after a reset, it must be because of a change in another part of the flash then, as it is persistent.

    The other parts of the flash that are typically affected during DFU are:

    • Any other part of the flash where application data may be stored. This is between the end of the application and the start of the bootloader. The bootloader will use this as temporary storage for the new SoftDevice before it is copied into place .(For completeness: if there is no room, the application is deleted and SoftDevice may overwrite that as well - in this case the application needs to be DFU'ed inn after updating the SoftDevice).
    • The bootloader settings page.

    I suggest you do a full dump of the entire flash before and after so that we can compare to see if there are any differences, and if so where. The easiest way to get a readable flash dump is to use:

    nrfjprog --memrd 0 --n 0x80000 > flash_dump.txt

    Now...

    EranR said:

    I am not using FDS, I verified it is disabled (#define FDS_ENABLED 0) on the sdk_config.h, 

    What kind of other libraries might you be referring to, Is there any other non volatile areas that might be relevant, and effected from SD update?

    Are you storing data in flash in any other way? This could be using FDS, fstorage, or a number of other methods. If you wrote the application, and do not use FDS or then I assume you do not. This is just an idea, may not be the case.

    EranR said:
    As I said before, I compared the memory are of the Application and it identical between what programming directly and after SD update, so can it be the issue?

    I was thinking about application data, so if the application behaves differently based on data that is stored in other parts of the flash than in the application region itself.

    EranR said:

    * I have noticed that if I add RTT printing to the application the problem disappears.

    * I have verified that if remove the app_sched_execute() call the problem disappears.

    I am not able to explain this in itself without knowing more about your application. But by commenting out app_sched_execute() you do not run the scheduled even handlers, so that could indicate that one of these cause problems, for some reason. Other than comparing flash from before and after, I suggest debugging to see more of what is going on.

Related
Terms of service