6 Replies Latest reply on Nov 26, 2014 7:29 AM by MichaelF_56

    Odd Puart behaviour?

      So I'm using the TAG board with the 737 on it, plugged into my pc & sending bytes to the board using RealTerm.


      Here's my simple (flash the gpio led whenever the callback is called.) puart code:


      void my_puart_interrupt_callback(void* unused)


          // There can be at most 16 bytes in the HW FIFO.

          char  readbyte;

          // empty the FIFO

          while(puart_rxFifoNotEmpty() && puart_read(&readbyte))


          if(gpio_getPinOutput(14/16, 14%16))

                  gpio_setPinOutput(14/16, 14%16, 0);


                  gpio_setPinOutput(14/16, 14%16, 1);


          // clear the interrupt




          // enable UART interrupt in the Main Interrupt Controller and RX Almost Full in the UART Interrupt Controller



      Weird thing is, as I'm slowly typing characters into the terminal & can see the led flash on the FTDI driver chip, the LED from the 737 only toggles every other or every few bytes. Why isn't it toggling with every byte received?

        • 1. Re: Odd Puart behaviour?

          UPDATE: I improved the performance of the PUART by including the callback that disables the sleep mode but this hasn't solved the issue completely.


          I've implemented a simple packet protocol for synchronising the 737 with another micro. However I routinely seem to miss one byte from the transfer when packets are sent aperiodically.


          If I send the packets based off a timer then every seems to work. The data I'm trying to send isn't periodic though


          So far it works if I duplicate the packets i.e. when data occurs two packets are sent (copies of each other) rather than just one packet being sent.


          Is the broadcom PUART going into another standy state or something? Something that would mean it'd need the first byte to wake up or something?

          • 2. Re: Odd Puart behaviour?

            The IO pin might not be in the state you expect it to be by the time the callback is entered.  I ran into this with the SPI CS interrupt.  Have you scoped it? 


            Instead of looking at the state of the pin, try toggling your LED if there is something in the FIFO (while you read it out):


            if (true == data_in_fifo)





            1 of 1 people found this helpful
            • 3. Re: Odd Puart behaviour?

              Do you mean you missed one byte from receiving by 20737?

              If this is the case, did you run fifo into overflow state? (rx fifo is 16 bytes maximum)

              As I know the silicon does not need an extra byte to wake up it if you correctly disabled sleep mode.

              1 of 1 people found this helpful
              • 4. Re: Odd Puart behaviour?

                I have not used such a callback, just the simple puart_print() function there.

                It needs to put "\r"\n" into string.
                But I saw as well that for instance "\r" was missing and not received on TeraTerm.

                (no time to debug and think about, just assuming a WFI and power down cycle from RTOS might kick in and affect UART - not sure)

                • 5. Re: Odd Puart behaviour?

                  Thanks for the input!


                  One clarification:

                  JaWa_2142591 asked about the missing byte. All the bytes were sent successfully from the other µC. Not all of those bytes were caught by the 20737.


                  Couple Updates:

                  Re the GPIO, I actually stripped that out of the code for testing & implemented a simple echo: the 20737 would write whatever bytes it received. This further showed that bytes were missing from the transfer. (when jora_1327726 mentioned IO, it was the led GPIO right?)


                  Now I've adapted my packet protocol to include two bytes of preamble "just to get things going". It seems to work in that I'm not seeing packet loss anymore but it's not ideal.


                  Re the FIFO being full; So far my packet size is about 8 bytes. The rate of packets is fairly slow - between 2 packets per second to 1 pckts/s. I'd have expected that that sort of throughput was well within the 20737s ability to read that data.


                  However, I do in the future expect to increase the number of packets I'm sending, is there a way for me to tell if the FIFO has filled? I saw the watermark level macros but I thought that they were used to set how many bytes are received before the interrupt callback is called?

                  • 6. Re: Odd Puart behaviour?

                    If I recall, there is a thread on the site where userc_6531 and ArvindS_76 go into some very low level details related to buffering architecture of the PUART, along with how to manage it within your application.  Code examples are included as well.


                    Take a look: UART Routines