TMS320F28377D: options for continuously data logging variables within TMS320F28377D firmware

Nick,

Thanks for reaching out to the E2E forum. 

1)I need to look into these numbers a bit more, if you look a bit further down at the F28335 device(also a C2000), the numbers are quite a bit better for both load and save with the XDS110.  The F28379D should be no worse than that device based on pure specs alone.  

I also see where they clocked the XDS110 at 10MHz for the F28335 vs 8.5MHz on the F28379D.

2)From what you have described I think we can focus on the binary save benchmark.  In this case, with the XDS110 listed the report is giving 120kB/s which should suffice.  With that said I want to be cautious here, as I believe that DSS(using the JTAG to extract data) has to insert these commands in parallel with whatever CPU activity is ongoing on the device, so we would need to understand that loading.  If you have the 2nd core free/less loaded it would probably be a good hedge to save your data to shared memory so we could DSS on the 2nd core.  

3)I think the debugger method is the right way to go for cost/complexity reasons.  However, if we end up going down a dedicated comm channel path, we can leverage the DMA of the F2837x device to remove the CPU from the critical path or perhaps the 2nd core.

Best,

Matthew

Hi Matthew,

Thank you! Okay based on your reply, I have some further input from the customer.

I am also very confused about the state of PC software support for data logging.  It is hard to sort out what hardware features are supported and which ones are deprecated since these part families have such a long history.  It hasn't been helpful that the TI Wiki was recently closed, because many of the links that might have answers are now dead. Is there a new location in the dev.ti.com portal for this information?

• For example, RTDX and HS-RTDX seem to be exactly what we want on paper.  However, I can't find data rate specs and I have read they are both deprecated since 2010 or so.  Why?  And what is the suggested replacement?
• Likewise, Section 7.8 of SPRU430F documents a DMA interface for JTAG reads of RAM buffers which seems very useful, but I can find no information at all about how this data would appear on a PC or in CCS.  What is the software interface for this feature?  Has it ever been supported by TI software?  Is that document even relevant to the F28 parts (C28 vs F28)?
• The TRM for our part, SPRUHM8H, Section 3.4.6 lists a "CPU Data Logging Interrupt" called "DATALOG", but it is not mentioned anywhere else in the TRM or other TI documentation.  I'm assuming that it's related to the "DLOGINT" interrupt mentioned in 7.8.3 of SPRU430F, but I'm not sure.  Either way, I have no idea how that would be used by a JTAG debugger and CCS.

I do know that CCS can graph JTAG debugger watch variables over time at a continuous update display rate of 10Hz (ideally) using standard memory reads. I've tried it and it works, but it's slow. I haven't measured the data rate we get, but I don't think it will be sufficient for our use case.

I also know that the same feature can read a RAM buffer (not just a single variable), but I don't know how quickly the different JTAG debuggers will actually read the data. So it's hard to determine how large our RAM buffer would need to be between 100ms updates (at least 10kB or 20kB to account for jitter). I suppose we would need two ping-pong buffers so we can write to one while the JTAG is reading the other, but since the CCS IDE would be controlling the refresh rate, I'm not even sure how I would synchronize those. That's what makes the above DLOGINT feature appealing (the chip schedules transfers, not the PC).

Nick,

SPRU430F is relevant, and I suspect that DSS might be using the DLOG functions to co-ordinate its transactions but I don't have the complete info off hand.

Agree that there is little info on how to implement this oneself, I need to pull some others into the conversation to better understand this.

I don't have any info on RTDX and why it was dis-continued unfortunately.

I know that our digital power team has implemented this to an extent with the SFRA tool, I'll loop them in as well.

It may take longer than usual given the weather here in Texas, alot of folks are without power/internet or both at the moment.  I'll do my best to get back to you before the end of the week, but it may be until next week that I can get input from others.

Best,

Matthew

Nicholas Carley said:

For example, RTDX and HS-RTDX seem to be exactly what we want on paper.  However, I can't find data rate specs and I have read they are both deprecated since 2010 or so. 

I found the old (Copyright 1995-2008) C28x Technical Overview webpage which says:

...and a powerful 20Mbit/s data logging debug capability

The screen shot on the webpage shows Code Composer, which predates Code Composer Studio.

Nicholas Carley said:

I'm assuming that it's related to the "DLOGINT" interrupt mentioned in 7.8.3 of SPRU430F, but I'm not sure. 

Section 7.8 Data Logging of SPRU430F has some explanation of how data logging is used from the point of view of the C28x CPU, and has the definitions of the data logging emulation registers. With a TMS320F28379D, in a CCS 10.2 debugging session used the Memory Browser to attempt to modify some of the data logging registers mentioned in SPRU430F appears to show registers exist there (in that can write to a register then read back the results).

However, haven't yet found if there is support in CCS 10 / current JTAG debuggers to allow the host PC to extract logged data via this mechanism.

Nick,

To add on to what Chester has mentioned, both DLOG and RTDX does indeed pre-date the current CC Studio. 

DLOG was something that was legacy carry over from an earlier C2000 core (C27x) before our tool chains had support for any kind of datalogging via JTAG.  This was never formally supported on the C28x, but was included for migration reasons when C28x released to the market(early 2000's)

RTDX was introduced as part of CCS v3.x sometime in the mid 2000's for all TI MCUs/processors that gave a dedicated set of functions that could be added to a project to enable data transfer across the JTAG.  I'm not precisely sure why we discontinued support for this product(I used this myself during that time), but was a TI wide decision.

Given what I've said earlier about how DSS works(uses C28x idle time to extract data) this may not be the best option for what you want to do(sustained data rate).

I think a more straightforward approach would be to use the SPI or McBSP comms to export data to a transceiver that could then send the data to your host PC.  Reason I have picked these vs the SCI is that both are accessible by the DMA, so that you'd not need to use any CPU cycles to send the data.  McBSP may be more attractive since you can emulate a SCI and use simple UART type comms back to the PC.  In either case, you'd need to add a transceiver into the mix.

If you are using the LaunchPad or controlCARD, we do have a UART backchannel embedded in the XDS100v2 that would use the existing JTAG USB connection to talk back to the host PC.

Let me know what direction you'd like to go and I'll help the best I can.

Best,
Matthew

Hi Matthew,

Thank you very much for looking into this and providing some answers and history.  It is good to know that JTAG is not the best path forward for this and that DLOG and RTDX are old features that are no longer supported.

My team and I are now checking pinouts and looking into how we can connect to the SPI or McBSP pins on our existing boards.  It's good to know that those peripherals support DMA.  I agree that UART signaling would be the most simple solution in terms of driver software on the PC.  Thanks for letting me know that the McBSP can do that.

The McBSP goes up to 50Mpbs, so we'll likely be limited by the speed of our PC interface adapters and any differential/optical signaling we'll need to reject EMI.  I've found FTDI UART to USB adapters that go up to 12Mbps which is sufficient for our needs.  But I still need to find a differential/optical adapter that can keep up.  I've also seen SPI to USP adapters (from Diolan) that go up to 48MHz, but then we'd be using different drivers to handle SPI.

I think all of my questions are answered for now, but I will let you know if I have any more on this topic.

Thanks again,
Remington