Exact match. Not showing close matches.
'[PIC]: Changes in HEX file format since MPLAB 7'
Where I work we are using a method of calibrating our units where we run
some tests and then actually patch the correct value into a very specific
location in the HEX file just before programming the unit. The way they kept
these locations open was something like
The hex file is generated based on this, and then the calibration values
are inserted into the hex file in either program memory location 6, 7, 8, or
9. The value is actually the instruction retlw XXh with XXh being the value
that we use to calibrate. Basically we jump to Calibration_Vector and then
it returns and puts our value in W. Anyway, the question is not about how
The question is: When I assemble the code using MPLAB 7.20 I get a hexfile
that appears to have optimized out those empty spaces. That makes the hex
file's format different enough that our program (that has been in constant
use for 7 years) doesn't find the correct place to insert the value. To make
the hex file's format match the old hex file (by match I simply mean has the
same addresses listed in the 3rd through 6th bits of each line in the hex
file, content can be different) I now have to insert NOPs between org 6 and
org 10 to hold it open. Okay, here is the question for real<g>... am I
thinking about this correctly? Does anyone know for sure if this change I'm
noticing does in fact correspond to the newer version of MPLAB? Are there
any suggestions for fixing this in a way other than my insertion of NOPs
Thanks for any help,
James Humes wrote:
> Are there any suggestions for fixing this in a way other than my
> insertion of NOPs method?
Yes. Your method got you into trouble because it tried to do a dumb edit on
the HEX file instead of interpreting it properly, making modifications, then
writing it back out. There are many legal ways the HEX file can be written
that can be different at the low level syntax.
Another point is that it would be best to put RETLW h'FF' in the source code
with an appropriate comment what the value means and that it will be filled
in during production test. That would also give you the option of modifying
the value in place after the programming step in case that is more
convenient. I use this method for a current customer. The firmware is
first programmed into the device because it needs to run in order to collect
the data for calibration. Once the data is collected, the FFh is
overwritten with the computed value without reprogramming the device. You
can always flip 1 bits to 0 but going the other way requires an erase
operation, often on more than a single memory location. The source code
specifies FFh because that is the erased state.
If you can determine calibration values up front, then making a temporary
custom HEX file will be the fastest way to get there since only a single
programming operation is required. This should be done by actually reading
the HEX file properly according to the spec, changing selected values, then
writing out a new HEX file with the custom values. If you don't properly
read the HEX file, you'll probably have this problem again some time in the
future even if you manage to kludge around it now.
Reading a HEX file is easy. Doing it right in the first place would
probably have taken less time that you already spent finding and thinking
about this issue 7 years later. Don't make the same mistake again.
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
Thanks for the clarification. I only graduated in May though, so I didn't
make the mistake the first time! <G> I'll get it done right, thanks.
On 9/27/05, Olin Lathrop <embedinc.com> wrote: olin_piclist
James Humes <mit.edu> wrote: piclist
> org 4
> clrf PCLATH
> goto reset
> org 6
> org 10
> retlw 0
> The hex file is generated based on this, and then the calibration
> values are inserted into the hex file in either program memory
> location 6, 7, 8, or 9. .... When I assemble the code using MPLAB
> 7.20 I get a hexfile that appears to have optimized out those empty
> spaces. That makes the hex file's format different enough that our
> program (that has been in constant use for 7 years) doesn't find
> the correct place to insert the value.
The Intel Hex format doesn't require each line's address to be higher
than the one before... If the hex file doesn't already contain data
for the address you want to patch, just add a new line to the end of
the file that contains the data for that address. Put it just before
the "00000001FF" termination record.
=== Andrew Warren - ix.netcom.comfastfwd
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...