How to use custom board revisions in application code?

[ilockit_CFR]

Hi,

I use Nordic connect SDK and have to create a new revision for a custom board, because there are some hardware changes. I managed to create an overlay for the new revision where I could add some pins, which were added in the new revision. I also can use these pins in my application if I compile it for the new revision. My question is now, how do I exclude these pins in the old revision with minimal impact on the source code. I tried setting CONFIG variables in a defconfig file, but that didn't work. What is the best practice and how should the revision files be used so that the application can work with all revisions?

Best regards,

Christian 

[Sigurd Hellesvik]

Hi,

Does the new revision use different pins for one feature, or does it add a new feature with some pins that were not used from the original revision?

Regards,
Sigurd Hellesvik

[ilockit_CFR]

Hi, 

thanks for the reply. It's a bit more complicated as I thought before. We have a new revision of the board with some minor general changes, e.g. the change of pin assignment of already existing pins. 

In addtion to that there're assembly variants of the pcb, e.g. a CAN bus controller which can be equipped or not. This uses new pins. 

And we have assembly variants were already existing pins are repurposed. We have a LED/button combination which can be exchanged for a fingerprint sensor. This means, the button/LED pins are now used for UART communication with the fingerprint sensor. 

The combination of these features should be as free as the SOC allows. 

At the moment I created a revision overlay file, which contains the generals changes to the new pcb design for all subsequent variants. Additionally, I create overlay files for each optional hardware feature. As I understood the documentation the overlays can then be set independently when I set-up a build configuration. 

Is that approach correct? And where do I define some macros for the used hardware overlays, which can be used in the source code to include/exclude features like CAN bus or fingerprint sensor?

Best regards,

Christian

[Sigurd Hellesvik]

ilockit_CFR said:

At the moment I created a revision overlay file, which contains the generals changes to the new pcb design for all subsequent variants. Additionally, I create overlay files for each optional hardware feature. As I understood the documentation the overlays can then be set independently when I set-up a build configuration. 

Is that approach correct?

I think it does. However, I will list how I would do it, and then you can say if that approach matches what you need or not:

If practical, I would give different revisions to boards with different peripherals, to simplify the system.

Then I would add overlays and deconfig to the board files per revision. See Board revision configuration adjustment. For example if my custom board was named "urd":

• urd_nrf52833_0_1_0.overlay
  • can node has `status="disabled"`
• urd_nrf52833_0_1_0-pinctrl.overlay 
  • Must be included in the normal overlay
  • Changes pins
• urd_nrf52833_0_1_0_deconfig
  
  • Has CONFIG_CAN=n

• urd_nrf52833_0_2_0.overlay
  • can node has `status="okay"`
• urd_nrf52833_0_2_0-pinctrl.overlay
  
  • Must be included in the normal overlay
  • Changes pins
• urd_nrf52833_0_2_0_deconfig
  • Has CONFIG_CAN=y

Then in the project, you can filter on CONFIG_CAN. In .c files you can do "#if defined(CONFIG_CAN)" and in CMakeLists.txt you can use "if(CONFIG_CAN)".

Since pins change in the pinctrl, the driver for those specific pins should be the same for each version, so you should not have to do anything in source code for this.

PS: You can use ".dts" files instead of ".overlay" files if you want to overwrite original revision instead of overlaying it.

[ilockit_CFR]

That was my first idea and it worked well. But then I noticed, that I have to create a lot of revisions for all possible combinations of hardware peripherals, for exaple: 

1. led switch
2. led switch + can
3. led switch + can + gps
4. led switch + gps
5. fingerprint
6. fingerprint + can
7. and so on...

So I would prefer an approach where I can configure the build process according to the underlying hardware. 

According to your example I have

• urd_nrf52833.dts
• urd_nrf52833_0_1_0.overlay
• urd_nrf52833_canbus.overlay
• urd_nrf52833_fingerprint.overlay
• urd_nrf52833_gps.overlay
• and maybe more, if our hw developer has more ideas ;)

Can I create defconfig files for the overlays, too? Is it possible to create my own CONFIG_ variables? I tested it once and the compiler said, that it was unknown.

[Sigurd Hellesvik]

ilockit_CFR said:

• urd_nrf52833.dts
• urd_nrf52833_0_1_0.overlay
• urd_nrf52833_canbus.overlay
• urd_nrf52833_fingerprint.overlay
• urd_nrf52833_gps.overlay

Ideally, how would you like your build command to look for for example 0.1.0, fingerprint and CAN?

I think what you are asking for are File Suffixes.
Not sure exactly how that would work yet. I will look more into it later, but wanted to give you the idea first.

Alternativley, I find some reference to Custom revision.cmake files, which indicates that you can make more custom revision stuff, right?

ilockit_CFR said:

s it possible to create my own CONFIG_ variables?

Yes, you can do that in Kconfig files. See for example here

[ilockit_CFR]

Thanks for your suggestion, but I must admit that I haven't fully understood the concept of these file suffixes. At the moment I add the required overlays and Kconfig fragments when I create a build configuration with VS Code. I think that is working well enough at the moment. But I will take a look at the file suffixes, maybe it can simplify the build process.

Thanks for your support.