Migration from NRF52832-QFAA to NRF52832-QFAB

RE: Migration from NRF52832-QFAA to NRF52832-QFAB

Jørgen Holmefjord — Fri, 22 Jan 2021 09:08:09 GMT

[quote user="DineshB"]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 ?[/quote]

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.

RE: Migration from NRF52832-QFAA to NRF52832-QFAB

DineshB — Thu, 21 Jan 2021 21:38:24 GMT

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.

RE: Migration from NRF52832-QFAA to NRF52832-QFAB

Jørgen Holmefjord — Thu, 21 Jan 2021 14:48:12 GMT

Hi,

These changes looks correct for QFAB variant.
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.
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.
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.
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).
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.

[quote user=""]

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).

[/quote]

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