Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
PROGACMP with K20DX128 - Verify error after manual programming
Ben C. Oct 22, 2014 at 07:13 PM (19:13 hours)
Staff: Takao Y.

  • I am trying to program an MK20DX128 with an S19 file using PROGACMP. However, after I go through the process in the PROGACMP user manual for manual programming (section 6.1) I try using the verify command and I get an error that says "verify error at address $0000040C", and my program does not run.

    Here's the procedure that I am using
    1. Program my MK20DX128 flash via my IDE. Close the IDE and reset the target board.
    2. Start PROGACMP. Connect to the multilink universal and the target board
    3. Select the algorithm freescale_k20dx128_1x32x32k_pflash.arp
    4. Use the UM command to read back the module into an S19 file
    5. Use the EM command to erase the module
    6. Use the SM command to verify that the module is all erased to FF
    7. Use the SS command to select the S19 file that I just read back
    8. Use the PM command to program the module
    9. Use the SM command to verify that data has been written to the module
    10. Use the VM command to verify that the data has been written to the module completely.

    At this point, I get the following notice: "verify error at address $0000040C. Byte in module is FE and should be 81". If I click "yes" to continue verifying, it just keeps coming up with more errors, although subsequent errors say that the byte is FF instead of FE.

    When I do SM again and look at address 40C, the memory shows up as FF. When I do SM initially after loading my flash from my IDE (when I know that it is correct), the values at 40C and nearby memory are all FF. I also tried using the S19 file that the IDE generated directly, but that has the same result.

    Any help would be greatly appreciated. Thanks.


  • Sorry I have to make two corrections. First, the original error message that I receive after step 10 is "Byte in module is FE and should be 7E". 

    And when I do a show memory after flashing from my IDE the memory is as follows:

    00000410 81 F0 ... etc etc etc

    After running PM all of these addresses are FF. There are non-FF values before and after this memory area, just this area now has all FFs.

    So this indicates that the PROGACMP probably correctly read back the S19 file in step 4 above, since it knows that address 040C should be 7E. So the question is why didn't it write the correct value? Why did it write FE to address 40C and then fail to write the rest of that block of data...

  • Greetings,

    You understand that from $400 to $40F are the security information, right? You should only be writing in this location if you plan on securing the chip and possibly securing the chip permanently.

    From the verify error you mentioned earlier that the byte is $FE when it should be $81, this makes sense to me that it would give you an error. You are writing a high '1' bit to a bit that is already a '0'. If you remember how flash works, you can only write from a '1' to a '0'. Maybe this clues you into why you may be getting other errors.

    Takao Yamada

    • Hello Takeo. Thanks for looking into this inquiry. 

      Maybe I should make this into a more general question. Basically I am just trying to use the S19 that was generated by CodeWarrior to program my part via PROGACMP. Are there additional steps that I must take between generating the S19 file in CodeWarrior and using the procedure in section 6.1 of the manual to download that S19 to my device?

      To answer your specific questions:

      "You understand that from $400 to $40F are the security information, right?"

      No. I did not know that. Is there something specific that I need to do in order to get these memory locations to program to the S19 file? Also, there are memory locations after 00000040F that also appear to have not been written... all FF.

      "you mentioned earlier that the byte is $FE when it should be $81".

      That was a mistake. I wrote a reply that corrected this, but you might have missed it. The actual error code was "Byte in module is FE and should be 7E".

      Thanks for your help.

  • Greetings,

    I highly suggest not programming from $400 to $40F because you can potentially brick your chip by permanently securing it. If you are using Codewarrior, it should already be avoiding this address region. You must have modified the default linker file if you are trying to program this region.

    Takao Yamada

    • Takao,

      I think that the fact that the security code happens to be located near address 400 is a read hearing. I'd like to stop focusing on that unless it can explain why other segments of the memory are not being written to correctly.

      I am looking at a diff of the S19 file that I am using for programming and the S19 file that I read back using UM (upload module) after programming. It looks like every other 0x400 byte block did not get written to.

      So basically here's what I see in the diff.

      00000000 - 000003FF Data Data
      00000400 - 000007FF Data Every byte is 0xFF
      00000800 - 00000BFF Data Data
      00000C00 - 00000C00 Data Every byte is 0xFF
      00001000 - 000013FF Data Data
      00001400 - 000017FF Data Every byte is 0xFF
      00001800 - 00001BFF Data Data
      00001C00 - 00001C00 Data Every byte is 0xFF
      00002000 - 000023FF Data Data
      00002400 - 000027FF Data Every byte is 0xFF
      00002800 - 00002BFF Data Data
      00002C00 - 00002C00 Data Every byte is 0xFF

      ... and this pattern continues until the end of the data.

      Any thoughts on what might be causing this?

      • Just to check the theory that writing to the 400-40F addresses was causing the problem, I did try removing the line from the S19 file that writes to addresses 400 through 40F and the result was the same. Still seeing 1024 byte blocks that are all FF alternating with 1024 byte blocks that look like real data.

  • Greetings,

    Could you open a support request ticket? Could you post this S19 file in your ticket and we would like to see if we can replicate this issue on our side.

    Takao Yamada

    • Just to close the loop on this issue - Takao helped me offline and was able to figure out that I had selected the wrong algorithm file for my part. Picking the right algorithm file solved the issue right away! 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