Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
error 51 programming 9S08QE128
Bruce A. Mar 3, 2016 at 06:08 PM (18:08 hours)
Staff: Takao Y.

  • I have a legacy 9S08QE128 project that I have updated many times over the years with no problems.  I use CW6.3 and USB HCS08/HCS12 Multilink rev B.  I use the checksum command in the linker file to create checksums used by the bootloader.  Today I made a change that added 3 bytes and when I run the debugger I get, ERROR 51 during programming!  The erase and program/verify commands execute with no errors. Then:
    CMD>VC
    Verifying object file Checksum16+CRC8 to device ranges ...
    block 00003000-00007F9C ... Ok
    block 0000C000-0000D443 .. Checksum16+CRC8 Error in block. (file = $003509, Device=$3509)
    ERROR 51 during script!

    The srecords in my .S19 file are 3000-7F9c, c000-d443, and ff00-ffff.
    I am not using paged memory.

    The bytes that get added are in the first block. I can add 2 bytes and it is Ok but the third byte causes the error. It doesn't matter where I add the bytes (if statement, asm{nop}, etc) The length of the second block remains the same.

    The checksum commands in my .prm file are:
    CHECKSUM
    CHECKSUM_ENTRY
    METHOD_CRC8
    OF READ_ONLY 0x3000 TO 0x7FFF
    INTO READ_ONLY 0xFF00 SIZE 1
    UNDEFINED 0xff
    END

    CHECKSUM_ENTRY
    METHOD_CRC8
    OF READ_ONLY 0x8000 TO 0x9FFF
    INTO READ_ONLY 0xFF01 SIZE 1
    UNDEFINED 0xff
    END

    CHECKSUM_ENTRY
    METHOD_CRC8
    OF READ_ONLY 0xB600 TO 0xBFFF
    INTO READ_ONLY 0xFF02 SIZE 1
    UNDEFINED 0xff
    END

    CHECKSUM_ENTRY
    METHOD_CRC8
    OF READ_ONLY 0xC000 TO 0xFEFF
    INTO READ_ONLY 0xFF03 SIZE 1
    UNDEFINED 0xff
    END

    CHECKSUM_ENTRY
    METHOD_CRC8
    OF READ_ONLY 0xFFB0 TO 0xFFFF
    INTO READ_ONLY 0xFF04 SIZE 1
    UNDEFINED 0xff
    END

    END

    Any clue as to what is happening?




    Comments

  • Greetings,

    Just so I have a clear understanding, could you explain to me what these checksum commands in your PRM file are doing? Is it calculating the CRC8 and programming them in 0xFF00-0xFF04? Is it doing a comparison to what is programmed in that range?

    Our CRC calculations are a combination of CRC-8 and Checksum-16. Is it possible that this may cause issues for you?


    Takao Yamada

  • Yes, as I understand it, these commands calculate the CRC8 over the range and program to 0xff00-0xff04 as you suggest.  The problem comes when the P&E programmer/debugger is run.  Evidently there is a script file and after the flash is programmed and verified it issues a VC command which is what fails.

    What does the VC command do?
    Where is the script file located?
    How is it created/edited?
    Why does it return an error for a block when it says the device value and the file value are the same?

  • Greetings,

    VC command calls our verify CRC command after programming to ensure that what was programmed is correct based on the binary file.

    There is no script file and it is predetermined. There is no way of changing this. If you want full control of how you flash program your device, then you should look into purchasing our PROG software (PROG HCS08 for your device). In PROG software, you can run any command you wish in any order. This includes being able to program individual bytes or serial data.

    You indicated you are writing 3 bytes. Is there something unique about these 3 bytes? Give me an example of what you are doing.

    What happens if you write 4 bytes instead of 3 bytes?


    Takao Yamada

  • What does the VC command verify?  It has already programmed and verified the flash.  Does it again read the flash and create a CRC and then read the file and create a CRC and compare?

    I tried removing the CHECKSUM commands from the .prm file and still had the same problem.

    I don't want full control of the flash programming. I just want to be able to click on the debug icon and have it program my target without errors.

    I had:
    if (condition) {
    statements
    }
    else {
    statements
    }

    and I changed the else to:
    else if (condition) {

    and that added 3 bytes which caused the problem with the VC command.

    If instead, I added before the if statement:
    asm {
    nop
    nop
    nop
    }
    I got the same error but not with 1 or 2 nops.

    Since I started this topic, I have added more code and the problem has gone away. That still means that there is some bug in your VC command that might show up again.

  • Greetings,

    The CHECKSUM you mention is not something we implement and I am actually not sure why it is there. Our VC command is something we call after flash programming to ensure that we programmed the flash correctly. A CRC/Checksum is calculated on the binary (S-record) and then calculate CRC/Checksum on the chip's flash where data was programmed and compare the values. Note, it will not calculate the CRC of the entire flash, unless you programmed every byte of flash.

    For me to debug and diagnose this problem, I think the best way for me to replicate this is to get your project. If that is possible for you, then please go to Support page -> Support requests and create a ticket with your project since you cannot attach any files on the forums.


    Takao Yamada

  • I had the same problem (different processor), and Takao referred me to the following page:
    http://www.pemicro.com/faqs/faq_view.cfm?id=211

    I applied the patch available there (which installed a newer version of the Programmer), and that fixed the problem.

    Thanks, Takao.

Add comment


   Want to comment? Please login or create a new PEMicro account.







© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement