I am developing a product that uses the Atmega328P (currently using Arduino nano as the development board). I would like to keep the software private, but also have the option to update it during the products life-cycle.

the way i am currently thinking is programing the 328P using ISP and locking the relevant fuse bits to prevent reading. I don't want to use the DIP version (based on potential customer base feedback, it looks cheap and outdated WRT other forms like TQFP, unfortunately this is actually important enough to warrant a design change) .

Can i use a TQFP with a mounting like this, and then have the user be able to take the chip out to replace it with one that has an updated software? or is this not feasible (is it stable enough inside a socket and not soldered to pcb, is it too difficult for normal person to swap, or the possibility of damaging the chips or putting it in wrong are high, these are my concerns.)?

Also, my plan is to use a potting compound for the PCB/case and have it go around the perimeter of the previously mentioned socket and about 3/4 of the socket height due, to the thermal/vibrations stresses in the environment.


2 Answers 2


A couple of things.

  1. I assume you mean "DIP" not "PID" for the existing package.

  2. That socket you link to is not for mounting TQFP, it is for PQFP packages, also a very old package.

In my opinion, there isn't a good socket for TQFP packages, any you find will be expensive, have a large footprint and be unreliable - especially if you have much vibration.

If the change is just because customer opinion - what are they requesting?

Physically changing the device is an outdated method of performing updates - you need a mechanism for downloading an update into your product with no physical changes required.

You may want to keep the hardware Arduino compatible for ease of software development. Since you will need a serial port (or equivalent to download updates) there will be essentially no extra hardware required.

You can encrypt the image and have the bootloader decrypt so keeping your security. There are multiple options for a secure bootloader.

  1. Microchip has an application note covering one that supports AES (you may have to use the AVR studio framework to use it): AVR231: AES Bootloader

  2. This one looks interesting as it is very small: One-Way-Loader

  3. Just Google "encrypted bootloader avr" for more options.

  • \$\begingroup\$ Ha! We both answered within a few seconds of each other, to the same extent that no, physical replacement is bad, and you even addressed the misunderstandings OP had. So, have my upvote! \$\endgroup\$ Jun 23, 2019 at 19:21
  • \$\begingroup\$ Yes, i meant DIP. thanks for the feedback, i will look into how to use a encrypt/decrypt Arduino sketches using a bootloader. so much better then a physical swap (I'm a mechanical engineer, recently started working on electrical) \$\endgroup\$
    – haxxor
    Jun 23, 2019 at 19:21
  • \$\begingroup\$ @haxxor then, please, edit your question and fix the typo :) \$\endgroup\$ Jun 23, 2019 at 19:22
  • \$\begingroup\$ @MarcusMüller - Thank you, I have returned the compliment. I agree with you that using an ARM processor would be good - the main complication I've had when going from AVR to ARM is interfacing with existing 5V hardware. \$\endgroup\$ Jun 23, 2019 at 19:32
  • \$\begingroup\$ @KevinWhite for existing 5V applications: NXP sells a lot of mechanical control system oriented ARM MCUs. See: their Kinetis E series. \$\endgroup\$ Jun 23, 2019 at 19:38

thermal/vibrations stresses in the environment.

directly contradicts

have the user be able to take the chip out to replace it

Clearly, if you need potting for your components, you don't want your user to be able to take out parts.

You'd normally just do this with a firmware update routine built into the firmware you deploy. For example:

  1. Your firmware has a period of time after boot during which it waits for a specific word (like "HELO") to appear on one of its UARTs
  2. When that word appears, a firmware download starts: the software on the other end of the UART sends the new firmware image. Your firmware calculates the checksum of that.
  3. If the downloaded firmware is valid, your firmware overwrites the firmware in the MCU's memory with that.

In step 2., you'd typically also check for a valid cryptographic signature (you can embed the public key to the private key only you know in the original firmware itself), and check for transfer integrity with checksums. If you really consider your firmware to be secret, you'd even encrypt it before sending it to the user, and you build the decrypter into your firmware. The decryption could be done directly after download, or when loading the firmware from non-volatile memory to RAM at boot. (that's interesting if you want to store the downloaded firmware in an external memory IC.)

That way, no exchangeable hardware is needed, without compromising confidentiality.

All you need is:

  1. a serial interface that you expose to the user (no exchangeable/moving parts!)
  2. enough temporary storage to store the firmware image while it's being downloaded, for verification,
  3. and enough non-volatile memory to store a bootloader + firmware

This is a very standard way of doing that, so real-time operating systems (and other OSes for MCUs, for example Chromium OS) have built-in facilities to allow exactly that.

It's unnecessarily hard to implement that on an ATMega328; there's just very little protected memory on that MCU. Maybe get something where a complex firmware actually fits, and where it's realistic you can run reasonably complex cryptography on it. A cheap ARM Cortex-M (for example, the very popular STM32 family) could both safe you money in comparison with the ATMega328 and be much, much more powerful than that.

  • \$\begingroup\$ This is good to keep in mind for a much more complex version later on. my device is strictly used to control a mechanical system, i wanted to keep the electronics/software as simple as possible. i think going down this road would be too much for the gains i would get. \$\endgroup\$
    – haxxor
    Jun 23, 2019 at 19:27
  • \$\begingroup\$ um, no. As said, if your environment requires you to pot components, using a socket simply is no option. So, there's no alternative to firmware updates. \$\endgroup\$ Jun 23, 2019 at 19:37
  • \$\begingroup\$ Potting is not a requirement, its more additional layer of protection/reliability. others have done products in a similar environment without the need for potting (automotive) . \$\endgroup\$
    – haxxor
    Jun 23, 2019 at 20:17
  • \$\begingroup\$ yeah, but if you even think about potting enhancing your reliability, you will quickly disregard the idea of having a socketed chip. It's really like not being sure whether you need a tank or just an armored vehicle, but then also installing a sunroof. \$\endgroup\$ Jun 24, 2019 at 5:57
  • 1
    \$\begingroup\$ yeah, I mean, a high-stake system will probably not use stock ATMega328's readout protection, since that has been shown in the past to be circumventable by a skilled reverse engineering engineer. \$\endgroup\$ Jun 25, 2019 at 9:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.