I have a software for an embedded system. That I first have converted to .bin, then unpacked and then repacked again and converted back to hex.

The two packed versions is identical afterwards except for precisely at the end where they differ. I suppose this is some data created by the packer. It's also a tad but shorter than the original. And when converted back to hex the original and the version converted back are identical all the way except that the re packed version ends at address A3xxxx or something similar while the original ends at Address FFxxxx.


So my question is if I should fill that address gap with FF perhaps?


Or leave it as is. That I think would mean that this part is not overwritten when flashing the software so it might cause a problem when flashing a costume edited version of the software that is shorter and do not overwrite all of the old code.

 

You do not have to overwrite unused addresses.
If you do not use those addresses your software does not care what was/is in it.

If you are using RAM for data storage, you can choose for the compiler to initialize those memory areas to a desired startup state, or you can simply not bother and have the memory space power-up to a random state.

 

You do not have to overwrite unused addresses.
If you do not use those addresses your software does not care what was/is in it.

If you are using RAM for data storage, you can choose for the compiler to initialize those memory areas to a desired startup state, or you can simply not bother and have the memory space power-up to a random state.

Okay thanks. I haven't compiled the software for this embedded system, that has been done by Harman/Becker - BMW.
I have only changed some text in it and repacked it and converted it back to IntelHex format to be flashed to the computer again.
I think at boot it runs some code to decompress this software into RAM and starts to execute from there. But I'm not sure that's how it works however...

 

The only time it matters is if the software goes bonkers and starts trying to execute the code there. You can fill the unused area with values that will reset the processor in this case. Just what you would fill it with depends on the instruction set of the processor.

 

The only time it matters is if the software goes bonkers and starts trying to execute the code there. You can fill the unused area with values that will reset the processor in this case. Just what you would fill it with depends on the instruction set of the processor.

Okay. That's good to know. The processor is a Renesas SH7709A (SH3) so a little more uncommon reduced instruction set processor.

I'll probably try to flash my costume file and see what happens. Worst case it bricks and refuse to respond. Best case it works flawlessly. Acceptable case it stops responding but I'm able to revert back.
So we'll see how goes. Thank you guys.

 

Hah! That is a different situation.

In order to safeguard the integrity of embedded systems, any system worth their salt would embed a checksum in their firmware.

If you alter a single byte, even text, the checksum will be incorrect and you will most likely brick your system.

 

Hah! That is a different situation.

In order to safeguard the integrity of embedded systems, any system worth their salt would embed a checksum in their firmware.

If you alter a single byte, even text, the checksum will be incorrect and you will most likely brick your system.

Well you are most likely right. I found many references to checksum calculation in the Debugging information.

This is 2 of them

At least the system ignores any hardware errors. I updated the system to a different HW revision software and it reported a hw mismatch but still boots and works fine except the A/D converter.

There are also companies that have changed the language of this computer this way (I think).
So they maybe have found a way to calculate the new checksums.