AVR Freaks

Hi ChuckH,

Ok, I put together a zip file for you.  This should contain everything you need.  The text file in the zip also contains code from a app/bootloader project I'm using this in to give some examples of how to use it.

I also included the crcsntag source code (main.c) so you can see how it reads/modifies HEX/ELF files too or alter it if you need to.  I compile it with Borland C++ Builder 6, but it is pretty stock C/CPP stuff so you can likely recompile it with something else...

From the text file in the zip:

CRCSNTAG 1.10
_____________

I previously used SREC_CAT to add CRC protection to firmware images, but it has a couple of drawbacks.  The first is that it only works with HEX files, but ELF files are required for debugging or for using the convenient CTRL-ALT-F5 program and flash command which allows you to skip opening the programming dialog each time.  The second drawback is that it expands the firmware image size to some static value (often the full size of the flash) which makes programming and verifying take considerably longer.

CRCSNTAG addresses both of these issues!  It works with both HEX and ELF files.  It also embeds a crc16 or crc32 into a tag within the firmware so that the firmware expands only a 9-17 bytes.  It knows the firmware size and only tests the active bytes.  It can also optionally embed a 4 byte serial number as well which is compatible with my autoprogrammer product (it can automatically increment the serial number for each device it programs).  A library is provided with functions to test the crc, get the serial number, or search for the tag (in the case of a bootloader, it doesn't know the location of the application tag, it needs to find it).

Bootloader support has been thought out and you can specify a start address so that the bootloader can have its own tag to validate itself, and the application can have its own tag to validate itself.  You can choose to put a serial number in either tag, but I would recommend putting it in the bootloader tag so you can release an application update that is not serial number specific.  The tag can also be used to locate other information externally - you can add a version number after the tag in the application section that the bootloader can retrieve and provide to the user.  The self test makes for recoverable system where if the application code does not pass the CRC check, it can stay in the bootloader waiting for a good application update.  As always it makes sense to have something such as a button also trigger staying in the bootloader so that the option to replace application section code is always present.

The tag uses a special 4 byte preceding signature (cRcM).  This must only be in your compiled code in one location as there can only be one tag in the compiled code.  You can combine a bootloader and application into a single HEX file if you want AFTER using the crcsntag tool, but you must sign the HEX files individually beforehand.

More from the crcsntag.txt file:

crcsntag.c/.h contain 3 functions:
  findtag
    searches from a start address through a stop addresss to find a tag
    an application or bootloader KNOWS its own tag location and simply can reference it by name, but a bootloader that needs to find the application tag would
      use this function.

  testcrc
    tests the crc of the tag against what is in flash

  getserial
    retrieves the serial number from the tag if it has a serial number

crcsntag_settings.c/.h
  the .h has options to enable crc32 instead of crc16 or flash more than 64K or not.
  the .c has example tags, you can enable the one you need (crc16 or crc32, with or without serialno)

_____

In AVR Studio you can automatically call this tool as a post build event by going to project properties, build events, post build event command line and add:

My main application build post build event command line:
  crcsntag "$(MSBuildProjectDirectory)\$(Configuration)\$(OutputFileName).hex" "$(MSBuildProjectDirectory)\$(Configuration)\$(OutputFileName).elf"

My bootloader build post build event command line (note the -start=0x7000 difference!)
  crcsntag "$(MSBuildProjectDirectory)\$(Configuration)\$(OutputFileName).hex" "$(MSBuildProjectDirectory)\$(Configuration)\$(OutputFileName).elf" -start=0x7000

_____

Some example code:

I have a project with a bootloader and app and I chose to include the crcsntag.c/.h/crcsntag_settings.c/.h files only in the bootloader.  The application needed a tag so I just copied the correct tag into it, but it doesn't do anything with the crcsntag functions as the bootloader does anything relevant with that already.

bootloader main.c - this is code snippets, some code not shown like all variable declarations, etc.

#include "crcsntag.h"

#define FUSE_EXTENDED  0xfd
#define FUSE_HIGH      0xd0
#define FUSE_LOW       0xc2
#define FUSE_LOCK      0xcc       

int main(void)
{
  //test crc
  if (boot_lock_fuse_bits_get(GET_EXTENDED_FUSE_BITS)!=FUSE_EXTENDED ||
      boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS)!=FUSE_HIGH ||
      boot_lock_fuse_bits_get(GET_LOW_FUSE_BITS)!=FUSE_LOW ||
      boot_lock_fuse_bits_get(GET_LOCK_BITS)!=FUSE_LOCK ||
      !testcrc(BOOT_LOCATION,(uint16_t)MsgCRCM))
    {
      //halt so it will not be responsive and this error condition will be detected
      for(;;)
        ;
    }

  //test for enter bootloader condition here UPD
  if (PIND==0xbf && PINC==0xff && PINA==0xfe && PINF==0xfe)
    goto update;

  //get serial
  if (!getserial(&sn,(uint16_t)MsgCRCM))
    sn=0;

  //does the app have a tag and its crc is good
  if (findtag(0,BOOT_LOCATION,&ui1) && testcrc(0,ui1))
    {
      //store sn in GPIOR0 so it can be retrieve by app
      GPIOR0=((uint8_t*)&sn)[0];
      GPIOR1=((uint8_t*)&sn)[1];

      //execute application
      asm("jmp 0");
    }

  update:
  //more code
}

Application main.c:

tag so crcsntag will find/update it:

const uint8_t PROGMEM MsgCRCM[]={'c','R','c','M', 0,0,0,    0,0,};
volatile uint8_t *dummy_ptr;

int main()
  {
    //grab serialno from bootloader
    serialno=GPIOR0 | (GPIOR1<<8);

    //make sure gcc doesn't optimize out our darn tag!
    dummy_ptr=(uint8_t*)MsgCRCM;

    //more code
  }

ALSO - you can include the crcsntag code in the main application and it could do a findtag to locate the bootloader tag and then get the serial out of the bootloader directly instead of my passing 16 bits of it using registers in the example above.

Super - I spent a lot of time with crcsntag trying to get it to do _everything_ I'd ever need so I didn't have to go back and rework it again later.

Great pictures - impressive sir!

Do you mean the crssntag.exe (from main.c) vs testcrc() from crcsntag.c ?  What is different?

I don't understand how you know some of it is ok and some not.  The crcsntag tool figures out the size of a hex/elf and calculates a crc for that entire blob of memory.  When you compile if you are using the post build command you can see the crcsntag executeable run and it will say what the length was, the crc calculated, etc.  For example:

crcsntool test.hex [hex, found 0x151, size 25206, crc 0x01A0]
crcsntool test.elf [elf, found 0x151, size 25206, crc 0x01A0]

Thanks,

Alan

Chuck, did you enable this line in the crcsntag_settings.h (by removing the //)?

//#define CRCSNTAG_ENABLE_FAR            //enable if you are using >64K flash

Very odd.  I've got to look and see if I have an easy to program part over 64K to test it with, so I might be able to look at it a bit this weekend.  Maybe you will figure it out first!!

Another test - remark out some of your code so it drops below 65536 bytes.  Does it work/fail then?

If it fails then, disable the tag above, Does it work then?

The code difference is probably me trying to optimize the C to produce better ASM on the AVR side.

Hi Chuck,

I've dug into it a bit too and one of the confusing things I think is that in gcc, it treats PROGMEM variables as 16-bit pointers (such as the MsgCRCM tag).  I don't think this is a huge issue because I've seen some messages about how gcc packs the PROGMEM's into the first 64K anyway, but there is a function pgm_get_far_address() that I *think* I've used in a bootloader before to get a correct pointer (I could be wrong about this).  That only has to do with using the MsgCRCM reference, if searching for it, it should be fine.  Even then, it might only be an issue in a bootloader loaded above 64K referencing its MsgCRCM tag.

I'm not following post #24...

Thanks!

Alan

So you have BOOTRST set, but you are testing the crc in the app section?  Do you have the bootloader as a separate project?  I've had BOOTRST set before and when I flash the app alone, it may start at the BOOTRST address, but if it is empty, it rolls around and eventually gets to run the app section...

Correct.  Could there be something corrupting the flash?  If you read the byte that comes back the wrong value in your main function before calling the testcrc function using the pgm_read_byte_far, what does it return?  Is it what it should return?

I do the same thing and agree.

I think the  out    0x3b, r26 is setting the rampz register.  I see that in your code example above - do you see it in yours tests in post 35/36 ?

What does removing the loop do:  What should the 3 bytes be?

volatile uint16_t TheByte;
TheByte = pgm_read_byte_far( 0x085A );
TheByte = pgm_read_byte_far( 0x085B );
TheByte = pgm_read_byte_far( 0x085C );