nrf52832 OTA over ESB based on SDK17.1.0

Question

Hi everyone: I developed an application based on ESB wireless communication protocol ofr the nRF52832, and I would like to perform an OTA DFU with it. Do you know any example of some over the air FW upgrade of nRF52832 chip via ESB protocol. 
 SDK is 17.1.0. 
 Best regards, 
 Lurn.

Edvin · Accepted Answer

Good good! We are getting closer. Now you only need a way to enter DFU mode. You are correct that we can still use the GPREGRET, and we can do so without using the softdevice. By default, the api to interact with the GPREGRET is nrf_power_gpregret_set() and nrf_power_gpregret_get(), like it is used in the bootloader example. However, if the softdevice is enabled, the gpregret is restricted, so you need to access the gpregret via the softdevice API (sd_power_gpregret_set/get()). When the softdevice is not enabled, you are free to use the "normal" nrf_power_gpregret_set()/nrf_power_gpregret_get(). These are declared in SDK\modules
rfx\hal
rf_power.h. 
 So the snippet in your last reply will still work. Just replace all "sd_..." with "nrf_...", and make all the variables uint8_t instead of unt32_t (because the GPREGRET is just an 8 bit value, and the non-softdevice actually expects and returns uint8_t instead of uint32_t) and you are good. 
 
 Do you know where you want to call this function? We have not discussed this, but perhaps you already have a plan. In a BLE bootloader, it is typical to use a special BLE service to put the device in DFU mode (the buttonless_dfu service). Other methods are: 
 1: Always enter DFU mode on power on, and make it time out after X time, and then enter the application. 
 2: Hold a button/gpio on reset to enter DFU mode. 
 3: Use the gpregret from your application. You are free to decide when you write this register. If you have a UART device connected, you can e.g. use a special UART message to trigger this. 
 
 Best regards, 
 Edvin

Edvin · Answer

If you are able to run nrfutil on the Android device, then yes. (You may need to correct the COM port). If not, then you need to look at the implementation of nrfutil, and port it to your Android device. 
 Alternatively, you can look at the DFU master implementation from the DFU getting started guide . 
 BR, 
 Edvin

Edvin · Answer

Hello Lurn, 
 You can generate a packet using nrfutil containing all 3 (BL + SD + APP). If you do not use the softdevice, then you don't need to update the MBR. It is always the same in all SoftDevice versions. 
 If you update the SD you should always update the BL in the same packet (if you use SD), if the softdevice update is a major version update. This is to ensure that the softdevice used by the bootloader and the bootloader itself is matching. 
 When you create a BL (+SD) + APP update image using nrfutil, and perform the DFU, it will be split into 2. BL (+SD) first, and then application when that is done. So whether you generate one image containing BL and APP, or one image for each doesn't really matter. When the BL is updated the app is deleted, and it will enter DFU mode either way. 
 
 BR, 
 Edvin

Edvin · Answer

I believe the limitation comes from the fact that most of our users use the softdevice, and it is a bad idea to update the bootloader and app without updating the softdevice, because updating the bootloader often comes with a version update, so you should update the softdevice so that the BL and SD are not incomatible. 
 In your case, if your bootloader doesn't use the softdevice, this requirement doesn't really make sense. But as I mentioned, there is literally no difference between having the BL and APP in the same packet or two. The only difference is that you need to do "nrfutil dfu serial -pkg ..." two times instead of one. It doesn't take longer time, as it is the same amount of data that needs to go through, and the end user will probably not notice a difference, if you are doing this from a custom app or some sort of script either way. 
 
 BR, 
 Edvin

Edvin · Answer

52=n*4, where n = 13, so that is fine. 
 If you want to skip this part, you can adjust the bootloader to pad the remaining 1, 2 or 3 bytes with 0xFF. It is probably better than just asserting. 
 
 I discussed the MTU_SIZE/2 fix with the colleague who wrote the DFU_Master application a few years ago, and we figured out that the reason faulted now is a change in the bootloader. Before, it would gather up several packets, and do a big write containing more packets. The default behavior now is that it writes to flash after every package, which is why it failed. 
 We also looked at the buffer size, and found the reasoning behind why it was divided by 2. 
 If you look in the bootloader, you will find: 
 #define RX_BUF_SIZE (64) //to get 64bytes payload
#define OPCODE_OFFSET (sizeof(uint32_t) - NRF_SERIAL_OPCODE_SIZE)
#define DATA_OFFSET (OPCODE_OFFSET + NRF_SERIAL_OPCODE_SIZE)
#define UART_SLIP_MTU (2 * (RX_BUF_SIZE + 1) + 1) 
 So the reason behind this is that the "SLIP" encoding will sometimes have to add an extra byte in cases where the actual payload byte is the same as the END or ESC character in the SLIP library. 
 Hence, it needs to double the buffer size. On the last line there, you can see that we take the RX_BUF_SIZE+1, which would be the actual buffer + one byte (I don't remember. It could be the byte indicating the length or something). Then double it, in case all bytes are escape or end characters (which in theory could happen, but probably won't happen). Then you add 1 in the end to account for the actual end byte of the buffer. So you end up with a buffer size of: (2 * (64 +1) + 1 ) = 2*65 + 1 = 130 + 1 = 131 bytes. 
 So in order to do the exact opposite of this, you can use: 
 MAX_ACTUAL_PAYLOAD = (((MAX_MTU - 1) / 2) -1) 
 which will be 64. So if the payload buffer is maximum 64 bytes, it should always be safe: 
 #define MTU_SIZE 131
#define MAX_ACTUAL_PAYLOAD (((MTU_SIZE - 1)/2) - 1) // = 64 bytes. 
 Note that MTU_SIZE is also increased to 131, which corresponds to the actual MTU size of the UART buffer in the bootloader from SDK17.1.0. 
 
 Best regards, 
 Edvin

nrf52832 OTA over ESB based on SDK17.1.0

Top Replies