Part Number:TMS320VC5509A
Tool/software: Code Composer Studio
This is just one of the meanwhile well-known libraries and siliconbugs of TI5509/ 55xx/5509A chips, which should have been familiar for a long
time by now to the development department of TI , but in forums are only seldom or never treated. (TI is only letting us down!)
I will describe an error that I have been searching for for five years and that always causes problems for my clients and my products every day.
The damage is enormous! I would never have found it on any of the documentation or forums of TI.
TI has never ever dealt with any of my questions, not to speak of qualified answers or treatment of my reports in their libraries or chip_bugs
Even worse, in their current development area CCS3.3 - chips, which they keep on selling today, are not supported. Essential debug-processes
are not possible here anymore, (on 5509a..) because it would cost some time.. to secure the downward compatibility. It is important to say this here!
Us developers are always yet again left alone. Nobody has ever closely examined my precise descriptions of these bugs: "I will forward this...",
but never another reaction after that and never was a problem solved -- for more than 20 years that I have worked with this chips!
This additional (one mor unsolved..) error describes the SPI mode of MCBSP - I guess for all chips, also 66xx and 55xx, but I have only tested on
5509A.
I also described a mistake in the transmission of linked lists in the USB_Controller of the same chip. I know that this is a library mistake -
"probably not reentrante Interrupt Functions" in the "TI" USB_LIB. It remained without reaction or treatment by the producer for many years.
And it is still erroneous today! following error:
In case you sometimes suspect a reading or writing error with the mode CLKSTP=03 configurated SPI master of a 5509A or of all other MCBSP
of this brand, you are probably mostly right! At least when the chip 5509A runs near its limit frequecy of 200Mhz (for me 192 Mhz), you should never!!
trust a single flag of the McBsp of the chip, if you really have to know the status! (especially with #inline)
This bug then leads to displaced data in the receiver array or unwritten "last cells" when writing with the usual drivers, especially in combination with
using a DMA. In case you know this rare error of maybe all >1000 times, then you are correct here! My tag is accordingly as follows: "saving error on
MCBSP SPI of TI, bug: MCBSP_xrdy MCBSP_xempty MCBSP_rrdy" It may happen that the flag "xempty" is true, even though I just sent data in the
transceiver. Only very shortly, but yes, it may happen! Therefore the only possible sequency to secure that the value is really transmitted even under
the highest speedrate:
- while (!MCBSP_xrdy(spi_Mcbsp)); // sequence secure send 1.part
- while (!MCBSP_xempty(spi_Mcbsp)); // sequence secure the send 2nd part
only one question 2 “xempty“ without prior xrdy leads immediately after MCBSP_write16..
sometimes to true!!, even if these data have not been "discovered" - and thus to one value "more" for example in the later receiver, than what
we have thought. Same with the bug in the mcbsp_spi receiver: again my search and some errors without any help from TI - even when
asking them for help! Only, „such sales and forget it”…
This error happens a lot, when a DMA sends the data of a transmission, while as common earlier the command (command + e.g. flash "dummy"_Writes)
was sent before only from DSP_Core (native Code). In order to make sure in any case that the MCBSP_SPI has really transmitted the command and
the DMA can now be started for the data, the following sequence is absolutely necessary to make sure that for example receiver data is not displaced
by one address like every >1000 writes / reads with a full speedrate. After the last Tranceiver_Byte ( here a Dummy_byte ) for the command sequence
following demands are absolutely necessary in this order, before starting the DMA:
… last part of the (CPU) command sequence…
MCBSP_write16 (spi_Mcbsp,( ((command<<8)&0xFF00) | (ushort)((dest_adr>>16)) ));
while(!MCBSP_xrdy(spi_Mcbsp));
MCBSP_write16 (spi_Mcbsp,((ushort)dest_adr & 0xFFFF) ); /* Prime MCBSP DXR */
while (!MCBSP_xrdy(spi_Mcbsp)); // Sequenz„only for shure“Data out 1.Part
while (!MCBSP_xempty(spi_Mcbsp)); // Sequenz„only for shure”Data out 2.Part
(please see comments, why both alone are error_ready also someone after are realy trasnsfer…)
DMA_start(Spi_Storage_xmt_Dma); // Now: Enable DMA channel for to begin transfer
The same problem occurs for the receiver! If I want to be sure that it is really empty, I ask before starting the DMA:
MCBSP_write16 (spi_Mcbsp,( ((command<<8)&0xFF00) | (ushort)((dest_adr>>16)) ));
while (!MCBSP_rrdy (spi_Mcbsp)); // Sequence „only for shure“Data realy out 1.Part
while (MCBSP_rrdy (spi_Mcbsp)) // Sequence „only for shure”Data realy out 2.Part
MCBSP_read16(spi_Mcbsp); // dummy read
Otherwise I have to live with the mistakes that TI has built in and that no-one there! will ever take care of!!
Sales and forget it… I haven't found a single source or documentation that describes this error.
Attention: reading/writing errors McBsp SPI.
Why did I 20 years ago choose AMD_DSP - was it the same mistake as Microsoft and X86_Intel instead of Motorola 68xx???
Never, never! trust this brand! Take a different signal processor, I have many years of experience, no-one here has ever helped
me. This should be a warning!
especially with inline