Thanks. My sample code included
snippets like Uwe’s. Because the bootloader doesn’t know
where the “end of the code” is, I needed to do this a bit
differently. I finally got what I wanted by doing the following:
srec_cat $(TARGET).hex -Intel -little_endian_max 0
-multiple -output max.hex -intel
srec_cat $(TARGET).hex
-intel -little_endian_crc16 0x1F7FE -Cyclic_Redundancy_Check_16_XMODEM -output
crc.hex -intel
srec_cat crc.hex -intel
max.hex -intel -crop 0 4 -offset 0x1F7FA -Output combined.hex -Intel
It is way too much work just to stuff the “high
water” mark at the end of FLASH w/o modifying the high water mark, but
that seems to be a fundamental limitation of srec_cat. The locations are
fixed, but need to be parameterized so I can specify where the loader lives
(various chips) and have the makefile do the math (BOOT_START-2 or -6).
Any hints how to do that? Also the first srec_cat spits out four warnings
because I am laying the “max” over the beginning of the input
file. How do I just put the length out as its own record w/o any of the
original file???
I ended up running through all
permutations of CRC, initial value for both srec_cat and the crc16.h header
file and found that only XMODEM worked. Uwe’s example, implies one
of the other combinations works as well but I was unable to figure it
out. Perhaps srec_cat is broken, or perhaps the AVR algorithms are
broken. I dunno. I have something that works, now, so I am moving
on.
The AVR end looks like this:
bool CheckCrc(void)
{
uint32_t
crc_end = pgm_read_dword_far(BOOT_START-6);
if (crc_end == -1)
return false;
uint16_t
crc = 0;
uint32_t
adx;
for(adx = 0; adx <
crc_end; adx++) // include
all empty space?
// crc =
_crc16_update (crc, pgm_read_byte_far(adx));
crc
= _crc_xmodem_update (crc, pgm_read_byte_far(adx));
return (crc ==
pgm_read_word_far(BOOT_START-2));
}
From: Schwichtenberg,
Knut [mailto:address@hidden
Sent: Thursday, April 05, 2007
12:32 AM
To: larry barello;
address@hidden
Subject: RE: [avr-gcc-list]
srec_cat help request
Larry,
I have not tried, but at 31.03.06 Uwe
Fechner came around here with the same problem. He solved the problem
and on his last email he showed his makefile which puts the CRC behind the
last used byte of code.
# Create final output files (.hex, .eep) from ELF output
file.
%.hex: %.elf
@echo
@echo $(MSG_FLASH) $@
$(OBJCOPY) -O $(FORMAT) -R .eeprom $< $@
mv $@ $(TARGET).org.hex
srec_cat $(TARGET).org.hex -Little_Endian_CRC16 -max
$(TARGET).org.hex -Output $(TARGET).hex
I'm pretty sure he also showed the
algorithm of the used AVR-CRC, but could not find it on his web.
From:
address@hidden
[mailto:address@hidden On Behalf Of larry barello
Sent: Thursday, April 05, 2007
12:12 AM
To: address@hidden
Subject: [avr-gcc-list] srec_cat
help request
I am updating my boot-loader to perform a CRC check across
the application – it will stay in the BL if the CRC is bad.
I am trying to use srec_cat to generate the CRC value.
I am having no success getting the CRC value to match what the bootloader
calculates. Since srec_cat operation is opaque to me, I am asking for
some help.
How do I get srec_cat to calculate a CRC value from 0 to
(lets say) 0x1F7FD and plop that value down in 0x1F7FE? I.e. deposit the
CRC into the last two bytes prior to my bootloader (2k byte, m128).
This is the command line I am using w/o luck (well, *something* is getting deposited…)
srec_cat $(TARGET).hex -Intel -fill 0xFF 0 0x1F7FE
-Little_Endian_CRC16 0x1F7FE -Cyclic_Redundancy_Check_16_XMODEM -Output
$(TARGET).hex -Intel
Does the above process the CRC over the entire address
range? Or just the extents of the input file? Srec_cat isn’t
clear on that.
Has anyone used these tools to do this? The only
example I have uses the application to check itself – it
“knows” it’s extents because the linker provides that.
Unfortunately the boot-loader doesn’t have access to that
information…
Alternatively if I could get srec_cat to put both the
maximum extent and the CRC near the end of FLASH, I could adjust my boot-loader
to read those values in generating the CRC.
Thanks in advance.