Is there any way to automate hex generation process on atmel studio????

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello Guys, 

I'm generating hex using Atmel Studio 7 and while doing mass production i have to go through the process x no. of times.

 

Actually the code just differ by one code of line:

 

#define Device_serial "DEMOxxxxx001"

 

if i have to do for 100 devices , i have to iterate the process 100 times just by changing "DEMOxxxxx001" to "DEMOxxxxx002"......and so on till "DEMOxxxxx100"

 

is there any kind of workaround for such situation..

 

please can anyone help on this?

This topic has a solution.
Last Edited: Wed. Oct 21, 2020 - 09:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Can't you put that in the EEPROM instead? It would be fairly trivial (I'd probably choose Python) to write a script that pumps out a hundred idNNN.eep files and then after programming a single, common .hex into all units you can serialize them by just then programming in the right identity to EEPROM.

 

Anyway, if you want to script the AS7 build note that AS7 (because it's really VS2015) can be invoked with command line parameters to perform a build (then closes down when done). You'd just need a bit of scripting around this (again, probably Python) to regenerate the one line .h file that has the #define before each invocation of AS7

 

Simply run:

C:\Program Files (x86)\Atmel\Studio\7.0>AtmelStudio.exe /?

C:\Program Files (x86)\Atmel\Studio\7.0>

to see:

 

 

where all the command line options are described.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, there are post-build events, you could write a script to make the change after each build.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
doing mass production

A production programmer should be able to cope with stuff like adding serial numbers to the hex

 

AN2468: Production Programming of Microchip AVR and SAM Microcontrollers

 

https://www.microchip.com/wwwApp...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how exactly i can achieve this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your programmer and chip is supported by Microchip MPLABX IPE then you can use Serial Quick Turn Programming (SQTP).

 

SQTP (serial quick turn programming) is used to program a unique serial number into each device. This number can be used as an entry code, password or ID number.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson....you have helped me a lot during my whole fota project..

 

this is the last segment of my fota project...

 

here like i have said i want to generate n no of hex...and the device serial will be somewhere sitting in a csv file

and i can use to update device serial in code and generate n hex.....

 

and also with that at the output side it should generate srec binary file with 16 bit crc(the method you suggested).... so i don't have to run command on every hex

 

is all this possible????

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you considered what I said in #2 about serializing the devices separately (EEPROM) so there'd be one common code then all that changes for each unit programmed is an initial value programmed into EEPROM from a .eep file.

 

Any other option, where the serial is in the "code" is going to involve actually full regenerating each .hex or at least editing a master .hex to put the serial number into it.

 

I'd go with EEPROM myself but if your heart is set in using HEX then I'd do it in Python, read the "master" copy of the code image HEX file in, just update the one record where you have the serial number, regenerate the checksum on that line and then write back out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i cannot rely on eeprom as in one of my functionality --- factory reset 

I'm clearing my eeprom..

 

i think the python alternative would be better... can you brief me on this???

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why not have a command you can use to set the serial number & other calibration parameters after the code is burned in?  In that case the code does not even know what these values are...they are set & saved after the program is flashed.  This would be used when you have a terminal or PC calibration/technician station hooked to the unit.

 

Some of the newer atmel chips have a built in serial number (actually a unique number)...can you use one of those?

 

during my whole fota project.

fix only the annoyances? 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Well Python has this available:

 

https://pypi.org/project/IntelHex/

 

there's a build it yourself manual for that but you can read the individual bits at:

 

https://github.com/python-intelh...

 

this allows you to read the whole of a .hex file into python then manipulate the data. But to be honest this could actually be ovekill for what you want to do. Say I had a master code that did:

#include <avr/io.h>

__attribute__((section(".serial"))) const uint32_t serial = 0xDEADBEEF;

int main(void) {
	while (1) {
	}
}

and I build this with something like:

 

 

then the .hex file looks like:

 

The place where the serial number lives stands out like a sore thumb. I deliberately set it to be at word address 0x3FF0 which is byte address 0x7FE0. I could "find" it in the HEX file if I just read itin as a text file in several ways. One is I could look for a record where the 4 address bytes are "7FE0". Another would be to look for the data sequence 0xDEADBEEF - that's not a real serial number but merely a "placeholder" that makes the item easy to find. In fact, because the AVR is little endian what I should have put in the C code was:

__attribute__((section(".serial"))) const uint32_t serial = 0xEFBEADDE;

which is "DEADBEEF" with the hex pairs in the other order. Then in the .HEX file I find:

 

 

where it's much easier to spot. If I simply opened this file as text in python I could read it line by line until I find the line where the 10th character is 'D', the 11th is 'E', the 12th is 'A' and so on. Either using "7FE0" in characters [3]..[6] or "DEADBEEF" in [10]..[17] I know I have the right line. 

 

The one tricky bit of changing the line is the last two digits (0x65) - that is the checksum for the line. As explained at:

 

https://en.wikipedia.org/wiki/In...

 

the checksum is simply the 8 bit truncated sum of all the other hex pairs in the line made 2's complement. So if I were reading this file in Python and I came across the 7FE0/DEADBEEF line I could replace the DEADBEEF with my preferred serial number and then just run a quick process over the line to add up all the bytes (except the last) and 2's complement that (subtract lowest byte of sum from 0x100) and then replace the final 65 with this new value. Then write out this new line (just as you have been writing out all the previous lines encountered) and then continue to do this for any lines after this.

 

At the end of the process you have a new .HEX with that one line changed. Now you just have to program it into a unit then rinse/repeat.

 

Of course somewhere you need to keep a list of numbers used or (by implication) "next number to be used" and that too has to go as an input to the Python process.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi clawson...

 

here in the memory setting how you have defined the  .serial at some specific  memory location...

my appcode hex size will vary as per the application...in such case will the fix addressing will work?

 

In my case i have defined serial no in demo.h file...


  #define SERIAL_NO "DEM02G0920110009"

inside the hex:

 

:1070EC004D205061636B65742053697A652025646B
:1070FC000D0A0044454D3032473039323031313091
:10710C0030313500646174612052656164204164E2

the highlighted part represent the serial number...

Last Edited: Tue. Oct 13, 2020 - 09:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well my idea was to position the serial number data at some high (and fixed) address in the flash image so it was well out of the way of the code itself but easily locatable in the HEX.

 

In the code you quoted you only show a #define but that doesn't instantiate anything alone. You must be using "SERIAL_NO" somewhere in the code. What I'm suggesting it that instead of putting it in the "middle" of the code you hold it separately in an easily isolated memory area:

__attribute__((seciont(".serial"))) char serial[] = "DEM02G0920110009";

the access this in the code however it is you are using it:

UART_sendtring(serial);

or whatever. But the data bytes themselves will be in flash at some fixed address that you assign to ".serial" like the 0x7FE0 in my previous example.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Have you considered what I said in #2 about serializing the devices separately (EEPROM) so there'd be one common code

or what I said in #4 about using a proper production programmer - which would take a common hex, and add the serial number during programming?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
i cannot rely on eeprom as in one of my functionality --- factory reset 

I'm clearing my eeprom..

A factory reset should not clear the Serial Number!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks awneil,

 

I'm not doing all this on may local machine.... 

so production programmer will not work for me...

 

the final hex will be converted to binary and that will be used in FOTA process.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
the final hex will be converted to binary and that will be used in FOTA process.

But, surely, a FOTA (Firmware update Over The Air) must require that you already have things like serial numbers - device identity - already in the chip?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
I'm not doing all this on may local machine.

Of course not - you said "mass production". So this would be done at the production (manufacturing) facility.

 

You send them the one Hex file, and they program it - using the production programmer - which adds the unique serial number to each unit.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
__attribute__((seciont(".serial"))) char serial[] = "DEM02G0920110009";

i tried to replace my Serial_no define code line by the above..

 

didn't worked getting error

 

Error    899    Disabling relaxation: it will not work with multiple definitions        1    1    Iolytic_Gsm_Project
Error    898    first defined here    C:\Iolytic_Gsm_Project\Release\src\ASF\common\boards\user_board\init.o    1    1    Iolytic_Gsm_Project
Error    942    multiple definition of `dev_serial'    C:\Iolytic_Gsm_Project\Release\src\main.o    1    1    Iolytic_Gsm_Project
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
multiple definition of `dev_serial'  
Well that's your error. You have dev_serial defined in two places. If you forget the Error List (which is frankly useless) and look instead to the Build Output it will show you both places where dev_serial is defined. You can't have two different ones. Perhaps you put this in a .h and it is #included in two different compilation units?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
__attribute__((section(".dev_serial"))) char dev_serial[] = "DEM02G0920110009";

the code you have suggested i have used dev_serial instead of serial....

 

so where ever i have used this dev_serial variable i'm getting that multiple error...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
so where ever i have used this dev_serial variable i'm getting that multiple error...
Only if you put it in .h

 

It instantiates an object so it must appear in only ONE .c/.cpp file. If more than one file needs to access put:

extern char dev_serial[];

into a shared .h file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mehul9 wrote:
i'm getting that multiple error...

This is standard 'C' stuff - nothing specific to AVR or Atmel Studio:

 

http://c-faq.com/decl/decldef.html

 

https://www.avrfreaks.net/forum/tut-modularizing-c-code-managing-large-projects

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks clawson...for the guidance.

 

i figured a way to change the device_serial, even if it is sitting at some random location like below...so no need to make any  change in the atmel code.

:1070EC004D205061636B65742053697A652025646B
:1070FC000D0A0044454D3032473039323031313091
:10710C0030313500646174612052656164204164E2

and also generation of srec binary files from the hex....

 

thanks...