Under-reported no. of bytes in circular buffer

[Brendan]

Hi Guys.

I presently have six active hardware UARTS on an STM32F407 micro.

Each UART is served by an Rx-Int, each calling a separate dedicated interrupt service macro for each port, and the data is captured to separate circular buffers for each UART.

In the main thread, it was my intention to branch if any particular circular buffer contained more than zero bytes, then simply wait a period of time for possibly remaining data to arrive, then extract the data from the circular buffer for processing. However, regardless of data in the buffers, the main flow would never branch in response to data.

So I added a simple debug test to the end of the main program loop (shown) and ran a few tests. Basically, a 3s delay applied to each main loop permits me to right-click (send) a sequence of 20 chars via PuTTY terminal (20 chars per click x 1/2/3/4/5/6/7 during the interval for each successive test), and the pictorials reveal the number of bytes under-reported by the circular buffer in each case.

Please don't be confused by the printed strings - limited/maxed to 64 bytes, including the nul of-course (with the circular buffer set at 128 bytes). Each successive test increases the number of bytes in the circular buffer by +20 in each case.

Many thanks,
Brendan

Circ_Buffer_StrLen.png (248.17 KiB) Viewed 190 times

[chipfryer27]

Hi

Can you post your chart so we can have an in depth look? Screenshots don't tend to give all the information.

Regards

[Brendan]

Hi ChipFryer,

Unfortunately, this is for a professional project and I'm prohibited from publicly sharing project details, so I've just shared the debug code added to the end of the main loop to exemplify the issue and test results. The main program loop was simply jumpered with a go-to from start of the main loop to the beginning of the debug sequence shown.

Understanding the difficulties to analyse this further without further access to project source/details, I should be able to implement a workaround for the present - e.g. indexed chars to strings instead of circular buffers as I'm running the core a little over 160MHz for bandwidth, though wanted to capture my findings for the report.

If I can characterise this further, I'll add to the report here.

Thank you again,
Brendan

[chipfryer27]

Hi

"I'm prohibited from publicly sharing project details" - Understood, but does limit any help.

In your "debug" you

1) Obtain number of bytes in buffer - content unknown. Was button to add pressed?
2) Get String(64) - This will remove up to 64 characters from buffer including null
3) Send string out on UART
4) Send \r\n out on UART
5) Obtain number of bytes in buffer - This will be zero if step 1) was 64 or less. If content isn't / wasn't character then a value may be returned.
6) Send number of bytes out on UART as number
7) Send \r\n out on UART
8) Receive string = ""
9) Flush buffer

Without knowing when/where the button was pressed and what went on before it is difficult to guess what should be in the buffer.

I recently did something similar but not with multiple UARTs

RxINT called an ISR and in there I simply grabbed the incoming value and put in buffer. This may possibly be where your issue lies. What are you expecting to receive and how are you receiving and storing e.g. UART1:ReceiveChar etc?

Of course this is just a guess but it may help you narrow down.
Regards

[Brendan]

Thank you Chipfryer - very much appreciated.

Further investigations suggest something could be going on with the stack/heap however, particularly as the main branch forcibly clears the circular buffer and associated variables at the end - well after possible reception of further data, yet loops and branches just once more (as though the circular buffer still contained data) before returning to standby.

Hmm... Too much working the small hours. Time to simplify, I think

Thank you again,
Brendan