Part Number:TMS320C6713B
Hello,
My customer reports an issue when trying to send data with the McBSP. As I do not have knowledge of this processor to dig into this case, could you please look into it? Thank you.
Best regards,
François.
CASE DESCRIPTION:
We using the MacBSP #0 resource of a TMS320C6713 to implement a SPI master driver.
After configuring the resource, and trying to send the first byte of data through this link - writing into the DXR register - our software is then stuck in an infinite while loop, waiting for the XREADY bit to indicate “ready” status in the Serial Port Control Register (SPCR).
The software gets stuck for 25% of the trials.
When this happens, we observe that:
1.The DX – data transmit pin – is silent, i.e. no data at all is delivered.
2.The CLKX – associated transmit clock – is silent too.
a.We also observe that CLKX signal leaves the hiZ state to a permanent state, which means that the CLKXM bit is properly configured.
3.The McBSP is configured to be driven from internal CPU/2 clock frequency.
a.This internal clock is present.
4.The board is at -6°C
MORE DETAILS, with source code and scope screenshots on Box:
We using the MacBSP #0 resource of a TMS320C6713 to implement a SPI master driver, as per literature reference SPRU580G, déc. 2006.
After configuring the resource, and trying to exchange the first Read/Write byte of data through this link, the DSP stucks in a “freeze” state.
Here are the high level implementation choices. We choose a bi-directional SPI link,using CLKG as in the internal clock source, without using the internal frame generator.
We choose CLKX frequency = CLKR frequency = 1 MHz.
We choose not to use DMA at all to service DXR and DRR , but only CPU write/read instructions i.e. using the said “polling method.
Next is a detailed log of observations. Please find the raised questions at the end.
When the issue happens, we observe that:
1.No more instructions are executed by the CPU when it freezes almost at the end of the attached source code.
2.The current consumption of the board does not increase as expected when the subsequent source code goes deeper in the SW application that uses >80% of CPU real time budget.
a.This is illustrated by the red trace in the .png oscillogram attached.
3.The CLKX – associated transmit clock – is leaving the High-Z state as expected, as we go through the attached source code, in 100% of cases.
a.This signal is illustrated with the blue trace in the .png oscillogram attached.
b.We understand here that the CLKXM bit is properly configured.
4.Some occurrences of the problem are recorded while 16 CLKX periods are captured as shown in the attached picture. However, the remaining occurrences exhibit NO CLKX periods at all.
5.The McBSP is configured to be driven from internal CPU/2 clock frequency.
a.The CLKS pin receives a ~63 MHz clock from the DSP’s CLKOUT D10 pin, while the CPU clock is running at ~300 MHz.
b.All observed cock signals frequencies match the expectations.
6.The board is at -6°C. At this temperature the DSP freezes with a 25% probability.
7.The problem occurs whatever the source code, i.e.
a.With “SpiDriver_best_try.cpp” which is our best effort to follow Ti’s SPRU580 litterature
b.AND with “SpiDriver_initial_version.cpp”.
QUESTIONS:
1.In our code “SpiDriver_best_try.cpp, can you see any showstopper that could explain the CPU freezing ?
2.In the “SpiDriver_initial_version.cpp”;
a.can you see any showstopper, given that this version does not stick with your recommendations in §7.1 of SPRU580.
b.In particular, we have noticed that in some code example from Texas Instrument – i.e. SPRA633C - the initialization begins with a reset to zero – i.e. write only – absolute writing into SPCR. Should we do the same ? We assume that the RESETN pin of the CPU was de-asserted just before the SPI drivers begins; which does the same – we hope.
c.In particular, we perform successive read/write operations into the SPCR configuration register of the McBSP – to set or clear some bits inside - at CPU clock rate without any special wait cycles. Is it a problem ?
d.Should we add some instructions to specifically disable any interaction with the DMA/EDMA controller ?
3.Our “Best Try” still hangs even if we add the Masking of Global Interrupt Enable – GIE = 0. Should we mandatorily add GIE = 0 during the inits ?
