- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
I am using UART for sending at commands.
example as below:-
UART_DEB_UartPutString("AT+UHTTP=0\r\n");
sometimes its working but sometimes its getting stuck in a function UART_DEB_SpiUartWriteTxData and never comes out of it
stuck in below while loop:-
{
/* Wait until TX FIFO has space to put data element */
while (UART_DEB_SPI_UART_FIFO_SIZE == UART_DEB_GET_TX_FIFO_ENTRIES)
{
}
UART_DEB_TX_FIFO_WR_REG = txData;
}
Did anyone faced similar issue?please suggest.
Thanks.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This happens when the TX FIFO buffer is FULL and the TX cannot send any character. I assumes three possible reasons.
1) CTS input is negated.
If you uses the CTS input and the input is negated, the TX cannot send any character.
2) UART is disabled.
If UART is accidentally disabled, SpiUartWriteTxData() can accept characters but no characters are sent.
3) UART clock is disabled.
If the UART clock internal or external is disabled, no characters are sent.
If possible, please attach a snapshot of the UART's configuration dialogue.
Regards,
Noriaki
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you attach your project?
Thanks,
Hima
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm having the same problem in my project. Actually talking to a spi device with an SCB peripheral in "spi mode". Attached are my configurations. Exact same functionality: it almost always works, seems to have a problem when I increase the amount of data on the bus/interact with the SPI input device. Locks up at the same line as sagard waiting for an opening in the tx fifo.
Thanks,
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have confirmed the issue with following source code.
#include "project.h"
uint8 txData[16] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
int main(void)
{
CyGlobalIntEnable; /* Enable global interrupts. */
/* Place your initialization/startup code here (e.g. MyInst_Start()) */
SPIM_Start();
SPIM_SpiUartPutArray(txData, sizeof txData);
for(;;)
{
/* Place your application code here. */
CyDelay(1000);
}
}
In this program, 16 bytes of data is going to be sent via SPI master. The data is written by the method _SpiUartPutArray() at once.
The execution is stuck at following line.
It was found that the program stops when the 10th byte "10" is to be sent. The 1st byte is already sent to the slave. The 2nd to 9th bytes (total eight bytes) are stored in the TX FIFO. But these bytes in the FIFO are not sent to SPI. I don't know the reason why FIFO does not consumed.
When the TX buffer size is larger than 8 to use the software FIFO driven by the interrupt requests, all data is accepted by the SPI.
Could this be a workaround?
Regards,
Noriaki
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you don't have interrupts enabled to transmit the bytes from FIFO, then it will not be consuming the bytes.
If you don't have the clock for the SPIM ticking, then it also won't be clocking the TX bytes out of the FIFO.
If you are current IN an interrupt while waiting for the TX bytes to send out, that could be the cause of the issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That code on line 309 is only built if you do not have a software TX buffer enabled:
SPIM_CHECK_TX_SW_BUFFER
But I'm seeing something else. This macro uses a mask:
#define SPIM_GET_TX_FIFO_ENTRIES (SPIM_TX_FIFO_STATUS_REG & \
SPIM_TX_FIFO_STATUS_USED_MASK)
Here's the definition of the mask.
#define SPIM_RX_FIFO_STATUS_USED_MASK ((uint32) SPIM_FF_DATA_NR_LOG2_PLUS1_MASK)
Here's a description of the bits used by the status reg:
/* SPIM_TX_FIFO_STATUS_REG */
#define SPIM_TX_FIFO_STATUS_USED_POS (0u) /* [3:0] Amount of entries in TX FIFO */
So you might think the mask is going to be 0x0F.
It isnt:
#define SPIM_FF_DATA_NR_LOG2_PLUS1_MASK (0x1Fu) /* Number of bits to represent #bytes in FIFO. */
Possibly we have another problem here with bit 4 generating a bad result?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That macro sounds like it is a binary count of the FIFO buffer byte size. Having a large available "count" shouldn't be the cause of the issue imo.
Nice work digging into the discrepancy though.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Nick,
I think that not having interrupts enabled is the source of your problem. You are also writing directly to the transmit hardware register like so:
So the first byte written (0x01) starts shifting out of the pin and subsequent writes of the other values to txData are just lost. They aren't getting buffered. You need to enable an internal interrupt and that has a service routine that gathers bytes from a buffer and writes them into the write register after each one is done transmitting.
See subsequent answers (on following questions) to make this more clear.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SPI write function I use is this:
uint8 empty[] = {0,0,0};
SPI_SpiUartPutArray(empty,3);
However, I have the buffer sizes set to 80 using a software buffer. I am also polling the FIFO buffer instead of using the interrupt, but I don't remember if it was due to the interrupts not working for me, if I had no ability to use the interrupts with my setup, or if I was just lazy