Migration from NRF52832-QFAA to NRF52832-QFAB

[DineshB]

Hello NRF team,

We have been using NRF52832-QFAA based dev kit from Sparkfun, which has 512KB Flash / 64KB SRAM. I developed the app on Arduino whereas I flashed the bootloader (which I compiled separately as per the pin assignments) + soft device through the NRF-DK, using the SWD port. All of these steps were fine.

We then fabricated some sample boards, but accidentally we ordered and mounted the NRF52832-QFAB (instead of the QFAA). We realized that the QFAB only has 256KB Flash / 32KB SRAM. Obviously the bootloader which was meant for the QFAA didn't pass through the nrfutil to load on to the NRF chip.

So, what we did was,

1. In the bootloader source files, specifically in the linker script, this is what we get for the NRF52-QFAA

FLASH(rx) : ORIGIN = 0x7A000, LENGTH = 0x4000

RAM(rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

NOINIT(rwx) : ORIGIN = 0x20007F80, LENGTH = 0x80

BOOTLOADER_SETTINGS(rw) : ORIGIN = 0x0007F000, LENGTH = 0x1000

UICR_BOOTLOADER(r) : ORIGIN = 0x10001014, LENGTH = 0x04

MBR_PARAMS_PAGE(rw) : ORIGIN = 0x0007E000, LENGTH = 0x1000

UICR_MBR_PARAM_PAGE(r) : ORIGIN = 0x10001018, LENGTH = 0x04

We changed this to:

FLASH(rx) : ORIGIN = 0x3A000, LENGTH = 0x4000

RAM(rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

NOINIT(rwx) : ORIGIN = 0x20007F80, LENGTH = 0x80

BOOTLOADER_SETTINGS(rw) : ORIGIN = 0x0003F000, LENGTH = 0x1000

UICR_BOOTLOADER(r) : ORIGIN = 0x10001014, LENGTH = 0x04

MBR_PARAMS_PAGE(rw) : ORIGIN = 0x0003E000, LENGTH = 0x1000

UICR_MBR_PARAM_PAGE(r) : ORIGIN = 0x10001018, LENGTH = 0x04

2. We flashed this new bootloader along with the softdevice 132. Based on the size of the softdevice, are there any restrictions on what SDs we can flash on to QFAB?

3. When you use the nrfutil to flash the bootloader and the softdevice, I observed that we give the family type as "-f nrf52". I am wondering, if the tool programs the hex files to predefined address map for the QFAA instead of QFAB?

4. Are there any settings / memory map on how to change the RAM addresses for the linker (for the bootloader), for 32KB RAM?

5. Also I believe when you compile your application source code, these address mappings should be changed on the compiler / linker level, so your app would know where to go and sit on the flash memory map and where to load on the SRAM?

6. Is there a NRF preferred Arduino like development platform on which I can port my code over and compile them, and load them on to NRF using the serial DFU? Well, I believe on this platform, I should be able to select the QFAA/QFAB variant and then compile the code accordingly.

The new design with QFAB, we managed to flash the soft device + bootloader (modified as per the changes given above). 

However, when we try to program the board over DFU, the board goes into DFU mode (where it starts blinking the DFU_LED). However, when we try to program the app using the Serial port, it wouldn't go through. Looks like the NRF is not responding to Serial flashing of the app (from the Arduino). 

Note : the same procedure works with QFAA (with the correct bootloader).

So I would need your help to figure out what changes are needed to migrate from QFAA to QFAB.

regards,

Dinesh.

[Jørgen Holmefjord]

Hi,

1. These changes looks correct for QFAB variant.
2. No, as long as you can fit the softdevice in the chip variant, there should be no limitations to the version. See the compatibility matrix for revision and SDK/softdevice support.
3. The family parameter is used to determine flashing algorithm, as this can vary between chip families. The Intel hex format depicts the location where the application will be stored in flash.
4. You have already changed the size of the RAM in your linker script from 0x10000 (64kB) to 0x8000 (32kB):
   

   RAM(rwx) :  ORIGIN = 0x20002C00, LENGTH = 0x5380

   
   See the tutorial Adjustment of RAM and Flash memory for more details on how to modify these parameters.
5. Yes, the length/size of the application needs to be modified/reduced accordingly. RAM is normally not utilized by bootloader and application simultaneously and can use shared (same start and size/length address).
6. The only officially supported development platforms are nRF5 SDK and nRF Connect SDK. None of these are very Arduino-like, but if you are developing a commercial product, I would highly recommend that you use one of these over Arduino.

However, when we try to program the board over DFU, the board goes into DFU mode (where it starts blinking the DFU_LED). However, when we try to program the app using the Serial port, it wouldn't go through. Looks like the NRF is not responding to Serial flashing of the app (from the Arduino). 

Note : the same procedure works with QFAA (with the correct bootloader).

I do not know how the Arduino bootloader works, but it could be as simple as it does not have enough space in the chip to perform the DFU. Some bootloader requires dual-bank DFU, which means that the old application is not deleted until after the full new application is received. This requires about 50% more flash space than single-bank updates.

Not sure how much this helps you, but as long as you are using Arduino, we do not provide much support, as this is not developed by Nordic. You may check with the developers of the Arduino libraries you are using if they have any suggestions.

Best regards,
Jørgen