This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: TMS320C6678
We're having a problem with running Ethernet and SPI at the same time.
It appears that the Ethernet is interrupting/crashing the SPI_Transfer() function (MCSPI_INT_RX_FULL).
So I have some questions:
Initially we had a setup issue (HWI conflicts), but resolved it under https://e2e.ti.com/support/arm/sitara_arm/f/791/t/664242?tisearch=e2e-sitesearch&keymatch=nimu%20spi%20conflictHowever, I can't find the Ethernet IntNum in the ROV output, so can't confirm that the Ethernet is NOT a higher priority (lower IntNum value) than SPI.
Can anyone answer my questions above and possibly give me some insights into this problem?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Cvetolin Shulev-XID:
In reply to lding:
I forgot to give info on the libraries I'm using:
I had a look, and here is a list of my interrupts:
I've just seen that the Tasks also have priorities. Do these priorities interfere with the SPI interrupts?We've tried to set the StackStart Task_priority to 8 (higher number, but lower priority than SPI) and the Task that our SPI calls are being called from to 1.This has not solved the problem.
I'm attaching our ROV output (Hwi, Swi, Tasks).
Any thoughts/guidance on how to set the Hwi IntNum and Task IntNum so that the low-level SPI_Transfer is not interrupted?
6406.ROV screen shots.zip
In reply to Ruan de Hart:
I'm adding my main.cpp and app.cfg as well.Hope this gives a bit more clarity.
So I've done some more digging and I'm now stuck in the SPI driver.I've updated to PDK 2.0.9, since there seem to be some improvements.
When calling SPI_Transfer() the SPI driver seems to get stuck in the SPI_v0.c file, specifically in SPI_v0_hwiFxn():
When debugging (with the Blackhawk XDS560v2-USB) tt gets stuck in the WHILE loop that services all the SPI interrupts. This is defined as
while (((intCode & SPI_INT_MASK) != 0) && (loop == true))
intCode is refreshed at the end of the WHILE loop
intCode = SPIIntStatusGet(hwAttrs->baseAddr);
I set a breakpoint at the WHILE loop to check the intCode value. At this point none of the interrupt flags are set, but there is a bit set in the reserved section (sprugp2a, March 2012, section 3.5 SPI Flag register(SPIFLG) ) = 0b0010000000000000.So it is clear that the WHILE loop should exit....but it DOESN'T????
If I do a single step, the intCode value changes to have the TXINTFLG bit set...and the WHILE loop runs again.
It then appears that the SPI driver then remains in this loop.
Why is the TXINTFLG bit not correctly cleared????Why does the intCode variable magically change during 1 step?????
My SPI setup function looks as follows:
SPI_socGetInitCfg( 0, &spi_cfg );
spi_cfg.csNum = 1;
SPI_socSetInitCfg( 0, &spi_cfg );
Board_initCfg cfg = BOARD_INIT_ETH_PHY | BOARD_INIT_MODULE_CLOCK | BOARD_INIT_UART_STDIO;
SPI_Params_init( &spiParams );
spiParams.frameFormat = SPI_POL0_PHA1;
spiParams.bitRate = 1000000;
spiParams.dataSize = SPI_v0_8bit;
spiParams.transferMode = SPI_MODE_BLOCKING;
spiHandle_ = SPI_open( portNumber_, &spiParams );
// Enable the SPI port
uint32_t xferEnable = 1;
SPI_control( spiHandle_, SPI_V0_CMD_XFER_ACTIVATE, (void *)&xferEnable );
I'm posting this, so that others can hopefully have the benefit. WE HAVE FOUND A PROBLEM IN THE PDK V2.0.9, SPI_v0_hwiFxn
In our application the DSP seems to be processing the SPI so fast, that RX data is not ready directly after the TX data is sent.When TX data is completed, the SPI_INT_TX_EMPTY flag is set.Immediately after this, we are expecting the SPI_INT_RX_FULL to be set...BUT THIS ASSUMPTION ISN'T TRUE.We have found that the SPI_INT_RX_FULL flag isn't always already set, which causes the TX & RX buffer processing to get out of sync.This eventually hangs the SPI driver.
SOLUTION:(NOTE: Not pretty, but it works)We put a WHILE loop in after the SPI_INT_TX_EMPTY is processed, to wait for the SPI_INT_RX_FULL to be set. This ensure the TX & RX buffers stay in sync.
I'm attaching the SPI_v0.c file.You should be able to merge the SPI_v0_hwiFxn function into your PDK and rebuild your PDK. ()
NOTE: Not all DSPs use the SPI_v0 driver. If your DSP uses the SPI_v1, you will need to merge it in there.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.