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
IDCCFV1 Not Working
Paul M. Apr 6, 2017 at 12:33 PM (12:33 hours)
Staff: Takao Y.

  • I have been using the ICDHCS08 for quite some time with several boards that have the HCS08AC128 as their MCU's. I decided that more computing power may be needed for a new applicationso I bought the IDCCFV1 and PROGHCS08 to be used the same MultiLink Universal interface that I have been using with the 8-bitter. It has some deficiencies but it has been very useful. I just built another board using another copy of the same PCB but populated it with MCF51AC256B which is supposed to be pin compatible. When trying to fire up the IDCCFV1 it complains that it cannot talk to the BDM debug mode. My setup is identical to the HCS08 system except that the board is different and I am using the CF debug software instead of the HCS08. What can I be doing wrong? All the board has on it is the 5V regulator /w bulk cap, bypass caps and pullup resistors for the RST and IRQ lines. The BDM cabling is exactly the same.


  • Greetings,

    The typical BDM connection is BKGD (pin 1), reset (pin 4), VDD (pin 6), and GND (pin 2). Without the multilink connected and powering up the board, measure the voltages on BKGD, RESET, and VDD. They should all match exactly at 5V (or 3V if that is the VDD you are using). Report back your results. If they do not match, then there is something wrong on the target board causing this issue. All 3 signals should not have any current-limiting resistors in series. The pull-up resistors should be 10K ohm on BKGD and RESET.

    If the voltages look fine, then you may need to use an oscilloscope and check the rise and fall edges making sure they are clean and you are not seeing any noise or sudden change in VDD value.

    Takao Yamada

    • My system runs at +5V by regulating +12V power down to +5V using a MIC39100 LDO that supplies 1A. My DVM is reading 5.02V from Gnd to Pwr. None of the signals you describe have current-limiting resistors in series from the MCU to the BDM connector. 

      The BDM pinout is the same as you describe except that pin 6 is tied to the IRQ pin of the MCU and not directly to 5V. However, it is pulled high via a 10K resistor. When the board is powered with the MultiLink not connected, this pin reads 5.01V. If the MultiLink needs to draw power from this pin it is not going to get much current. This same MultiLink adapter works just fine when used with the other board that has an HCS08AC128. Its pin 6 of the BDM is also tied to MCU's IRQ with a 10K pullup resistor. Of course, the debugger programs that use the MultiLink adapter are different because the processor architectures are different. The PCBs of both boards are ostensibly identical and were made from the same Gerbers and came together in the same package. I could replace the 10K pullup resistor with a short (0K resistor) so pin 6 of the BDM would be 5V Pwr instead of 5V logic high. I don't believe that is would hurt the IRQ pin of the MCU to be tied directly to power but it does need to be pulled high.

      Pin 1 of the BDM is tied to BKGD of the MCU and it reads 5.00V using the DVM. There is no discrete 10K resistor to pull it high nor is there a bypass capacitor to ground. I believe this pin is being pulled high via an internal pullup resistor in the MCU. Perhaps I need to change this(?).

      Pin 4 (Reset) of the BDM is pulled high with its own 10K resistor. It is also bypassed to Gnd with a 0.1uF ceramic capacitor. The high side of the resistor reads 5.02V with the DVM. I have placed a footprint for a reset switch to pull this signal to ground in case a physical reset button is needed. The footprint for the switch is unpopulated at this time. Here is the strange part. The low side of the resistor (which is connected to the RST pin of the MCF51AC256B and pin 4 of the BDM) only reads 1.90V as does pin 4 of the BDM connector. I have looked at the trace under a microscope and where pin 3 of the MCU solders to its pad at the end of this trace. The joint looks good and the trace appears to have good copper separation from surrounding ground (top side) and power (bottom side) copper pours which I routinely use for supply power to parts. Of course, micro-hairs of copper can find their way to signals and bias their voltages. I don't know what may be dragging the voltage down or even if this is normal.

      Since I don't have a pullup resistor on BKGD, this could be a source of the problem I am seeing. However, the 8-bit board is the same way and works as expected. A 10K pullup resistor could easily be added to the board if needed.

  • Greetings,

    The reset to me sounds like the source of problem. When using the S08 target, do you see the same behavior on reset and it still works fine? Pin 4 must read 5V. Otherwise the multilink does not know whether the chip is in reset or not. it is floating at 1.9V

    A pull-up on BKGD will help, but it is only needed if the toggling of the BKGD line is slow and needs a sharper faster rising edge.

    Takao Yamada

  • When I power up the S08 target with no MultiLink connected, the BDM Reset signal (pin 4) reads 4.99V which is essentially Pwr level (Pwr reads 5.00V). However, the reset pin 4 on the ColdFire is not floating. The 10K pullup resistor is trying to pull it up to a logic high. However, something is preventing this. Whether it is the MCU or not I can't tell. I have seen the high side of the pullup resistor at 5.02V. I have also measured its resistance with the DVM and it reads 9.78KΩ. The alternate paths through the board certainly account for lowering the apparent resistance below 10KΩ. I could lift the RST pin on the MCU off its pad and measure the voltage of BDM pin 4 again. If the voltage goes to 5V then it will be proof that the MCU is responsible. If the voltage stays the same then I will suspect that there is an invisible copper hair coming from ground that lowers the voltage. What do you recommend trying next?

  • Does the MultiLink ever assert the Reset line? I assume that it does. Otherwise, I could replace the 10KΩ pullup with a lower value to force it to a high. However, this might not be good for the MultiLink if it uses this pin to force a hardware reset on the MCU.

  • Greetings,

    The multilink does pull the reset signal low to 0 volts, and releases it if it needs to be high. So the high signal is what worries me. If it is floating and not reaching 5V when the signal gets released, then the multilink still thinks the chip is in reset and cannot move forward in entering debug mode.

    The 5V on VDD is the reference voltage and will be used to determine if a signal is high or low. Some current from VDD is required so that the buffers on the multilink circuitry can determine the reference voltage on the chip because some designs have 3.3V as a high signal.

    Takao Yamada

  • Well, as I've said. The Reset signal is not floating because the 10K pullup is there trying to bring it to 5V. I've measured the resistance and it is close to 10K. But the voltage is seen at 1.9V so something has to be pulling it down. I'll lift the RST pin of the MCU off its pad and see what happens. If the MCU got damaged somehow, this might account for the odd behavior.

  • The pins on the MCU are so small I decided not to risk breaking the RST pin so I cut the trace coming from the MCU to the pullup resistor. This should be easier to repair after my test is complete. After power is applied (trace cut), Reset on the BDM signal (pin 4) now goes all the way up to 5V when the MultiLink is not connected. So it is the MCU that is the cause of the voltage drop. I read open when measuring resistance between this now isolated segment of trace (connected only to the RST pin on the MCU) and ground. Where should we go from here?

  • Greetings,

    Was this issue resolved? Were you able to find the problem? I do not have the schematic nor the board so it is really difficult to help you diagnose this problem that I believe is a hardware issue.

    Takao Yamada

  • This issue has not been resolved. I think that it is a hardware problem too. The number of hardware variables are few since I have very little on the board. It really should come up. I eventually gave up and went back to the board with the HCS08 on it which came up fine and acted normal. I could send you a copy of the schematic or even the board itself if that would help.

  • Greetings,

    You cannot attach any files in the public forums, so please go to Support page -> Support requests and create a ticket. There you can attach the schematic and I will take a quick look at it to see if there is anything that could cause this issue.

    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