Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
search inside all forums
progacmp
John G. Dec 18, 2017 at 05:14 PM (17:14 hours)
Staff: Takao Y.

  • I cannot find progacmp on your site and cannot find it on my pc. I have downloaded and installed PKGCFZPROSTARTER and multilink_universal.




    Comments

  • Greetings,

    PKGCFZ is for ColdFire chip architecture.

    What chip exactly are you trying to program? Which P&E interface are you trying to use?


    Takao Yamada

    • We are using a Multilink FX on a Coldfire V2 via a JTAG connection. I don't have the exact processor at hand right now (I'm at home). A document in PKGCFZPROSTARTER referenced PKGCFZ as the way to manually set the device type. The auto detect thinks it has found a 5441 (I think) and that is not the chip we are using. (We are using an older device.) When I try to connect I get a message that the processor sent a bad command.

  • Greetings,

    PROGACMP is for ARM devices, so that would have been the wrong software to purchase.

    PKGCFZ is the correct software for you.

    Try lowering the debug shift frequency option before you click on connect. ColdFire is a much slower device and the multilink FX is typically too fast.


    Takao Yamada

    • I have tried many slower debug shift speeds and get the same message each time:

      Debugger retrying force to background mode.
      Illegal command error from CPU - try a RESET.
      Device Debug Module : Revision D+PSTB
      Device Detected : 5441x
      Illegal command error from CPU - try a RESET.

      BTW, we are using a 5232.

  • Greetings,

    Is this your first attempt in trying to debug/program this chip? Or have you been successful in the past but you are running into issues now?

    Are you connecting all 26 pins of the BDM connection, or are you hand selecting the connection and if you are which do you have connected and which are omitted?


    Takao Yamada

    • First time with this degugger. The project itself goes back many years but we used a different debugger (which we no longer have). The JTAG connector has all pins connected except for 1, 21, and 22.

      I thought I saw somewhere in your literature some notes on the JTAG signals to check for but cannot find them again.

      The first thing we would like to do is have confidence that we are communicating with the target. The next thing is to be able to reprogram some flash chips (through the uproc) that have become corrupted. Finally, we would like to debug some code. This last step may take some reconfiguration since we are using a DIAB compiler, not gcc. We are generating elf files.

  • Greetings,

    Sounds like a good plan you have set.
    Omitting 1, 21, and 22 is fine as these are no-connects.

    For ColdFire, check these signals in this order when you try to connect:

    1) BKGD (pion 2), DSI (pin 8), and DSCLK (pin 4) are driven low
    2) RESET (pin 7) is driven low for 20 ms and then released. The chip should now be in debug mode.
    3) PST0 (pin 15), PST1 (pin 14), PST2 (pin 13), and PST3 (pin 12) should all be driven high.
    4) Activity on DSI, DSO (pin 10), and DSCLK for communication to target chip.

    Also note that VDD should be stable at 3.3V measured against the GND signals.

    Concerning debugging, as long as the ELF file is ELF/DWARF 2.0 or higher than our ICDCFZ software found within the PKGCFZ software package should be able to handle loading the debug information. Note that all paths to files must be listed and not just the directory/folder they sit in.


    Takao Yamada

    • I occasionally get signals that are close but not reliably. How do I determine the proper Debug Shift Speed. I,ve tried them all. We have a 14.745 KHz xtal. 

      Also, I notice that the BKGD and DSI signals go high about 50 ms after the third reset. I makes me suspect that I would see them after the first reset if the second reset didn't start things over again. Is there some other parameter I should be setting? Is this covered in the manual somewhere?

  • Greetings,

    Debug shift speed is determined typically on trial-and-error because everybody's board is different and unique. You want to find the fastest yet reliable speed so that when you move from one board to another you can reliably be able to enter debug and program. But if none of the speeds are working reliably, then something else is wrong.

    You should try adding 200ms reset delay. It could be that the reset that the P&E interface is attempting is too fast and the board's own reset circuitry needs more time to complete. The 200ms delay will wait after reset is done for a short time until it proceeds to the next step.


    Takao Yamada

  • Greetings,

    Any update on this?


    Takao Yamada

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