Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Does PROGCFZ have an error log?
Richard P. Feb 5, 2015 at 09:38 AM (09:38 hours)
Staff: Takao Y.

  • Yesterday I purchased & downloaded PROGCFZ version 5.21.0, to use to install firmware on a device.  My company does this regularly (established hardware) but I had problems.

    In PROGCFZ, after connecting & choosing an algorithm (Spansion_29GL032N_04_1x16x2meg), I issued the following commands:

       EM Erase module
       SS Specify Object File
       PM Program module
       VM Verify module (All Bytes)

    In response, in the Status Window, I saw the messages:

       Blank Checking ...
       Module word not erased at address $00000000 word is $8001.
       Erasing. Module has been erased.
       Checking range of S records. Checked.
       Programming Address $00000000. Error during programming.($00000000)
       Verifying Address $00000400. Verify error at address $00000400.
       Byte in module is $FF and should be $4E.

    I am especially interested in the error "Error during programming" for the PM command.

    I need more details about *what* error happened during programming.

    Q1. Can you point me to an error log/trace file?

    Q2. If not, can PROGCFZ be put into a mode where it dumps internal messages to OutputDebugMsg so that I could see them with something like DebugView?




    Comments

  • Greetings,

    Usually for customers who are using external flash, the problem is either the selected algorithm is incorrect, the chip select in the algorithm is incorrect, or some other setting needs to be set in the algorithm for your specific board design (external watchdog, system bus chip, signal MUX, etc)

    For users with external flash, my recommendation is to use the "ChipSelectDiagnostics" menu option in PROGCFZ. This will help you debug the issue by checking the signals on your JTAG connection. This is the best way to debug your issue.

    Do you know if you are using the correct algorithm? Do you have a single Spanision chip with 16 bit width and 2 Megs of lines of memory (16 bit * 2 Meg lines = 4 MBytes)? Are you using chip select 0, which is our default for all algorithms we provide.


    Takao Yamada

    • Let me also add a description of my situation:

      - we usually use an older version of your software

      - I am trying to set up on a 'new' PC

      - I am seeing this problem with version 5.21.0 (just-purchased version) and version 5.13.02 (starter package) on my new PC

  • To your questions:

    >> "Correct algorithm" - yes, we're using Spansion_29GL032N_04_1x16x2meg (and it works fine on the devices we install software on, daily) - we are using a 16 bit bus to access the part.

    >> "Chip select 0" - yes, we use CS0 from the flexbus to select this flash chip.

    >> "ChipSelectDiagnostics" - it turns out that during my testing I used "SM" to confirm that we successfully wrote the first 0x0400 bytes (00000000 to 000003FF), but failed after that (wrote nothing - still saw 0xFF from 00000400 forward in memory). I also manually did a PB to write 2 bytes to 00000400-00000401, which was successful (used SM and scrolled around to confirm the 0xFF 0xFF had changed to 0x22 0x33). I believe this (ChipSelectDiagnostics) is trying to do something less.

    I suspect that we have the right 'algorithm', and in general the right hardware design; in this case, we see that we are able to write to flash.

    Whatever the reason was that PM had an error causing it to stop writing with the byte at offset 0x03FF, the reason was *not* because 0x0400 was not writable.

    Do you have any suggestions as to why PM stopped at that point?

    1) Could it be some kind of buffering issue?

    2) Is there some configuration that we should check?

    3) We are using a USB-ML-CFE Rev C adapter; we are seeing this problem with firmware versions 5.48 & 5.54; could it be some kind of compatibility issue?

    rich

  • Greetings,

    The issue may be with the communication speed. Try slowing down the debug shift frequency within the connection manager and see if this improves the communication. If it keeps failing, keep lowering the speed until you reach the last option.

    I doubt the issue is with the firmware versions. They have been stable for many years.

    Are you using an ELF file when programming your chip? If so, could you create a support request ticket (Go to Support page -> Support ticket) and put my name in the title or description? I think I know what may be the issue.


    Takao Yamada

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