7 Replies Latest reply on Mar 12, 2015 4:09 PM by user_78878863

    Bug in generated UART code

    peter.gray

      I've spent some time today tracking down a bug in the provided UART code.

         

      I have a large (4k) software RX fifo configured in PSoC BLE UART (for RS-232 data).

         

      When that RX buffer gets overfull, the ISR code generated by the PSoC Creator gets stuck: It has set the related irq mask to 0x5 (NOT_EMPTY and TRIGGER), but the ISR code, at least when the fifo is full, does not have an action to clear TRIGGER as a source and only explicitly clears NOT_EMPTY. As a result it gets stuck in the ISR, with irq source of 0x01 (TRIGGER, but not NOT_EMPTY).

         

      My quick solution is to clear TRIGGER as a irq source. Better would be clear TRIGGER in the ISR, but I'm not sure of the implications of that.

         

      On a related note, I find the API for UART to be weird. I need to send blocks of data, but only the most basic "put string" functions are provided for UART. I've been using the SPI functions (PutArray, UART_SpiUartGetRxBufferSize) functions to acheive the same results. I can't find any "block read" function, and UART_UartGetByte() doesn't return a byte, etc...

         

      Best regards.

        • 1. Re: Bug in generated UART code
          user_1377889

          Welcome in the forum!

             

          I would suggest you to create a "MyCase" to have Cypressed informed. At top of this page Support & Community -> Technical Support -> Create a MyCase

             

          Best is to attach a project that reproduces the error.

             

           

             

          Bob

          • 2. Re: Bug in generated UART code
            user_78878863

            I cannot find an interrupt source called 'TRIGGER'. Do you maybe mean 'RX FIFO Level'? That one should not be enabled by default, so it should never trigger an interrupt - did you maybe enable it manually?

               

            What you can do: register a custom interrupt handler, and clear the interrupt source there. It gets called from the internal ISR.

            • 3. Re: Bug in generated UART code
              user_78878863

              Maybe I should have asked: are you using the SCB-based UART opr the UDB-based one?

                 

              For the SCB-based, there is UART_PutString that takes an uint8 array, and SpiUartPutArray that can take either uint8 or uint16, depending on the UART configuration. Yes, the naming is weird since this is a multi-functional component.

              • 4. Re: Bug in generated UART code
                peter.gray

                 This is a UDB UART.

                   

                 

                   

                Page 1790 of the TRM for PSoC4 BLE, in section 25.1.78 SCB0_INTR_RX_MASK ... describes TRIGGER.

                • 5. Re: Bug in generated UART code
                  user_78878863

                  The register you are looking at is only for SCB_based UARTs, which you don't use.  How do you determine which interrupts are currently requested for that particular ISR?

                     

                  (Btw: from the description of TRIGGER in the SCB0_INTR_RX register it the RX_level interrupt)

                     

                  The UDB-based UARTs don't use any of the standard registers. Their component implementation uses an internal interrupt component (at least I think so), which gets triggered by an UDB output.

                     

                  Are you using another SCB-Based component that might request an interrupt you are looking at?

                  • 6. Re: Bug in generated UART code
                    peter.gray

                    Sorry, no, this is an SCB Uart. Not UDB.

                       

                     

                       

                    I arrived at that register name by drilling into the generated code.

                    • 7. Re: Bug in generated UART code
                      user_78878863

                      If its a SCB UART - check whether the "RX level" interrupt is enabled in the UART config. When testing, I see that setting this flag changes the UART_DEB_UART_INTR_RX_MASK values from 0x04 to 0x05 - so maybe thats your problem?

                         

                      (I cannot see any other place where this interrupt source is enabled)