10 Replies Latest reply on Nov 3, 2017 8:11 AM by e.pratt_1639216

    uart stuck in while

    sagard_1819731

      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.

        • 1. Re: uart stuck in while
          ntan

          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

          • 2. Re: uart stuck in while
            sagard_1819731

            Hi Noriaki,

             

            Thanks for the reply.

             

            PFA the PSOC Creator Configuration for UART.

             

            Regards,

            sagar

            • 3. Re: uart stuck in while
              hima

              Can you attach your project?

               

              Thanks,

              Hima

              • 4. Re: uart stuck in while
                nick.handran_1513271

                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

                 

                psoc_1.PNGpsoc_2.PNG

                • 5. Re: uart stuck in while
                  ntan

                  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.

                  GS003340.png

                  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.

                  GS003341.png

                  Could this be a workaround?

                   

                  Regards,

                  Noriaki

                  1 of 1 people found this helpful
                  • 6. Re: uart stuck in while
                    e.pratt_1639216

                    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.

                    1 of 1 people found this helpful
                    • 7. Re: uart stuck in while
                      user_16306146

                      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.

                      • 8. Re: uart stuck in while
                        user_16306146

                        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?

                        • 9. Re: uart stuck in while
                          e.pratt_1639216

                          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.

                          • 10. Re: uart stuck in while
                            e.pratt_1639216

                            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