Slowly pulling out my hair here... in general programming because the processor is an ARM STM32L073.
I have a widget which talks on two serial ports; on one to a PC via a built in ACM serial USB line; on the other to a mobile phone via a bluetooth link. Neither has any flow control, but the link to the PC has a fairly horrible protocol: it's emulating a single bidirectional line.
- every outgoing character from the widget is immediately reflected by the PC and discarded by the widget
- ignoring that echo, a byte actually sent from one end to the other is reflected with its inverse
- data is sent a packet at a time, with a packet length, packet type, packet count, packet payload (max twelve bytes) and an 0x03 EOTX to finish
- after initial setup, widget sends a request, computer responds. One packet to computer, one packet from computer.
I have debug printfs to the bluetooth terminal at various handy places which can be turned on and off at build time; I have permanent packet display and decoding on the PC
tick 37542 rx ram request: 06 23 01 07 20 10 03 tx ram reply: 0a 24 fe c9 c8 00 00 00 00 80 03 rx ram request: 06 24 01 0a 20 00 03 tx ram reply: 0d 25 fe 5f ec b9 62 80 64 00 00 19 af 03 tick 37544 rx ram request: 06 25 01 07 20 10 03 tx ram reply: 0a 26 fe c9 c8 00 00 00 00 80 03 tick 37545 rx error request: 03 26 07 03 tx error reply: 0d 27 fc 01 00 00 00 09 1c 00 00 00 09 03 rx error request: 03 27 07 03 tx error reply: 0d 28 fc 00 00 00 00 00 00 00 00 00 00 03 rx error request: 03 28 07 03 tx error reply: 08 29 fc 00 00 00 00 00 03 tick 37546 rx error request: 03 29 07 03 tx ack: 03 2a 09 03 rx ram request: 06 2a 01 0a 20 00 03 tx ram reply: 0d 2b fe 97 ec bc 62 80 64 00 00 1c b8 03
Serial data from either of the ports triggers an interrupt which buffers the data; that buffer is polled to check for/receive any data.
The tick count on the list above is a seconds (ish) count from the laptop. As you can see, it's run over ten hours... that's because the widget end is displaying every character received or sent (including the discarded echoes). If I stop displaying every character it will run for some indeterminate time - minutes to a couple of hours and then lock up. The fail condition looks as if the PC has sent a reply packet - either ram or error - but the widget doesn't see it.
I'm obviously suspicious of the interrupts on the serial port - one thought in particular was that perhaps the USB packeting was sending exactly the same size data squirt as the buffer, but increasing the buffer size and making it not be a power of two had no apparent change in behaviour. One curious thing is that timeouts in the receive character routine don't timeout - almost as if that routine simply isn't running.
Meh, it's doing my head in. I'm not really expecting a solution - apart from anything else, the code is way too big to post - but it'd be nice to hear if I've missed something obvious :)