• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 30 subscribers
  • Views 453 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Error connecting to LM3S617

Ian Smith
Prodigy 130 points
Other Parts Discussed in Thread: LM3S617, LM3S818

Hello,


I am trying to debug a problem with a Stellaris LM3S617 micro, but have now run into another problem. When I attempt to connect to the micro via JTAG I get the following message:

"CORTEX_M3_0: Error connecting to the target: (Error -1170 @ 0x0) Unable to access the DAP. 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.14.5)"

JTAG emulator: Spectrum Digital XDS200USB

CCSv5: version 5.5.0.00077

I have tested the JTAG connection using the "Test connection" button in the .ccxml editor and no errors were reported.

I have tried this with 2 different XDS200USB emulators and 1 Spectrum Digital 560v2 STM emulator. All give the same error message.

The micro has power (3.3V on pin 7). I've tried various JTAG CLK speeds, but get the same error message.

Any ideas, or is this micro no longer any use to anyone?

Cheers,

Ian

  • 0
    TI__Guru**** 244380 points
    Hello Ian

    LM3S617 has already been EOL'ed. Did you check the errata document for the same to see if there is a known cause you can associate the last working use case on the micro

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 130 points

    Hello Amit,


    I know that the LM3S617 is EOL'd. This is old hardware with a new bug that I was hoping to fix. But now I have this issue with the JTAG. The only JTAG issue on the errata is for the INTEST command. I don't believe this is the cause of the problem, the emulator works happily with the 617 on the RDK STEPPER evaluation board.

    Cheers,

    Ian

  • 0 in reply to Ian Smith
    Guru 117850 points

    My small tech firm has used that exact LM3S device - and multiple others.   (to include the famed 28 pin parts)   

    Your description strongly suggests that either:

    • You have encroached upon the MCU's JTAG/SWD pins (PC0-PC3)
    • You have a mistake w/in the System Clock set-up command
    • Your board may have insufficient or missing pull-up Rs upon the JTAG lines

    There's bad new w/such (early) LM3S parts - I don't believe that you can "recover" those early devices - should either of the first 2 bullets prove true.

    If that's the case - and you're really desperate - we may be able to share a (difficult) method which (sometimes) works.   (comforting that)

  • 0 in reply to cb1_mobile
    TI__Guru**** 244380 points
    Hello Ian

    I agree with cb1 on the possible root causes. Other than that I am not aware of any similar issues that I have seen on field returns.

    Regards
    Amit
  • 0 in reply to cb1_mobile
    Prodigy 130 points

    Hello cb1_mobile,

    Thanks for your reply. I think in this case, setting the clocks was the likely cause. Before the device lost the DAP, I was getting a crash after execution of the SysCtlClockSet function. Unfortunately, before I could investigate this I lost the DAP as described in my first post. We have now replaced the LM3S617 with an LM3S818 (and bought a load of spares!).

    On checking the SysCtlClockSet function it looked as though it might be possible for the function to clear the BYPASS bit before the PLL has locked,which the LM3S617 manual warns could render the device inoperable. I have replaced SysCtlClockSet with my own function which sets the clocks correctly, and have now discovered that on one call to SysCtlDelay, the stack pointer is not correctly restored, which results in the micro going off into the wilds of memory. At which point anything could happen. I am proceeding carefully as they say!


    Thank you for your offer of a method to recover from the loss of DAP, but for the moment I am able to continue with my work.


    Cheers,

    Ian

  • 0 in reply to Amit Ashara
    Prodigy 130 points
    Thanks Amit. As I said in my reply to cb1_mobile, I suspect that incorrect clocks setting was the root cause of the problem.

    Cheers,
    Ian
  • 0 in reply to Ian Smith
    Guru 47900 points
    Good for you Ian. And great thanks for describing your "fix" and the path which caused/contributed to your issue.

    I salute your "load purchase" of "backup" LM3S - when devices flee production - wise to have "internal" stock. (as we do w/LX4F)

    May I suggest a protective/defense mechanism - sure to comfort? W/in your Stellaris grouping should appear, "gpio-jtag.c." This small code blurb should be placed atop (all) of your programs - and enables you to (most likely) "recover" your (otherwise) "un-recoverable" LM3S devices.

    Prevention - so often - trumps any "cure." Bon chance mon ami.
  • 0 in reply to Ian Smith
    TI__Guru**** 244380 points
    Hello Ian,

    Yes, I did see the response.

    Regards
    Amit
  • 0 in reply to cb1
    Prodigy 130 points

    Thanks for the tip cb1_mobile. I've found the relevant file and will see about integrating it into our code.


    Cheers,

    Ian

  • 0 in reply to Ian Smith
    Guru 47900 points
    Good for you, Ian. This vendor's "removal" of M3 from (their) playing field - and the difficulty in recovering their (past) M3s from "misfortune" raises, "prevention" far beyond any "cure." (i.e. "normal" cure may not work w/vendor's past M3 parts)