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.
// empty the FIFO
while(puart_rxFifoNotEmpty() && puart_read(&readbyte))
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
P_UART_INT_ENABLE |= P_UART_ISR_RX_AFF_MASK;
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?
Solved! Go to Solution.
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?
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)
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.
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)
Thanks for the input!
janusw 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.
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 jose.raffucci 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?