Full BSDL files with IEEE1532 commands for TMS320F28035PN

Frank D'Aliesio said:

Unfortunately I can't figure out how to make the Piccolo MCUs programmable similarly. TI does offer a "Flash API" library but it must be embedded in a custom boot loader and somehow written into the Flash before it can be used. We are facing Catch22 here - this firmware must be written in the Flash in order to be able to write to Flash.

The API can be downloaded from an external comms port as well.  It doesn't have to be embedded in the device.  For example, a small kernel + API can be downloaded through the SCI port using the boot ROM loader.  The boot ROM then transfers control to the kernel which handles the programming (i.e. interfaces between the flash API and the host). 

On 28035 the flash API library is also included within the boot ROM of the device.

Frank D'Aliesio said:

First of all, it is not feasible for my customers to go and buy CCS just to be able to program my board with a new version of firmware.

Agreed.  An example is a free programmer such as CodeSkin which uses the SCI port on the device and an RS232 on the PC.  (http://www.codeskin.com/programmer for more information).  CodeSkin also supports XDS100 and does not require a CCS install.

Frank D'Aliesio said:

The other issue is that the board must be stopped, case opened, JTAG cable connected to Piccolo's DEDICATED JTAG connector etc. I need something to be able to reprogram it in-circuit, without opening the case and connecting cables.

Some connection will need to come out to the host - it can be SCI or some other comms.  It doesn't have to be JTAG.   If the default boot ROM loader is used, then a pin will need to be toggled to start the SCI loader.  (note: in this context a loader simply loads a code via a stream from the host into RAM and then transfers control).

If pulling a pin low is not desired, a custom check can be done in OTP  (i.e. check for traffic on the SCI port, if none, then boot to flash, if yes, then call the loader in ROM).

About dedicated JTAG:

To do emulation on the MCU (e.g., to program the flash, debug code, etc.), you must use an emulator that is designed to work with the TI MCU.  You no doubt already have one of these things, which we call the "Pod". For example XDS100.  This pod will not work with the CPLD.  You will need to use whatever Pod the CPLD requires.

However, you can certainly have the CPLD and the DSP daisy-chained on the same JTAG chain (you daisy chain TDO signal from one device, to TDI signal on the next device).  What you do is configure the debug tool (e.g., Code Composer Studio for the MCU) to tell it that there is a BYPASS in the chain (i.e., the CPLD is a bypass as far as Code Composer Studio is concerned).  You can then do whatever it is you want to do with the MCU.  You would probably do the same for the CPLD tools (e.g., setup the DSP as a BYPASS in the chain), although I cannot speak for the CPLD tools since they are not a Texas Instruments tool and I don't know them.

Frank D'Aliesio said:

I can NOT use Flash API because of multiple issues -- it is not uniform with CPLD and FPGA programming (that I can do from the same JTAG chain with my own software,) it requires a separate initial programming, the Flash programming software can be damaged in the Flash thus making board inoperable and not fixable without special tools, I will need to put a dedicated connector for Piccolos to make use of those special tools and for initial programming, Flash API require using aditional pins for programming and I'm extremely limited on those.

What I would need is a full BSDL file for TMS320F28035PN so I could put them in the same chain with CPLD and FPGA and program them with my own sotware over JTAG.

I need a FULL BSDL file, with IEEE 1532 ISC commands. NOT the IEEE 1149.1 Boundary Scan info that is offered on the TI site so I don't need any SPECIAL programming devices or software to program those. I have not been able to find this file.

We have BSDL files available for the MCU, but as you noted, this is for boundary scan use and not for programming or emulation.  JTAG 1149.1 was developed for boundary scan testing.  TI hijacked the JTAG port and also uses it for emulation.  The two (boundary scan, and emulation) have nothing to do with each other.  IEEE doesn't specify anything about emulation.  That is purely a TI thing.

The C2000 MCU's are not IEEE 1532 compliant - actually I don't think they could be made compliant as the standard is for CPLD and FPGA class of devices. CPLD and FPGA can't do anything until they are programmed where as a MCU runs boot code and is alive at time zero. 

I don't believe the IEEE 1532 standard is addressing programming of flash that is embedded in an MCU (or flash/EEPROM chips that happen to be external to the MCU).  For the C2000 MCU the CPU itself does the programming by running a flash programming algorithm. This is true for ALL of our programming solutions (even in TI's production testing and even via Code Composer Studio).  For Code Composer Studio, the JTAG port is not used to actually program the flash.  Rather, CCS uses the JTAG (emulation) to stuff into the MCU the code that will do the programming of the flash, and also to transfer over the code/data that is to be programmed into the flash.

I hope this helps.  Some other resources you  may find helpful:

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

Regards,

Lori