• State
  • Locked Locked
  • Replies 15 replies
  • Subscribers 82 subscribers
  • Views 1553 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F280045: (Error -2131 @ 0x0) Unable to access device register

Mike Twieg1
Intellectual 390 points
Part Number: TMS320F280045
Other Parts Discussed in Thread: C2000WARE

After getting help in a previous thread I've been able to make a lot of progress developing my custom board, but I'm intermittent occurrences of "Error connecting to the target: (Error -2131 @ 0x0) Unable to access device register. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.628.3)". I've read through a lot of other threads regarding this error, but my circumstances are someone odd.

Basically, I can power up my custom board and start a debug session via my XDS200 and Blackhawk JTAG isolator. However, after halting the debugger and trying to start a new session (to upload modified code, for example), I will sometimes (maybe one out of four) get the error. And once I see this error, it will persist until I completely power cycle the board. 

Some other potentially useful clues:

  • Even resetting via pulling XRSn low has no effect.
  • While debugging I am often controlling a large SMPS on the same board. But I've never seen any debugger issues appear while in the middle of a JTAG session. And that power circuitry is always disabled when I halt one session and attempt to start another. So I don't think EMI is the culprit. I believe it's actually occurred without ever activating the SMPS a couple times. I also don't think ESD is a factor.
  • But even after the issue manifests my blinking LEDs suggest that the code in FLASH is running as I would expect.
  • I've seen this behavior on all three of my custom boards so far. I even reflowed the MCU one just to make sure it wasn't an assembly defect. The previous thread I linked above shows the JTAG connections on the custom board, I believe I've followed the hardware guidelines faithfully.
  • I've tried watching the supply rails on a scope for dips/bumps/spikes, but haven't seen more than +/-100mV on VDDIO and VDDA and maybe +/-40mV on Vdd.

Basically I haven't been able to correlate this behavior with anything else. Any suggestions are appreciated.

  • 0
    TI__Guru 50611 points

    Hi Mike,

    As LED is flashing, I am assuming you have code running from flash and the board is in 'Flash Boot' mode. Have you tried in 'Wait Boot' mode? Do you observe same behavior when the board is in 'Wait-Boot' mode?

    Thanks & Regards,

    Santosh

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    Hi Santosh, thanks for the quick reply.

    Yes my boot mode pins (GPIO24 and GPIO32) have 2K pullups on the board, so I should always be in FLASH boot mode.

    At what point in the sequence are you suggesting I set the bootmode pins for Wait mode? Before starting the first debug session? After ending the first debug session but before starting another?

    Regards,

    Mike

  • 0 in reply to Mike Twieg1
    TI__Guru 50611 points

    Mike,

    We can try two experiments,

    1. Set 'Wait-Boot' mode from the beginning, launch debug session, you can load the code, run it. Then halt the debug session, reset the board, and try to connect again.
    2. Follow your normal sequence, when it fails to connect, put the board in 'Wait-boot' mode, reset the board and connect again.

    Please let me know if you are able to connect in the two scenario mentioned above.

    Thanks & Regards,

    Santosh

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    Hi Santosh,

    I spent more time yesterday on this project and got it into the bad state again, so I tried your experiment 2 by pulling down GPIO24 to GND, resetting the MCU with XRSn (all without cycling power), then trying to start another debug session. No change in behavior, got the same error message as before.

    From that point on I left GPIO24 tied low after power cycling. So far I haven't had the error -2131 pop up again, nut I only had to restart the debugger a few times after that, so I'm not yet convinced it's actually resolved the issue.

    What does this tell us?

    For experiment 1, should I leave GPIO24 tied low during that entire process, or go back to Flash boot mode before resetting?

    Also, something odd that might be related. After I started debugging from the Wait boot mode, I had problems with graphs in CCS. I had already set up several graph windows which were working fine in previous debug sessions, but now when starting a new session the graph is blank except some text saying "current cpu is null," similar to what's shown in the screenshot in this thread. If I try to add new graphs from the "tools" menu I cannot, the icons are greyed out. I found that the only way to get my graphs back is to restart CCS, and set everything up again, very frustrating. This happened twice in the two hours I was working on it. Not sure if this is related to the JTAG error, but I have never seen this behavior before.

  • 0 in reply to Mike Twieg1
    Intellectual 390 points

    Today I started getting the error even when the MCU is always in Wait mode. Still not observing any real pattern governing when the error happens.

  • 0 in reply to Mike Twieg1
    TI__Guru 50611 points

    Can you try any C2000Ware example, and do you see same behavior? Do you use Watch-Dog timer?

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    Hi Santosh,

    I loaded the example project led_ex1_blinky (in \C2000Ware_4_00_00_00\device_support\f28004x\examples\led\) into my workspace. To use it with my board, I changed its debug configuration to use the same target configuration as my original project (so it refers to the correct part and debug tool). I verified that when my board is in its "normal" state, I can load the blinky project, and it blinks one of my LEDs.

    I tried halting and restarting the blinky debug session many times, but haven't seen it get into the "bad" state again (again, not yet convinced it won't happen eventually though).

    I then went back to debugging my own project and eventually ended up in the bad state. I then tried loading and debugging the blinky project, but see the exact same error message.

    As for the WD, I'm not making use of it in my source code. I'm using the default f28004x_codestartbranch.asm, which I believe disables the watchdog before I get to main(). When debugging I'm also using the default f280045.gel file, which also disables the watchdog (I think).

  • 0 in reply to Mike Twieg1
    TI__Guru 50611 points

    Mike,

    Is it possible to reproduce the issue on my setup/TI EVM? If you can share trim-dowm project which can reproduce the issue, it will be easier to debug?

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    Hi Santosh, I've managed to get into the bad state without my custom project being involved (but still on my custom boards). Here's an example sequence of events I'm seeing:

    1. Power up board. XDS200 debugger already connected.

    2. Make blinky my active project/debug configuration. Use CPU1_FLASH build configuration.

    3. Launch debugger. Session successfully launches, halts at main().

    4. Resume execution. LED blinks as expected. Can suspend, resume, set breakpoints as normal.

    5. Assert XRSn by pressing the XRSn button on my board.

    6. Debugger immediately suspends, shows "no source available."

    7. View disassembly, see that I'm at an ESTOP0. I also checked the NMI registers, but they're all at default values.

    8. Halt debug session.

    9. Attempt to launch new debug session.

    10. Sometimes the debugger launches normally. But often I get the Error -2131 @ 0x0, which persists until I cycle power.

    11. Strangely, even if I assert XRSn again, the MCU still seems to be stuck (no LED blinking). Only a power cycle helps.

    I've attached a zip with my modified blinky project, including my target configuration for the F280045. Not sure if my debug configuration is in there or if that's in my workspace...

    Now I'm curious as to what this strange state is where where even a reset seems to not work...

    2112.led_ex1_blinky.zip

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    As for trying to duplicate with a TI EVM, I'm not seeing the point in that. Such a setup would have no overlap with my custom application (different MCU, different debug tool, different project, etc). I will see if I can dig up a F280049 launchpad, if I have extra time...

  • 0 in reply to Mike Twieg1
    TI__Guru 50611 points

    Mike,

    Thanks for sending the code. I have F28004x controlCARD with external xds200. I will try to reproduce the issue. Let me know if  we have a way to produce on TI EVMs.

    Thanks & Regards,

    Santosh

  • 0 in reply to Santosh Jha
    TI__Guru 50611 points

    Mike,

    Just wondering if you are able to resolve the issue or it is still having the issue?

    Thanks & Regards,

    Santosh

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    Hi Santosh,

    I did try loading a blinky project onto my F280049C launchpad, but could not replicate this behavior. Not at all surprising, it's an apples-to-oranges comparison. I still regularly encounter the behavior on my custom boards, still no clear pattern. Anything on your end?

    It's become a major challenge since the boards are now being evaluated in-system. Basically that means that there are times where a board or the system it's installed in has exhibited some interesting behavior, and I want to connect a debugger to the target to inspect its state. But when this problem manifests, then there's no way to connect to it without power cycling, which also resets the state I was hoping to inspect. Very frustrating.

    I looked over the F28004x documentation and found that it recommends putting pull up resistors on TDI, TDO, and TMS. Probably a longshot, but I'm going to hack those on a board and see if it changes things.

    Also I may try changing my target configuration to use cJTAG (like the F280049C launchpad) instead of JTAG, and using the XDS110 on the launchpad to debug my custom board. Again definitely a longshot, but that should eliminate at least a couple of the differences between the Launchpad and my custom board.

  • 0 in reply to Santosh Jha
    Intellectual 390 points

    I think I've asked this in the past, but does TI make any dev boards which use a F28004x in the RSH package? Preferably which can also be used with full JTAG (not just cJTAG)?

  • 0 in reply to Mike Twieg1
    TI__Guru 50611 points

    Mike,

    You can use F280049C controlCARD. It uses XDS100v2.

    https://www.ti.com/tool/TMDSCNCD280049C