If I manually alter a .hex file with a hex editor and then upload it to a microcontroller (Maxim MAXQ610A), will the code run? Or is there a checksum buried in the .hex file that will prevent the binary from running if I manually alter it?

I'm making a device that will have a device ID (4 byte string) hard coded into the firmware, but the device ID needs to be changed for each device. The device ID is used by the firmware during operation. My thought was I would have the compiler output a .hex file, then manually edit the .hex file with a hex editor to alter the device ID before uploading the .hex file to each chip. What I don't know is if the chip does any validation on the code before running it, such as comparing against an expected checksum that is also stored in the .hex file, etc.. This is my first foray into this type of project and I would be grateful to anyone who can help with any info or tips.

 

OK I found the answer, sorry for posting before I completely RTFM. Apparently this chip uses the standard Intel .hex format, and the last bye of each line in the .hex file is a checksum. I can recalculate the checksum for each line after modifying it, but I'm open to better suggestions. The ID string needs to be random and reasonably unique, but it's not going to be a major issue if I end up with a duplicate every now and then.

 

One option is to write the unique data to the chip's on-chip eeprom if it has any.
Also, some programming software will correct the checksum when you change program data
(I think ICProg does this, but don't know if it writes your chip).

Some compilers also have an option to serialise chips.

 

Some programmers (Microchip) have the capability to create a unique serial number for each push of the button. I don't know about yours.

I DO have clients that do exactly what you propose i.e. modify the Intel .HEX for serial numbers and calibration data. Since its just a text file, its easy to do. Frequently, the ID / serial number is off in some special area of memory so its always in one place.

When the data can move for whatever reason, I will put a pointer to the ID block (which can move depending on various factors) at the top of the ROM image. The pointer is always at a known place. The programming / test software reads the Intel .HEX to get the pointer then knows which records contain the custom data.

I've also put signatures in the ROM image that bracket the variant code. The programmer scans/verifies the sigs then knows where the linker put the records.

Have fun.

 

I had the direction to build a test fixture for a PIC timer product. The exact time was fixed but could vary from order to order. So I made the fixture (also PIC based) program the unit under test with code that varied to meet that particular spec.

Yeah, I actually built a PIC programmer. Not for the faint of heart, but actually the programming spec is pretty clear and complete. I don't recommend doing this

Target code was stored in the PIC as an array (both units source code was written in C). I discovered where the constant I needed to change lived by thru searching the dissasembly listing, then finding the byte pattern in the raw data.

As this was my own programmer I did not need a checksum on the code, just load, adjust, and go.

 

You can write your own memory monitor that allows you to read and modify any byte in memory.

 

I thought most microcontroller programmers had a box where you can enter a unique serial number before programming?

If the programmer and programmer software does not have a serial number option, you could write a simple script on the PC (ie VB, PERL, etc) that increments the value in the HEX file and recalcs the checksum on that line in the HEX file. It should even be able to run the programmer software too, so there's only one user button press per chip programmed.

 

Thanks guys for the ideas. The thought crossed my mind that in this case I don't need to know what the ID string is, I just need to know that it's relatively unique. The ID string will be transmitted with the data, so the only thing that matters is that the receiver knows which ID string it has been paired with. So I'm thinking about wiring a button that executes a function to generate a random code, and store that code in the flash memory of the chip. This will be the ID string. The ID string can be changed at any time by pressing the button, but will be non-volatile since it's in flash. The receiver already has a button to "learn" or "pair" with the transmitter. Are there any downfalls to using the on-chip flash in this way?

I realize this chip doesn't have a full time clock, so maybe I can use the button press duration to seed the random number generator.

 

I realize this chip doesn't have a full time clock, so maybe I can use the button press duration to seed the random number generator.

That is the hard part, and good luck getting 4.2 million uniformly distributed states out of one button push.

Your trick is to get a good source of random information. Some of it could be fixed at build time (serial number) with the remainder from a local source.

If there is a timer free running you can read that when the button is pushed for some random bytes.

 

Maybe your idea is best, let a timer run free and just read its value when the button is pressed. I will check if this is possible on the chip I'm using.

I'm trying to avoid relying on anything unique at assembly time because I'm not sure if the programmer I will be using will have the ability to insert unique data for each chip programmed.