This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE dfu/I2C EEPROM update

Hello

at the moment I have a running S120 BLE firmware update on my nRF51822 hardware. This works fine on my desk. But we have the additional requirement to update the I2C EEPROM content, too. Is that possible in general? I think I have to change the nrf.exe tool to get the EEPROM image into the .zip file. Also I would have to change the App and the bootloader firmware. Additional there should be any kind of version control. Because the right eeprom image is needed to get the application firmware running as expected. Does anybody have an idea of the basic architecture/implementation of this additional step?

Regards, BTprogrammer

Parents
  • Hi BT,

    I'm thinking of an easier way that you don't have to modify the app and the zip file is that you can re-use application DFU to update the external EEPROM.

    Basically, in the bootloader, after you have copied the new app image into the swap bank (the original app has not been erased yet), you can check if there is a flag (at address 0x00 for example) with first 6 bytes = "EEPROM". Then you know it's not the app image but the external EEPROM image. Then you can start writing to I2C with this image, instead of swapping with bank 0.

    By doing that you still can keep the app, CRC checking, init packet generator. You only have to modify the bootloader.

Reply
  • Hi BT,

    I'm thinking of an easier way that you don't have to modify the app and the zip file is that you can re-use application DFU to update the external EEPROM.

    Basically, in the bootloader, after you have copied the new app image into the swap bank (the original app has not been erased yet), you can check if there is a flag (at address 0x00 for example) with first 6 bytes = "EEPROM". Then you know it's not the app image but the external EEPROM image. Then you can start writing to I2C with this image, instead of swapping with bank 0.

    By doing that you still can keep the app, CRC checking, init packet generator. You only have to modify the bootloader.

Children
  • Hi Hung Bui, thanks for your idea. But if I would implement it like this, the user must do the update procedure in two steps. First uploading the .zip package for the EEPROM and second uploading the .zip package for the application itself. Am I right? This would not be really comfortable for the end user. Do you see any chance to update the nrf.exe tool to get an additional EEPROM.hex file into the .zip archive (is the source code for the nrf.exe tool available?) ? Of course, also the Smartphone App and the Bootlader must be able to handle this... Regards!

  • Hi BT, I afraid we won't be able to provide the source code of the nrf.exe tool. But you can create the zip file without using the nrf.exe.

    The instruction to generate the init data without using nrf.exe is described here.

    The manifest.json file can be edited using notepad, and since you have control over the smartphone app you should be able to add the support for the EEPROM update beside application, bootloader, and softdevice update.

Related