Code working on 52832_xxAA - but not xxAB ?

[MDF]

using NCS 1.9.1 - Zephyr - Segger Studio - sample code: bluetooth / peripheral_uart

I based my project on the sample, modified it slightly and it works well on a board with nRF52832_xxAA - trying the same code on a 52832_xxAB brings up the error : bt_settings: settings_subsys_init failed (err -33)

According to SES the output for zephyr.elf is : code = 171 kB and Data+RO = 55 kB - so this should run on both version AA and AB, right ?

I've seen no warnings or errors when loading the code into the chips, I also tried J-flash, but same result.

The NCS/zephyr project configuration seems to make no difference whether the target is AA or AB - am I missing something ?

thanks, Matthias

[Jørgen Holmefjord]

Hi,

Which target board/device are you building for? The chip variant is given in the devicetree in Zephyr/nRF Connect SDK. For instance, for the nrf52dk_nrf52832, the nrf52832_qfaa.dtsi file is included in the board dts file. There is a separate nrf52832_qfab.dtsi file available that can be use used with nRF52832_XXAB variants.

Although the size of the application can fit in the flash/RAM of the device, does not necessarily mean that the linker have placed the location of objects in the available address range. You can configure the build system to place certain sections in specified parts of flash/RAM, for instance place constants in a known address in flash, or place the stack/heap area in top of RAM. You can check the map file for the build (build\zephyr\zephyr.map) to see where the parts of the application is stored in flash/RAM.

The application may also decide to store data in specific locations in flash/RAM, which seems to be the problem in your case. The settings subsystem will likely try to store/read data at a specific location in flash (often based on configurations from the build system or chip type).

Please make sure you build for the correct chip variant. If this does not solve the problem, we will help you debug it further.

Best regards,
Jørgen

[MDF]

there is no "board dts file" - the only thing I can find is a "zephyr.dts" file and it seems that this is built whenever I compile my code.

However, I can find this here in this file

       compatible = "nordic,nRF52832-QFAA", "nordic,nRF52832", "nordic,nRF52", "simple-bus";

I searched in KConfig and found something in "Hardware Configuration > nRF52x MCU Selection" : there I can select between QFAA and QFAB - is is appropriate to select the proper board here ?

If yes - and with all the DTS and other things Nordic is doing right now to disconnect my code from the hardware - why does Nordic think its a good idea to put QFAA and QFAB into the same build branch, despite the fact that memory size is a critical difference between these two targets ?

matthias

[Jørgen Holmefjord]

MDF said:

there is no "board dts file" - the only thing I can find is a "zephyr.dts" file and it seems that this is built whenever I compile my code.

Yes, this is in your build folder. The board files are defined in Zephyr, for instance the board files for the nrf52dk_nrf52832 board. If you are using a different board than the DK, with other components, you need to define your own custom board files to match what you are using. See Custom boards in the SDK documentation and have a look at this webinar.

MDF said:

I searched in KConfig and found something in "Hardware Configuration > nRF52x MCU Selection" : there I can select between QFAA and QFAB - is is appropriate to select the proper board here ?

I don't think this will be sufficient, you would also need to create the custom board files as this is separate from the Kconfigs. 

MDF said:

why does Nordic think its a good idea to put QFAA and QFAB into the same build branch, despite the fact that memory size is a critical difference between these two targets ?

Not sure what you are referring to here. If you build for the nrf52dk_nrf52832 target, this board only comes with the QFAA variant of the nRF52832 chip. If you have a custom board, you need to follow the documentation in order to build for the correct chip variant on your board.