This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

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,

Red

Blue

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!

  • Couldn't you just let the user input which case he/she is using in the app? Would be a lot easier than what you are suggesting.

  • Hi there~. My client doesn’t want that scenario; the user has to scroll/search 40 items to choose the purchased car, an inconvenient scenario for the user.

    If the user bought 5 different types of RC cars, the user have to choose the covering case 5 times with the mobile app!

    Maybe creating a custom jig that reads the nRF52840’s 64-bit chip id with UART and sends it to a database is my next idea.

    Is there a better solution?

  • Will it be possible to buy different covering cases for one car chassis? By this, I mean does the nrf52840 need to recognize the covering case only once or multiple times (i.e. if you change covering cases for example).

    One idea I have is to have some kind of QR scanner on your nrf52840 and have different QR codes on the different covering cases. But this would probably be quite expensive. I would recommend something similar to this, just cheaper. Some kind of cheap sensor that you can attach to the nrf52840 that will be able to tell the difference between different covering cases. That way, if your client wants more covering cases, it shouldn't be an issue at all.

  • Holy cow! You have opened my blinded eyes, Bjørn!

    does the nrf52840 need to recognize the covering case only once or multiple times

    Only once! The client didn't intend to change covering cases. The blue truck stays as the blue truck always. :D

    Some kind of cheap sensor that you can attach to the nrf52840 that will be able to tell the difference between different covering cases.

    I will get rid of the USB feature and replace it using a serial flash memory!

    nRF52840 supports QSPI, so I will tell the serial memory vendor to pref-flash data related to the covering case and other data for the user before delivering the flash ICs.

    You are a live saver, Bjørn! :D

  • However, it will best when the nRF52840 MCU can solve my problem by not relying on external sensors or serial memories. I thought there might be a firmware solution to solve my problem so I can get rid of the external memory.

    For instance, (1) can I set a 64-bit value(data related to the car) in the nRF52840's flash using fstorage or other features from Nordic's SDK? I want to set this value in the flash memory and I want this value to be unchangeable, whether I flash a new firmware using J-Link or BLE OTA.

    (2) use other features like Crytocell or Trustzone (I'm not sure if these are used for my purpose)

    Or (3) Nordic/IC distributor flashes the 64-bit value on flash or register before delivering (this might be the worst choice for both of us)

    Using only the firmware, can my problem be solved? Or adding an external IC(sensor, memory, etc) is inevitable?

Related