Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

XMC™ Forum Discussions

User12223
Level 2
Level 2
First solution authored
Hi,

I am seeing a real strange issue with my SPI tx data transfer. When calling the following function in main.c and observing the results on an oscilloscope, the function successfully executes and the data can be seen on the MISO line of the XMC4500.
The issue comes when I call the same function in a different source file. The status of the transmit is Success however, the code will then get stuck in the while loop.

void SPI_Write_Data (void)
{
uint16_t WriteData = 123;
if(SPI_MASTER_Transmit(&SPI_MASTER_0, &WriteData, sizeof(WriteData )) == SPI_MASTER_STATUS_SUCCESS)
{
while(SPI_MASTER_0.runtime->tx_busy)
{
}
}
}


I am using a XMC4500 with DAVE 4. I am using the SPI_Master app in full duplex mode with a desired baud rate of 1M.
The app is configured to interrupt mode, however no end of tx/rx callbacks. FIFO is enabled, with a size of 2 for both Rx and Tx.

I dug down further into the cause, to make sure the data is not still being transferred and the CS has returned to a high state, only to find that no data is even transferred.
The tx_busy flag is set to true, as part of the ‘SPI_MASTER_Transmit’ API, though it is never set back to false.

When in the working instance, the tx_busy flag set to false and the data transferred in the XMC_USIC_CH_TriggerServiceRequest(handle->channel, (uint32_t)handle->config->tx_sr) function, with in the ‘SPI_MASTER_Transmit’ API.
In the non-working instance, nothing appears to happen during the XMC_USIC_CH_TriggerServiceRequest(handle->channel, (uint32_t)handle->config->tx_sr) function call. The tx_busy flag remains set to true and no data transferred.

Does this mean some other interrupt is generated to set the flag back to false?

I have read about others having issues with SPI in passed posts and used many examples but nothing has yet to help me out.
I was hoping I could use some help from you guys with why/how the origin of a function call can change the way the function works, without anything being passed in!

Any ideas?

Thanks in advanced,
Steven
0 Likes
2 Replies
jferreira
Employee
Employee
First like received 750 replies posted 500 replies posted
Hi,

In the non working situation, which other interrupts do you have in your system? which priorities? I guess the SPI TX interrupt is not being executed because of other interrupts in your system…

Regards,
Jesus
0 Likes
User12223
Level 2
Level 2
First solution authored
Hi Jesus,

Thanks for getting back so quickly.

You are right as always! Tx is not being executed as the SPI tx has the same priority as the task scheduler.
This explains the strange behavior I have been seeing.

The code is very interrupt heavy. I wasnt aware the priorities mattered for the SPI as the callbacks where not being used, so I left them at the lowest priority (same as the task scheduler).

The code was recently migrated from Dave3 to Dave4, in Dave4 we make use of the SPI_Master APP in interrupt mode, in Dave3 we use the APP SPI001.
I could not find any documentation to suggest which mode SPI001 is using, the priorities were not an issue before so is it a fair assumption this is in direct mode?
Could you let me know of the main differences between the two? I am struggling to find any helpful documentation on the matter.

Thanks for the help
0 Likes