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.

XDS560 & Stellaris (LM3S9D96) in CCS?

Other Parts Discussed in Thread: SYSBIOS

I'm trying to find the best debugging setup for a new product based on the LM3S9D96 development kit.  (More information on my situation is in my Emulation, Connection, Tracing with DK-LM3S9D96 Based Board thread.)

Ideally, I'd like to stay with CCS for cost and familiarity.  I'm planning to use SYS/BIOS.

Does CCS v5.2 fully support the XDS560 for use with Stellaris, particularly the LM3S9D96?  Will all of the XDS560 features work (like software and real-time hardware breakpoints and watchpoints, real-time monitoring of memory, ...)?

(If you have any strong recommendations for another software/hardware suite, you can let me know too).

  • Hi,

    Yes, XDS560v2 emulators fully support Stellaris, however you will need an adapter as the LM3S9D96 devkit has an ARM 20-pin connector in it. Check the page below:

    http://processors.wiki.ti.com/index.php/Stellaris_support_in_CCS

    XDS-class emulators support all debugging functionality (breakpoints, watchpoints, etc.), as well as SYSBIOS debugging features (ROV, etc.). A few things not supported are shown at the page above. Another detail is the Real-Time Mode mentioned in one of the links is supported through accessing the Debug Access Port or DAP (check here), but I would need to verify if this is also supported using XDS-class emulators. 

    Regards,

    Rafael

  • Thanks so much, I still have a lot of questions; I'll be sure to verify all your answers.

    Ok, so real-time mode is just a TI proprietary thing; the ARM chips don't really have it.  I did read this Real-Time Monitor thread that said, as you suspected, that Stellaris can only have read-only real-time access and only with the ICDI.  I vaguely remember reading somewhere that this was because the driver in the FTDI chip on the LM3S9D96 development kit used the virtual COM port in the background to transmit additional data?

    I've been looking in the LM3S9D96 manual, and there's not much documentation on the Debug Access Port (DAP).  Page 72 has a block diagram, but I don't really see any specific pins listed for it.  I guess it's not handled by an XDS interface anyway.

    When we make our board, rather than using a full ARM 20-pin connector, I was planning on making a 7 pin connector and wiring an adapter.  That should be ok, yes?

     

    I'm still not quite sure the best way to go for debugging this product.  I think this is what I understand:

    • ICDI - will allow me to read memory without halting the processor.  Downside is I need to figure out how to program an FTDI chip or another Stellaris to implement ICDI and it takes up more board space and money in the product.
    • XDS - won't give me any real-time access for the ARM processors
      • XDS100v2 - The cheapest standard debugger interface from TI available.
      • XDS100v3 - Like XDS100v2 but IEEE 1149.7 support allows for debug at 4 different levels of power operation, and multichip support.  Also includes SWO support for ARM (but apparently unused in CCS)
      • XDS510 - Seems more expensive than and being obsoleted by the XDS560v2.
      • XDS560v2

     

    1. Is System Trace different from TPIU?  Since TPIU isn't supported in CCS for Stellaris, I'm wondering if I can get printf ability through system trace with the Stellaris, or will that not work either?
    2. XDS560 vs. XDS100: With XDS560 I will get:
      1. watchpoints
      2. counters
      3. state sequencing
      4. trace
      5. system trace (at least for non-ARM?)
      6. more speed
      7. real-time read/write and background ISR's for non-ARM TI chips
      8. can purchase off-the-shelf isolation adapters for the XDS560 interface

           3. Are you saying that the SYS/BIOS features like System Analyzer and Runtime Object Viewer (ROV) are available even with XDS100?

     

  • Hi,

    I just confirmed that real-time memory works by connecting XDS-class emulators to the Debug Access Port (DAP).

    - Launch the debugger normally; it will connect to the M3 core, load the code and halt on main() or somewhere else depending on your configurations.

    - Find the address of a global variable that you need to monitor (local variables would be a bit more difficult as they may be placed in registers). Write the address somewhere.

    - Right-click on the Debug view and select Show All Cores. An additional core named CS_DAP_0 will be shown.

    - Right-click on the core and select Connect Target

    - Put the application to run and highlight the DAP core.

    - Open a Memory Browser and type the address of the global variable (the variable name is meaningless for the DAP core).

    - Click on the button continuous refresh. The value of the variable or even other memory addresses should change at regular intervals.

    The procedure above will eventually become a wiki page, but I just wanted to confirm the procedure was valid...

    Regards,

    Rafael

  • Wow, that's great to hear.  Are there additional pins other than the TDI, TDO, TMS, TCK, two grounds, and Vref that need to be connected for the Debug Access Port?

    Can't wait to hear about my earlier post too.

  • Hi,

    Wow, while I was replying you posted the questions. Well, let's start.

    Andrew Warnock said:

    I've been looking in the LM3S9D96 manual, and there's not much documentation on the Debug Access Port (DAP).  Page 72 has a block diagram, but I don't really see any specific pins listed for it.  I guess it's not handled by an XDS interface anyway.

    Check previous post.

    Andrew Warnock said:

    When we make our board, rather than using a full ARM 20-pin connector, I was planning on making a 7 pin connector and wiring an adapter.  That should be ok, yes?

    It is really up to you, provided you keep the JTAG connections short enough to maintain signal integrity. A good reference on pinouts and signals is at the page below:

    http://processors.wiki.ti.com/index.php/XDS_Target_Connection_Guide

    Stellaris devices do not have any of the Trace capabilities of their bigger brethren (Sitara, Davinci, etc.), therefore you can get by with the basic JTAG pinout. However, keep in mind that ARM has standards for 10 and 20-pin connectors, while TI has a 14, 20 and 60-pin connectors, which could help in scenarios where you don't have an adapter handy. Connectors are shown at the page below:

    http://processors.wiki.ti.com/index.php/JTAG_Connectors

    Andrew Warnock said:

    I'm still not quite sure the best way to go for debugging this product.  I think this is what I understand:

    • ICDI - will allow me to read memory without halting the processor.  Downside is I need to figure out how to program an FTDI chip or another Stellaris to implement ICDI and it takes up more board space and money in the product. - YES
    • XDS - won't give me any real-time access for the ARM processors - NO. Check previous post.
      • XDS100v2 - The cheapest standard debugger interface from TI available. - YES
      • XDS100v3 - Like XDS100v2 but IEEE 1149.7 support allows for debug at 4 different levels of power operation, and multichip support.  Also includes SWO support for ARM (but apparently unused in CCS) - Not sure if Stellaris M3 cores support cJTAG.
      • XDS510 - Seems more expensive than and being obsoleted by the XDS560v2. - YES
      • XDS560v2
        • Faster than XDS100 - YES
        • Advanced Event Triggering - Apart from Trace and System Trace, everything else is supported by XDS100.
        • Unlike XDS100, standard isolated adapters for ESD / high voltage / noise protection are available for XDS510 and XDS560. - I guess the TI page for the TMDSADP1414-ISO adapter is outdated, as several C2000 development boards have isolated circuitry along with XDS100 emulators (the 14-pin JTAG connector and signaling has no different between all XDS emulators).

     

    1. Yes. System Trace is a subsystem available in Sitara and DaVinci devices that comprise a series of features that use TPIU to perform data transfer from the device. Regarding the printf() support, I think this is supported as of today. Need to check.

    2. Check the quote above...

    3. Yes. Obviously the data transfer speeds will be slower with a XDS100 emulator.

    Answering your last question, yes, the signals you mentioned are enough to access the DAP. Any questions check the wiki references sent above.

    I think I did not forget anything...

    Regards,

    Rafael

  • Wow, you've been super! :)

    So in summary, since we won't be using Sitara or higher-level MCU's in the known future, I won't ever have a need for system trace.  As for trace, it sounds like as long as I'm using SYS/BIOS, I can get just-as-good debugging through the SYS/BIOS tools so spending the extra money for XDS560v2 right now probably isn't for me, unless I really need the faster speed.  I had no idea watchpoints and counters were available in XDS100.  Sound good?

    Yes, that TI page for the TMDSADP1414-ISO adapter is confusing by not mentioning XDS100.  So all of those adapters are compatible just fine with XDS100 then too?

    Although, it looks like I won't be needing it.  I have an Experimenter Kit (used with controlCARDs for C2000) and it can function as a XDS100 (v2?).  It has the TI 2x7 JTAG connector, so all I need to do is buy a standard 2x7 JTAG cable, right?  Or make my own as I said before.

    I did check the schematic for the Experimenter Kit, and it does have some protection on the USB data lines with series resistors and some diode clamps to Vcc and ground (BAW567).  No idea what level of ESD protection that gives you, but there seems to be no documentation of how much ESD protection you get with the TMDSADP1414-ISO either.

  • Hi,

    Andrew Warnock said:

    So in summary, since we won't be using Sitara or higher-level MCU's in the known future, I won't ever have a need for system trace.  As for trace, it sounds like as long as I'm using SYS/BIOS, I can get just-as-good debugging through the SYS/BIOS tools so spending the extra money for XDS560v2 right now probably isn't for me, unless I really need the faster speed.  I had no idea watchpoints and counters were available in XDS100.  Sound good?

    Yes, the XDS100 seems to be a reasonable option for your needs. However, keep in mind the extra circuitry and the opto-isolators reduce the JTAG speed, which can also affect the performance in real-time memory monitoring. I then expect the use of a XDS100 + an isolation adapter + a TI-to-ARM adapter may slow you down considerably (if you use one of the ARM JTAG standards).

    Andrew Warnock said:

    Yes, that TI page for the TMDSADP1414-ISO adapter is confusing by not mentioning XDS100.  So all of those adapters are compatible just fine with XDS100 then too?

    Yes. These adapters are manufactured by BlackHawk and I just double-checked with them that XDS100 is supported. Their page has better details on circuitry and characteristics.

    Andrew Warnock said:

    Although, it looks like I won't be needing it.  I have an Experimenter Kit (used with controlCARDs for C2000) and it can function as a XDS100 (v2?).  It has the TI 2x7 JTAG connector, so all I need to do is buy a standard 2x7 JTAG cable, right?  Or make my own as I said before.

    I am not sure which card you have, but usually its 14-pin connector is only one way - i.e., you can connect an emulator to it to debug the controlCARD, but it cannot be used to connect to an external board.

    Andrew Warnock said:

    I did check the schematic for the Experimenter Kit, and it does have some protection on the USB data lines with series resistors and some diode clamps to Vcc and ground (BAW567).  No idea what level of ESD protection that gives you, but there seems to be no documentation of how much ESD protection you get with the TMDSADP1414-ISO either.

    The BAW will give some 50~100V of reverse protection, but the ISO adapters have 1.5kV of galvanic isolation - i.e., there are no electrical connections between the two sides (thus the performance penalty). Some details are in BlackHawk's page sent before.

    All in all, my suggestion is: start with a XDS100v2 (lowest cost emulator, free CCS licensing), check its performance even when associated with the ISO adapter and then decide if the performance is acceptable. Then move on to a faster emulator if required.

    Regards,

    Rafael