This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Debugger connection problem with Piccolo TMS320F28035PAG

Other Parts Discussed in Thread: ISO7231A, ISO7231C, ISO7230A, ISO7240C, ISO7240A

Hdello,

on my new board I have a TMS320F28035PAG (64 pin package) and Iam having trouble with the debugger connection. I use a XDS100V2. The JTAG scan test works fine. But when I start a debug session I get the error

"Error connecting to the target:
(Error -1015 @ 0x0)
Device is not responding to the request.  Device may be locked, or the emulator connection may be unreliable. Unlock the device if possible (e.g. use wait in reset mode, and power-cycle the board). If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK).
(Emulation package 5.1.507.0)"

I found a hint in the datasheets and the forum to use boot mode "wait" (GPIO34=LOW, TDO/GPIO37=HIGH, TRST=LOW) to prevent the controller from making stupid things. But the controller should be empty, it's fresh out of the box. But no luck with this boot mode. I found this post

and hey! I see a similar pulse on the reset pin, pulsing @ 74 Hz. This looks not good!

I tried to to disconnect the debugger duing power up to make sure all IOs are at their expected level, I tried all other combinations of boot mode pins incl. emulator boot, I did a hardware reset after power up, nothing works :-(

Only when I pull GPIO34 and GPIO37 to LOW (parallel boot), the reset pulse vanishes. But still no connection to the debugger.

On a ControlCardISO I changed a damaged Piccolo and it worked flawless at the first connect. No fancy boot mode selection.

Any comments are appreciated.

Regards

Falk

  • Hi Falk,

    My feeling is that this has something to do with your connection between the emulator hardware and the C2000 device.  I might recommend looking at your device datasheet's 'Emulator Connection' section.

    Is your emulator one you made or one you bought?

    ===

    The pulsing on XRSn is actually a relatively good sign.  On power-up, an unprogrammed chip (that is in boot to flash mode) will start running code.  Since the chip is unprogrammed, it will quickly ITRAP and stay there.  Because the watchdog was not disabled, it will eventually force a reset.  You can look at the datasheet to reference guides to check the exact timing that the watchdog will reset your device by default, but from what I remember it is very close to the 74Hz rate you are describing.

    The fact that you're seeing the periodic reset pulse tells you that the device is being powered, is able to run code, etc.


    Thank you,
    Brett

  • Hello Brett,

    You are right, my two XDS100 are selfmade, but they are just a minor modification of the C2000 Launchpad with the Piccolo removed. So far I managed to make one of my two debugger work! This one generated runt pulses on TCK which messed up the communication. These pulses where comming from the ISO7240 isolator! Replacing the part made the debugger work fine!

    The first board still does not connect to the Piccolo, but the JTAG integrity test works fine, one after another! I checked the signal integrity on all pins close to the target, everything is fine. Clean signals, no crosstalk. Very strange! Reducing the JTAG frequency does not change the situation. I also checked the signals with a logic analyzer, everthing looks OK during JTAG test. How ist this possible? Which JTAG operations are not tested during the JTAG integrity test but are used during debugger connect?

    Regards

    Falk

  • Ok, here comes the happy end. I changed the ISO7240A and ISO7231A (1Mbit/s) for a modern ISO7240C and ISO7231C (25 Mbit/s) and now it works. There is no logic explaination for that, since even the old, slow A devices should  be fast enough for 1 Mbit/s operation, which is used by the XDS100V2 design (max 110ns propagation delay, 1000ns clock period). Also a reduction of the clock frequency down to 10kHz did NOT work. There is probably a nasty, hidden timing issue in the protocol or the FTDI2232 that does not work with the slower device. Another bug was a mix up of ISO7230A (4TX, 0RX) and ISO7231A (3TX, 1RX), but the wrong channel was NOT used by the JTAG signals, only by the optional UART.

    Regards

    Falk

  • Hi Falk,

    Great job debugging the issue and thank you for posting your resolutions!

    I have run into similar things to you in which the isolator chip's speed requirements created issues.  I probably should have mentioned this possibility, but I failed to think about this option during your posts. 

    I don't have visibility into the team that developed the xds100 driver, but your comments completely matched with my assessment of the situation. 
    (ie it seems like the -A grade isolators should work, but there's likely some kind of timing issue or latency requirement that is just barely being missed and therefore, they don't work)

    Note that if you plug in an emulator faster than the xds100v2 (like the xds200), you should expect to upgrade the isolators to the -M speed grade even though it may not seem obvious that you'd need to.

    ===

    Did you utilize the -A grade because of its usage in one of the C2000 kits' schematics/BOMs?  If so, let me know and I'll try to get it updated. 
    (early on the C2000 team didn't always specific the speed grade in HW documentation. I've tried to fix this over time to try and reduce the risk of customers running into what you did)


    Thank you,
    Brett

  • The use of the A version was more or less pure conicidence, since I found them first and most cheapest on the RS website ;-)
    The BOM of the C2000 launch pad lists the correct C version, but I was searching just for ISO7240 (without any letter after this). I did not order directly from digikey, since this is more paper work in my company, but this would have save me a lot of trouble 8-0
    Anyway, now it works just fine.

    Regards
    Falk