Single FW Binary to run on Multiple Atmel MCU models - Page 1
Forum section: electronics / general

author: Nick Novak
author_rank: Contributor
timestamp: August 27, 2018, 05:57:45 pm
content: I’m currently loading the same firmware binary on multiple device types with different hardware add-ons and switching capability on and off at run time. I’d like to add another device to the family using a different MCU and maintain the binary compatibility. The MCUs are obviously very similar Atmel SAMR21E18 vs SAMR21G18, which is just a larger package.I’m pretty confident this will work from a field update / binary perspective. I’ll build for the G18 and refrain from accessing hardware that isn’t there on the E18, although I expect the registers are in place.The difficulty I see though is trying to debug on the E18, using the E18 headers many of the G18 defines will be missing so my code wouldn’t build. If I build for the G18 Atmel Studio wont connect to an E18.Does anybody have any experience doing something like this and want to share their tricks? With Atmel’s toolset ideally.Is there a way to pull in the G18 headers explicitly and convince studio that its targeting an E18 chip? Or maybe I need my own header that adds the missing G18 defines.Nick

author: westfw
author_rank: Super Contributor
timestamp: August 27, 2018, 07:08:48 pm
content: If you refrain from accessing hardware that isn’t there, why would you code not compile due to “missing definitions?”

author: TomS_
author_rank: Frequent Contributor
timestamp: August 28, 2018, 07:07:55 am
content: Perhaps you need to use preprocessor directives (#ifdef et al) to include or exclude certain bits of code based on the target platform, like platform specific headers and code?Although that may go against your single universal binary approach.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 28, 2018, 09:26:14 am
content: Surely the answer is to just build and debug for the largest package, assuming it's a superset so you can just avoid using the bits that aren't on the smaller one ?

author: mikerj
author_rank: Super Contributor
timestamp: August 28, 2018, 10:16:02 am
content: Quote from: mikeselectricstuff on August 28, 2018, 09:26:14 amI think the OP's problem is that he may want to attach a debugger to a design that uses the smaller micro, in which case Atmel Studio will no doubt have a fit as the Device ID won't be correct.I've not used any of the later versions of Studio, would it be possible to change the target device to the smaller one and connect the debugger without re-building or downloading the binary to the target?

author: cv007
author_rank: Frequent Contributor
timestamp: August 28, 2018, 12:16:52 pm
content: mv e18header.h e18header.h.bakcopy g18header.h e18header.h

author: mikerj
author_rank: Super Contributor
timestamp: August 29, 2018, 08:24:45 pm
content: Quote from: cv007 on August 28, 2018, 12:16:52 pmMight be possible but typically a whole family of devices will share a common header with different sections inside enabled when the compiler defines a symbol relating to the target device.

author: cv007
author_rank: Frequent Contributor
timestamp: August 29, 2018, 09:42:51 pm
content: it appears the differences are in the pio header, and it looks like the only difference is simply the added pin names to the g18mv (or ren) pio/samr21e18a.h pio/samr21e18a.h.bakcp (or copy) pio/samr21g18a.h pio/samr21e18a.hthe headers one level up have the same two names, but are identical (except for DEVice ID), and then include the specific pio headerso the above rename will have the e18 including the g18 pio header with the additional pin defines(could also simply change the include line in the base e18 header to include the g18 pio header instead, tomAto tomOto)edit-you may also be able to add to the global build options-U__SAMR21E18A__ -D__SAMR21G18A__or __ATSAM..., not sure what is usedthen no files need changing