Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
CProgCFZ ver 5.13.02. fails with "ERROR 18" but older version 1.68 flashes ok.
. Jan 12, 2015 at 10:08 AM (10:08 hours)
Staff: Takao Y.

  • Hello,

    I recently ordered a new copy of the CPROGCFZ programming software along with a new USB Coldfire Multilink BDM module. I have a known good board that erases and flashes fine with version 1.68 but will only erase with new version 5.13.02.00 and fails with a "ERROR 18 during script" msg. The working setup and the failing setup have the same results in both PROGCFZ and CPROGCFZ. Some part of my programming setup is not forward compatible with the new version.

    This seems very strange since the erase DOES work so the chip is being written to reset to all 1's. When the fault occurs, the msg "checking range of s records" says "checked", then the next line has Programming address displayed followed immediately by the error msg.

    The SPANSION CFP file I'm using (for old and new setup) is:[S29_gl512n_w_5485_cs1] but contains a line that says : REQUIRED_PROG_VERSION=1.62 ?? Is this a factor?

    Programming station:
    Windows 7 (32bit) SP1 system with a new USB coldfire Multilink BDM connector.
    Flashing a SPANSION 29GL512P, 1x16x32meg, proc=5485, cs=cs1

    other screen notes:
    USB-ML-CF detected - flash version 5.54
    Coldfire Core type detected as 54xx.


    Any assistance you can provide is most appreciated ! -Scott C.




    Comments

  • Greetings,

    Could you give us the CFG script you are trying to use? All of the commands in order would give me a better idea of what might be wrong.

    The required prog version is only a factor if you have a PROG version that is less than this value. Since you have versions higher than this, then you do not need to worry.

    Have you tried lowering the debug shift frequency within PROGCFZ? See if this improves your communication to your target.


    Takao Yamada

  • Hello !   Thanks for getting back to me.   Below is the CFP file from the original setup using CprogCFZ 1.68.    I have tried slowing down the interface which is noticeably slower but I still get a fault showing
    "Programming Address $E0000000. Error during programming. ($00000000)"

    An interesting note... the erase function does work as verified by showing all F's under VIEW MODULE DATA. After the programming function fails, the VIEW MODULE DATA shows that writes did occur down to $E00003ff.

    More to follow.... Thanks ! -Scott


    ;version 1.00, 12/06/2010, Copyright P&E Microcomputer Systems, www.pemicro.com [S29_gl512n_w_5485_cs1]
    ;device Spansion, 29GL512P, 1x16x32meg, proc=5485, cs=cs1
    ;begin_cs device=$00000000, length=$04000000, ram=$80000000
    REQUIRES_PROG_VERSION=1.62/
    CONTROL=40000001/0C0F/ ; set mbar on with address $40000000
    WRITE_LONG=00000000/4000050C/ ; CS1 address=0
    WRITE_LONG=00101580/40000514/ ; CS1 ASET=01, AA, 16-BIT
    WRITE_LONG=FFFF0001/40000510/ ; CS1 mask +ON
    WRITE_LONG=FF800000/40000500/ ; CS0 address= FF800000
    WRITE_LONG=00001980/40000508/ ; CS0 control
    WRITE_LONG=001F0001/40000504/ ; CS0 mask +ON
    ;end_cs
    NO_TIMING_TEST
    DOUBLE_BUFFERING
    ;Blocks 512-128k
    USER=BE Block Erase 2Block > /00000000/000001FF/
    ;
    S3158000000080000190800001B00000008000000000A8
    S315800000100400000000000000800000740000000062
    S3158000002000000000800000C800000000800001067B
    S31580000030800000628000006480000066000000008E
    S3158000004000000000000000008000004C2E3C0002F2
    S3158000005000004C0700002040D1FC0000000060003A
    S3158000006000324AC84AC82A7C00000AAA2C7C0000B2
    S3158000007005544AC8223CFFFFFFFF32180C81FFFF60
    S31580000080FFFF6606558066F24AC8203CFFFFFFFFE9
    S315800000904AC83ABC00AA3CBC00553ABC00803ABC6F
    S315800000A000AA3CBC005530BC0030223CFFFFFFFF5D
    S315800000B032100C81FFFFFFFF66F632100C81FFFFC6
    S315800000C0FFFF66EC42804AC83ABC00AA3CBC005599
    S315800000D03ABC00803ABC00AA3CBC00553ABC001031
    S315800000E0223CFFFFFFFF3239000000000C81FFFF3A
    S315800000F0FFFF66F23239000000000C81FFFFFFFF30
    S3158000010066E442804AC822482848204B240342801D
    S3158000011042813ABCAAAA3CBC55553ABCA0A0301C28
    S3158000012030C03228FFFEB28066F83228FFFEB280E9
    S3158000013066F0558266DC3019321BB28066085583BC
    S3138000014066F442804AC8203CFFFFFFFF4AC893
    S804000000FB
    ü¡

  • Greetings,

    I do not want your CFP file, I want to see the CFG file. The configuration file of all the commands you are using like erase, program, and verify.


    Takao Yamada

  • Hello,
    Ok, here it is. The half above the asterisks does the boot flash to a different IC and always works. The lower half always erases ok but faults during programming.

    RE
    CM wellpilotRPOC\WellPilotRPOC.cfp FD800000
    CA ; Clear All Locks
    EM ; Erase Module ... Boot Flash


    SS C:\!FW_RPOC\FW-00007-00\303PP\FI0000701.S19
    PM   ; Program Module... Boot Flash (thru $FDF5A200)
    ;VM ; Verify Module
    ;************************************************************
    CM wellpilotRPOC\Spansioncs1.CFP E0000000
    CA ; Clear All Locks
    EM ; Erase Module ... Code Flash

    SS C:\!FW_RPOC\FW-00007-00\303PP\FI0000700.S19
    PM   ; Program Module... Code Flash (thru $E3FDFFF4)
    ;VM ; Verify Module

    RE ; Reset Chip
    GO ; Run

  • Hi Takao,
    Have you had a chance to look over my CFG file contents? I have moved back to the GUI (ProgCFZ) to try different parameters and view the chip contents after the program effort fails. As I mentioned before, the write function does start and programs down to $E00003ff before failing. Thanks in advance for your help. - Scott

  • Greetings,

    I have taken a look at your CFG file, but I have no way of replicating this since I do not have your board.

    Are you using the exact same algorithm that you used in the older version of CPROG?

    Could you create a support request ticket with us? I believe this is tied to a software bug we have in our latest software and I want to see if our fix will fix your problem.

    Please put the words "vaddr vs paddr bug" into your ticket description just so the support engineer knows how to handle your problem.


    Takao Yamada

  • Hi Takao,
    Understood on replicating. Yes, I am using the exact same algorithm for old and new programming versions. We'll see what the SE guys come up with. Thanks !

    Got it submitted.... SR #21653.


    - Scott C.

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