Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

Please accept the use of cookies on our site

At PEmicro we use web browser cookies in order to provide you with an enhanced experience and in order to be able to do things like shopping cart processing and identify you when you login to our website.

Click here to accept

search inside this forum
search inside all forums
Davide G. Mar 12, 2015 at 05:41 AM (05:41 hours)
Staff: Takao Y.

  • Hallo.

    Each time I try to erase the module I have the same trouble.
    All times the erase seems executed correctly, but neither blank check nor flashing can be performed.

    Actually I neet to change a microcontroller each time I need to change the firmware on it. It is not a good thing...


    Initializing. Initialized.
    ;version 1.06, 07/17/2013, Copyright P&E Microcomputer Systems, [mc56f84786]
    ;device freescale, mc56f84786, 1x16x144k, desc=all
    ;begin_cs device=$00000000, length=$01040000, ram=$00060000
    Loading programming algorithm ... Done.
    -Module has been erased.

    Initializing. Initialized.
    ;version 1.06, 07/17/2013, Copyright P&E Microcomputer Systems, [mc56f84786]
    ;device freescale, mc56f84786, 1x16x144k, desc=all
    ;begin_cs device=$00000000, length=$01040000, ram=$00060000
    Loading programming algorithm ... Done.
    Blank Checking ...
    Module word not erased at address $00000000 word is $E155.
    ERROR 25 during script!

    The version of PROGGDSC is the latest (3/2015) V5.13.03.00
    I tried also to use CPROGGDSC but have the same problem.

    cprogdsc.exe ? SCRIPT.TXT Interface=USBMULTILINK Port=USB1 BDM_SPEED 1
    (I tried also with various BDM_SPEED)

    DEVICE MC56F84786    
    RE           C:\PEMicro\PROGDSC\Algorithms\freescale_mc56f84786_1x16x144k_all.dsp
    SS C:\PEMicro\PROGDSC\Files\progfile_v12.S19

    Please Help me to solve it.



  • Greetings,

    If erase module seems to work but fails during blank check, then it is very likely a communication problem. A few questions:

    1) Have you gotten this setup to work in the past? Or is this your first attempt?

    2) Are you using any custom ribbon cable, adapter, external watchdog, reset circuitry, or other unique hardware between the P&E interface and the chip?

    3) Which multilink are you using and its revision? If you have a multilink universal or FX, make sure your firmware is correct. Download the latest resource CD:

    Takao Yamada

  • 1) We installed recently the tool, for programming several boards, and never worked properly. I can program only brand new chip, but if I need to reprogram it, I can't due erase problem. I can't try to install the tool on other computer due license/seat limitation. 

    2) Yes the ribbon is custom, the programmer is connected in a special jeeg that using some nails to contact the board that contain the processor to be programmed and maybe a reset circuitry with WD. Also the flat form programmer to nails, is really short (15cm).

    3) The programmer is multilink universal FX and I installed latest driver and program, that programmed the latest firmware on the programmer.

    I have no problem if the chip is new (never programmed) I can successfully program it and the board work perfectly. I have trouble only if i need to flash again (with a different firmware) an already programmed micro, due the erase module function, do not work properly.

    If you have something to suggest to try...


  • Greetings,

    Thank you for the new details.

    Reply to 3) The PROGDSC software is free, but you must activate a new license each time you want to install on a new machine:

    4) Do you know if the binary code secures the chip? I need to do a little research to find out if DSC has the ability to permanently secure itself. I would like you to run a quick test where you grab a new chip and just program a few bytes at the beginning of flash. The command "Program bytes" or "Program word" should be available to you in PROG. Then remove from your setup and reconnect and see if you are getting problems the second time. If you do not get any trouble, then we know for sure there is something in the binary that is securing the chip or turning on your watchdog.

    5) Get an oscilloscope if you have one and monitor the RESET line. While trying to erase and program the chip, see if the RESET line is toggling constantly. This would mean your reset circuitry with the watchdog is causing your issue. There must be code running on your chip that enables the watchdog and causing problems the second time. In this case, you should find a way to stop this watchdog.

    Takao Yamada

  • Greetings,

    Any update on this?

    Takao Yamada

  • Sorry for my silence, but at the moment we finished the production batch for this product. As soon we start  new batch and I will try to do what you suggested to do.

    We have also Cyclone and Cyclone pro programmers, and I will do further tests with these programmers.

    We have ever a 'time' problem, the customer need the production batch as fast we can, and leave not enough time to make tests.

    As I know customer have a update procedure that use a special prepared SD card, so the firmware inside is able to flash itself via a proprietary bootloader os so on. So I need to do further investigation if it's currently works. At the moment customer do not highlight any problem with board that we programmed.
    N.B. To program it we used the programmer and procedure supplied by the customer.

    When we have stuff to test, I update status.

    Thanks again for support.


    Davide Gatti

  • Hello,
    we have the same problem as Davide Gatti wrote above, we use the same microcontroller. But we also got 3 burned programmers after updating already programmed microcontrollers.
    We use a MCP131T-300E/TT voltage supervisor (has an integrated 95k pullup resistor) and in addition a 7.5k pullup resistor. Could this configuration cause some problems, especially burning programmers?
    We already successfully program these microcontrollers using Codewarrior for uploading the bootloader and then uploading firmware using serial port.We don't understand why it doesn't work using scripted code as explained in the CPROGDSC guide.

    Thank you very much for your support.

    Massimiliano Tebaldi & Daniele Berretta

  • Hello,
    we are using the same microcontroller as Davide Gatti wrote in the first post and we are experiencing the exactly same problem programming with PROGGDSC. Moreover we had three burned programmers after trying to upload bootloader+firmware on an already programmed microcontroller.
    The script we use has been written following PROGGDSC guide.
    The cable is a custom, partially non-flat cable, but this should not be the problem because we already use this cable for bootloader upload or update and it works fine.
    We employ reset circuitry: MCP131T-300 (Microchip voltage supervisor, which has an integrated 95k pullup)+ the 7.5k pullup resistor. Could this circuitry be the cause of burned programmers?
    Our script should not secure the device.

    Thank you in advance for your support.

    Massimiliano Tebaldi

Add comment

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

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