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.

[DineshB]

Hello Jorgen,

Thanks for your quick response detailing the process.

I would change the IDE to the one that you have proposed, and hopefully I can port my codes on to this IDE without too much of a hassle.

We ordered the 512KB/64KB QFAA version, and will rework the boards, which will get us to the finish line quickly. This only a prototype stage, so for the next stage, I will have some time to port over to an SDK that you have suggested.

I too believe, probably its related to dual-bank DFU. I believe there are enough sample codes on the SDK, for me to try out. I am interested in the BLE UART , where a mobile phone / Tablet or PC would connect to the NRF (without pairing) and send / rx commands and status.

Just another one quick question, what power modes are supported by the NRF with your SDK and libs? Do they have low power modes where the current can potentially be in the range of uA ?

Thanks again for your in-depth explanation provided below.

regards,

Dinesh.

[Jørgen Holmefjord]

DineshB said:

Just another one quick question, what power modes are supported by the NRF with your SDK and libs? Do they have low power modes where the current can potentially be in the range of uA ?

The SDKs support both System ON and System OFF idle mode. The base current consumption in these modes are given in "Current consumption, sleep". System ON is the default idle mode used when the chip is active (for instance between BLE events). whenever the CPU does not have any tasks to do, this mode is entered in a while loop in main(). System OFF is the lowest power mode, where all clock sources are turned off. Wakeup from System OFF can only happen due to an external event, as described in above link (GPIO, NFCT, LPCOMP, RESET). For BLE applications, we have a Online Power Profiler, where you can enter your configurations and get the average expected current consumption.