using the FLashloader API -> appStart

 Hello everyone,

I've been using the USB-Boot-nano example from Karol and it works great. However, when programmed through the Debug or USB-Interface, the Bootloader doesn't recognize the program, because of a missing checksum as far as I know.

Is there a way to generate that checksum and write it into the flash so that the Bootloader sees the program as if it programmed it itself?

Regards,

Christoph

Parents Reply
  • Is there any news to this topic? Knowing where the checksum is stored and having a way of generating it and most importantly storing it in the right position in flash is really needed.
    If that doesn't work, is there a way to tell the flashloader framework to try and load anyway, since the image is raw and not bch? (found two definitions that seem to distinguish the analyzed flash between bch-flashed and raw-flashed.)

    Regards,

    Christoph
Children
  • I have ued this tool to add the CRC to the downloader srecord file that is programmed into flash using the debugger (load the srecord into memory, and only load the symbols from the elf file for the downloader) :-

     

    http://srecord.sourceforge.net/

     

    I added a new builder to the project (add_crc) :-

     

    and then the builder configuration was :-

     

     

    The arguments are :-

     

    ${build_type}
    0x100000
    0x17FFFF
    ${project_name}.srec
    ${project_name}_crc.srec

     

    These are:-

     

    %1 is build type
    %2 is slot base address
    %3 is slot end address
    %4 is input S-record with no CRC
    %5 is output S-record with CRC added

     

    and the crc_add.bat file I created is attached (rename to .bat to use).

    @echo off
    REM %1 is build type
    REM %2 is slot base address
    REM %3 is slot end address
    REM %4 is input S-record with no CRC
    REM %5 is output S-record with CRC added
    
    @echo Build phase to add CRC to S-record output by compiler for download by debugger 
    
    @echo build type is        %1
    @echo slot base address is %2
    @echo slot end address is  %3
    @echo input S-record file  %4
    @echo output S-record file %5
    
    if "%1" == "clean" goto clean
    
    if "%1" == "incremental" goto build
    
    if "%1" == "full" goto build
    
    @echo no action taken
    goto done
    
    :build 
    set /a slot_base 	   = %2%
    set /a slot_end  	   = %3% + 1
    set /a crc_start 	   = %2% + 0x818
    set /a crc_end   	   = %2% + 0x81C
    set /a crc_blank_start = %2% + 0x81A
    if exist %5 del %5
    REM srec_cat.exe outputs a warning about a hole in the data presented for CRC16 calculation, this hole is correct in this case. 2> nul on the end of the command pipes this warning to NULL
    ..\srecord-1.64-win32\srec_cat.exe ..\Debug\%4 -fill 0xff %slot_base% %slot_end% -exclude %crc_start% %crc_end% -CRC16_l_e %crc_start% -BROKEN -fill 0x00 %crc_blank_start% %crc_end% -o %5 2> nul 
    goto done
    
    :clean
    @echo Removing S-record with CRC added
    if exist %5 del %5
    goto done
    
    :done
    @echo finished

  • Hi Jeremy,

    Thank you very much for your detailed answer. I will try this next week as I am currently not at work.

    Regards,

    Christoph
  • Hi Jeremy,

    I tried your solution and the batch file executes, the srec with crc is created, but the flashloader framework still doesn't accept the flashed data as valid firmware. Updated through usb stick still works. My program reaches from 0x80000 till 0x380000 and I tried these settings as slot_base and slot_end and also the 0x17FFFF as slot_end. None of these work.

    Any idea what could be the problem?

    Regards,

    Christoph

     

    EDIT: I read out the working flash and the crc-generated flash and these differ in one line only, the line where the checksum is, I presume. The working, bootloader-flashed read-out has a 66CB and the flash programmer flashed, crc-generated read-out data has a 496F. So that's why the Flashloader framework says the image is corrupted

  • I resolved the issue. I had set the wrong boundaries, I needed 0x3FFFFF as slot_end_address, not 0x380000, which is the flash size I use for my program.

    Regards,

    Christoph