TMS320F2837xD JTAG initialization

Avinassh,

Check this post: e2e.ti.com/.../1906656

There is a difference between F28377D device and other devices that you mentioned with regards to JTAG connection. F28377D has an additional router to connect to CPU TAP.

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks for the quick response. However, one thing is still not clear. Where do I find information regarding what JTAG commands to send? Is there no document from TI which explains the JTAG init sequence? Because in the thread which you sent, it is proposed to request from CCS who seems to make their own stand alone solution just like us.

Thanks in advance,
Avinassh.

Avinassh,

I asked our emulation team to comment on this.

Thanks and regards,
Vamsi

Thanks for the link. But, looking into the device datasheet (SPRS880F, Revised May 2016),  in page 4, under Functional Block Diagram, I do not find any ICEPick Module.

I will try to add the core using ICEPick. However, after I add the core using ICEPick, is there any document explaining what commands need to be sent to the MCU (for initializing JTAG, writing/reading from ram, and so on) before accessing the flash? 

Best Regards,

Avinassh

I would like to add one more question. In the TMS320F2823x/33x, there were secured and unsecured RAM regions available. But in the datasheet from TMS320F28377D, I do not find any information like that.

And one more update:
I was able to read ICEPICK ID = 0x411221CC0 and IDCODE = 0x0B99C02F. However, still reading of flash just keeps returning 0x893D. So, I do need to know the commands to be sent for initializing jtag and writing/ reading flash and RAM.

Avinash,

"Table 6-6. Memory Types" in device datasheet has the info related to secure and non-secure RAMs.

Regards,
Vivek Singh

Avinassh,

In your original post you asked, "Is the JTAG initialization different from TMS320F2806x/F2803x/F2823x/F2833x?"   

The answer to that is "no" expect for differences due to the ICEPick. Do you have the information you need to debug the cores you mentioned above, or are you still looking for the debug specification for the C28x family devices?  That you asked the above question and followed by asking only for the differences led me think you already had information on how to debug those devices.

When you're scanning through the device after selecting it via the ICEPick, you do need to remember that you are still scanning through ICEPick. The IR path length would be the C28x core plus the ICEPick for a total length of 44 bits (38 + 6).  When talking to the C28x core, make sure to scan all ones into the ICEPick (keep it in BYPASS, the last six bits scanned).  And if you need to scan through the DR path, remember that the ICEPick's DR BYPASS register (1 bit) will be there.

Meanwhile, I'm trying to locate the C28x debug spec to forward if you still need that.

Edward,

Thanks for the info. I would still appreciate sending me all the documents which you have regarding C28x debug spec and any other information with respect to this MCU.

Avinassh, 

The documentation is only available through the Emulation Developer Community.  If you have access, you may use this link to access the software.

www.ti.com/mysecuresoftware

Click the red Access button for the Emulation Developer Community - Emulation TRM.

Then select the file 28x_ETRM-1_1_0-Setup.exe (C28x debug IP).

That file contains the TRM for C28x debug via JTAG.

In addition, I've compiled an FAQ and errata for the document which I've copied here:

“The document spruf82_c28x seems to contain some inaccurate information. “

That is true.  At best, some of the instructions are confusing.  And there is at least one section that is wrong.  This FAQ should help answer many of the questions regarding the document.

“Figure 3-1 on page 20 seems not to be in line with JTAG as it seems to show DR and IR as same.”

Yes, that is a confusing diagram. What it should state clearer is that the C28x debug does not use the JTAG DR scan path.  Every scan is through the IR path and includes both 6 bits that work as a traditional IR scan value and 32 bits that work like a DR payload. You don’t scan in a value into the IR and then scan through the DR like you would for most JTAG devices. Instead, both are combined into a single IR scan every time. (There are DR scans for standard JTAG registers like IDCODE, and there is a DR scan supported that always returns the C28x SSR.)

"How do we setup JTAG debug mode?"

The general steps would be:

   Put the target into Test-Logic-Reset (either pull TRST low, or hold TMS high will toggling TCK for at least 7 cycles)

   Execute an IR path scan to write a value of 0x000000aa into DC_STRBS

"How do we read/write program memory ,data memory, cpu register?"

For program memory, see spruf82_c28x, section 3.2.4.1.  Also refer to Appendix B.

Data memory and registers work similarly, but the info in section 3.2.4.2 is incorrect.  Use the following instead.

Address Fields:

26:24 MUCYC[2:0] Indicates the type of DT-DMA cycle to perform:

    0 = Program Memory

    1 = Data Memory

    2 = Register (see table of register indexes)

    ...

23:0 ADDR[23:0] 24-bit address.

C28x Register indexes:

   0    XAR0    (32-bit)

   1    XAR1    (32-bit)

   2    XAR2    (32-bit)

   3    XAR3    (32-bit)

   4    XAR4    (32-bit)

   5    XAR5    (32-bit)

   6    XAR6    (32-bit)

   7    XAR7    (32-bit)

   14   SP      (22-bit)

   320  IC      (22-bit)

   6    RPC     (22-bit)

   224  ACC     (32-bit)

   256  P       (32-bit)

   160  XT      (32-bit)

   192  ST0     (16-bit)

   11   ST1     (16-bit)

   12   IER     (16-bit)

   13   IFR     (16-bit)

   9    DBGIER  (16-bit)

   10   DP      (16-bit)

   8    ORIFR   (16-bit)

   (indexes are decimal values)

“What exactly is register ORIFR?”

I do not know.  The register is not implemented in our debug driver and doesn’t seem to be accessible from CCS.   It’s probably safe to ignore it.

"How do we run application code in ram?"

Control execution via the Run State Machine Control bits (EXE_DIR) in the MF_REG_0 register.  See section 3.2.7 and Appendix B.

"What is the protocol of C2000 JTAG interface?"

JTAG 1149.1

"Why do I have to retry some debug steps for them to work?"

The debug logic in the C28x is driven by the TCK clock.  If your JTAG probe does not have a free-running TCK, then it necessary to run some extra TCK cycles at the end of each scan to ensure the debug logic remains active to act on your last command.  Make sure you execute an additional 16 cycles of TCK at the end of each scan.  Also, you should run TCK some while TRST is low and after releasing TRST to ensure the debug logic is fully initialized.

"How do you do a system reset?"

That depends on what you mean by system reset.  You can reset the debug logic via TLR.  You may be able to do a CPU reset.  You may be able to do a device level reset if the device has an ICEPick router.  But you cannot do something like a board level reset or power on reset.

To do a CPU reset on the C28x, you follow this basic procedure:

   Set the reset bit in MF1

   Execute a single step on the core (required to actually do the reset)

   Check SSR until you see the reset acknowledged

   Clear the reset bit in MF1

"Why isn’t my target responding to memory requests?"

Your target may not be allowing debug requests.  This is controlled by the DBGM bit of the ST1 register.  You can override this by setting additional bits in MF0:

#define MF0_QUAL_LD        ((UINT32)0x00000080) /*  7 Load QUAL fields(6:0) */

#define MF0_IGN_HPI        ((UINT32)0x00000040) /*  6 1=Ignore HPI          */

#define MF0_IGN_DBG        ((UINT32)0x00000020) /*  5 1=Ignore DBGM         */

#define MF0_IGN_ALL        ((UINT32)0x00000060) /*  6:5  Ignore HPI & DBGM  */

#define MF0_DFR_MASK       ((UINT32)0x0000001F) /*  4:0  DFR                */

Setting the QUAL fields allows you to force debug access.  Set MF0_QUAL_LD to set these bits.  Ignore HPI tells the debug logic to let you halt while the application is executing a “high priority interrupt”.  Ignore DBGM tells the debug logic to ignore the state of the DGBM bit in ST1.  And you should set the DFR, Debug Frame, to -1 initially.  So the value loaded into MF0 to halt the core should be:  0x00080FF.

"Why can’t I connect to one of my boards?"

If the CSM is locked, you cannot debug the target.  You’ll need some way other than the debugger to unlock the board.  (Some boards use pins on the chip to configure specific boot modes to let you flash the chip to recover.)

 

Hi Vivek,

Yes. The issue has been resolved.  Thanks for the support.

Regards,

Avinassh.