Questions when mass producing a custom PCB and firmware that has similar functionality and different device info

[Matthew K]

Hi there~. This is Matthew! I saw a thread explaining that the production variants of the nRF52840 will first be available Q4 2017 at this link.

I was planning for BLE RC Car mass production that uses nRF52840 in the next year 2018. This RC Car uses the USB to store user's custom data so I chose the nRF52840. Also, the car will be controlled by a mobile BLE app. The app is also used for OTA firmware upgrade.

This is my concern; I have to produce RC cars that have 40 different covering cases.

All RC cars will have the nRF52840 on it to control motors but as shown from the example images,

on top of the PCB, a red case, orange case, blue truck case will be mounted on each PCBs. Although the outer cases are different, each RC Cars will use the same battery input (4 AA batteries in series). After the RC car pairs with the BLE mobile app, the app is planned to distinguish what car cover is used.

The point is that the control part or the BLE service part of the firmware is identical, regardless of covering cases.

The problem is what trick or technique is needed to make the firmware/mobile app to distinguish what case it is using.

This is my first idea. Since I have 40 different covering cases, I have chosen 6 GPIO input pins (2^6=64 > 40) and connected them to 3V and GND.

The firmware reads the GPIO pins and sends the read value using BLE's NUS or DIS (Device Info Service, set the system id or HW revision string as the GPIO value).

However, I expect that this forces to make me take 40 times of FCC/CE certifications due to different HW connections. Even worse, if my client asks me to add extra series of covering cases, 6 GPIO pins will not be enough!

Will there be a better way to solve this problem like using CRYPTOCELL or flashing an ID into a place that is not affected by OTA firmware update?

I just want to create one Keil/SES project, not 40 or more!

Or is it not possible to create multiple projects or bypass multiple certification processes?

THANKS FOR READING THIS!

[RK]

you can use the same method you use for programming the chip (SWD) to write data into the client-use NVRAM. So at the point you decide what the body is going to be, you write a byte or a word of data into that location with a JLINK type device and then you seal the product up.

There are other ways, you could program your firmware if the body type hasn't been set to advertise a special characteristic, you then write to that characteristic once, store that in NVRAM, reset the device and now you have a programmed car.

[Matthew K]

Hi there~ I haven't understood your methods which uses the NVRAM (I guess you mean Non-Volatile RAM). I mean, is there any NVRAM in the nRF52840 or are you mentioning the RAM retention/to add external NVRAM and flash that external NVRAM with the J-Link?

I think I have nearly figured out your 2nd method. For example,

non-configured device advertises the DIS service

|

the mobile app and the non-configured device pairs

|

the user choose the car type with the mobile app (or use other scenarios)

|

this device now advertises NUS to tell it is a configured device and write the NVRAM (I still didn't understand the NVRAM part though)

What a clever idea! You were meaning something like this, right?

[RK]

Well you could write to a given place in flash or to the UICR which has some space for customers to hold non-volatile data.

[Matthew K]

Wow, that's great, RK! I have one concern. Wil the written value (in flash or to the UICR) change after I update the firmware using BLE OTA or J-Link?

The mobile app supports BLE OTA, so I was concerned which flash memory address would not affect the value.

Considering the OTA update, will this flash/UICR method work?

[RK]

no - the UICR persists across OTA updates.