BC127 Drops bytes after wake from sleep


#1

I am using the BC127 with rev 6.1.3 firmware. I have enabled deep_sleep and am using the GPIO to toggle between data and command modes.
Once a minute, the software wakes the radio to transmit 120 messages of 1030 bytes in each “packet”. I use a serial encapsulation technique with SOF/EOF with a binary stream. Processing time is allowed between each packet.

My test bench runs for hours, even days, so the firmware seems fairly reliable now (compared to the older 6.0.X series).

The issue I have is that the first, sometimes first 2, bursts of traffic over the SPP are short 56 bytes (at the end of the sequence).
After sleeping for a minute, the radio is awoken with a on the data lines per spec. We wait the appropriate 5 mSec, enter DATA MADE (GIO_5 transitions high), we wait 500 uSec, then start pushing bytes out (honoring RTS/CTS). The first message of 1030 bytes arrives at the receiver but only has 974 bytes, the tail 56 bytes don’t seem to arrive. The code proceeds to send 119 more packets of 1030 bytes and they all arrive in tact, of the correct length.

I’ve tried tinkering with longer delays and delays between packet bursts, but that seems to have no effect.

Any ideas as to what could cause this? (I am assuming back-pressure OTA would results in loss of CTS which would hold me off). Not sure what to do next?
Why only the first message and why only the ending bytes? (It might make sense if the start got cut-off, but it’s the end of the message).


#2

Okay, so I know this is coming… try version 6.1.5
So, I loaded 6.1.5 and the problem is noticeably worse.
I now get those short packets for the first 3 or the 120 packets sequence.
Again, as before, it’s always bytes being cut-off at the end of the packet.

Seems like a buffer overrun between the host micro-controller and the radio. My guess is that maybe the radio buffer is being overrun?
Why wouldn’t the radio withdraw CTS to hold off the processor? The link is running at 115,200 so I believe that’s as fast as the spec allows me to go.

Anyone else having overrun issues? (Or at least it now seems like overrun).

I didn’t see anything in the release notes that even hinted this would get worse between 6.1.3 and 6.1.5

Thanks


#3

I’ve taken the experiments a bit further, and it is looking like I don’t get RTS/CTS handshaking between the microcontroller and the radio.

I added a 350 mSec delay after waking the radio to allow time for the SPP connection to be re-established and that fixed (worked around) losing data on the first packet. I added a flexible delay between the frames and found that 15 to 25 mSec was a sweet spot to allow the buffer to drain before sending the next frame. This works a good 99% of the time. The remaining issue I see is that between the first and second packet, the link is still negotiating bandwidth (I presume) and things are just getting going. I frequently drop several bytes in that second packet when there is wireless traffic of any significance.

So, this is all pointing me back to CTS~ not going high when I should be holding off.

I have enabled flow control on the UART and SPP as so:
“SET UART_CONFIG=115200 ON 0\r”
"SET HIGH_SPEED=ON OFF\r
“SET ENABLE_SPP_SNIFF=ON 0 0 0 0 0\r”

Have I misconfigured something? What do I not see CTS~ go high when the back-pressure has built up in the radio?
I’ve set a breakpoint in my code and never see CTS~ go false… kind of odd it seems.

What have I done wrong? Is there more to getting the radio to drive its’ UART CTS~ false when the buffers fill up?

Thanks


#4

Only using classic Bluetooth at the moment… here is the configuration loaded into the radio flash (note turned off DEEP SLEEP to enable interactive debug):
BlueCreation Copyright 2017
Melody Audio V6.1.3
Build: 1489773678
Ready
OK
NAME=M-020002
OK
AUDIO=0 0
AUDIO_ANALOG=15 15 1 OFF
AUDIO_DIGITAL=0 44100 64 100A00
AUTOCONN=1
AUTO_DATA=OFF OFF OFF
BALANCE=100 100
BATT_CONFIG=OFF 145 4250 1500 150
BC_SMART_CONFIG=68E3 28F0 89F7 D93C
BEACON_DATA=0 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF 04 D2 16 2E EE
BLE_CONFIG=0 OFF 40 ON
BLE_CONN_PARAMS=128 12 6 40 0 400 50 400 400 61 400 400
BT_VOL_CONFIG=A A 10 1
CLASS_1=OFF
CMD_TO=20
COD=80091C
CODEC=0 OFF
CONN_TO=0
DEEP_SLEEP=OFF
DEVICE_ID=0001 0002 0003 0004 0005 0006 0007 0008
DISCOVERABLE=1 0
ENABLE_BATT_IND=OFF
ENABLE_CAPSENSE=OFF
ENABLE_LED=OFF
ENABLE_SPP_SNIFF=ON 0 0 0 0 0
GPIO_CONFIG=OFF 0 254
HFP_CONFIG=OFF OFF OFF OFF OFF
HIGH_SPEED=ON OFF
LOCAL_ADDR=20FABB0207A0
MAX_REC=2
MM=OFF OFF 0 OFF OFF OFF OFF OFF
MUSIC_META_DATA=OFF
MUSIC_OLD_AVRCP=OFF
NAME=M-020002
NAME_SHORT=BC207A0
PIN=0000
PROFILES=0 0 0 0 0 0 1 0 0 0 0 0
REMOTE_ADDR=000000000000
SPP_UUID=00 00 11 01 00 00 10 00 80 00 00 80 5F 9B 34 FB
SSP_CAPS=3
TWS_CONFIG=OFF 1 2
UART_CONFIG=115200 ON 0
USB_HOST=OFF
VREG_ROLE=0
OK
STATE CONNECTED[0] CONNECTABLE[ON] DISCOVERABLE[ON] BLE[OFF]
OK