OSTC over BLE experiences and questions

[Jan Mulder]

On 04-07-17 20:30, Linus Torvalds wrote:
> On Tue, Jul 4, 2017 at 10:04 AM, Jan Mulder <jlmulder at xs4all.nl> wrote:
>>
>> :-) What I can add to my use case ... even the communication stops, the
>> "download mode enabled" stays on on the OSTC3.
> 
> Looking at the dump, I think this is a flow control issue with that
> "rx/tx credit" thing.
> 
> In particular, I think - if I read that dump correctly - that in
> packet 90 you set that receive credit to the max by writing one byte
> of 255 to handle 18.
> 
> And I didn't count the exact number of Handle Value Notification
> packets you get on the handle 0x0f, but it's definitely in the ~250
> packet range (starts at packet 131, ends at packet 395, with roughly a
> dozen packets that we send in between.
> 
> If it's not exactly 255 packets, it's something very close.
> 
> So I think you may need to write that credit thing every once in a while..
> 
>                        Linus
> 

Indeed, that was something I was thinking of myself. And to check this 
idea I already did write the 255 value to that same descriptor I write 
it to in the initialization on every call of the write() function. They 
showed up correctly in the logging, including write confirmation. But 
all this, the stopping behavior was identical. That made me think it was 
not related to the initial credit setting.

This all said. I just counted the received packets ... and it is spot on 
255 packets. So I'm now sure that it is related to that credit thing, 
but still very unsure how to fix that, given my earlier attempt. I just 
further tested setting the initial credits to 200, and, yes, I receive 
exactly 200 packets from the OSTC.

A relevant fragment of that TIO doc: "It is the Terminal I/O client's 
responsibility to track the number of UART credits granted by the server 
(peripheral) by adding the number of received credits to a
credit counter and decrementing the credit counter for each UART data 
packet written to the server. Once the credit counter reaches 0, the 
Terminal I/O client shall not send any UART data until having received 
additional UART credits from the server." (in this text, the Terminal 
I/O client is Subsurface, and the "server" is the TIO implementation on 
the Telit/Stollmann chip).

Ok, the current Subsurface code does not track "the credit counter", but 
the quoted section is highly unclear (to me). Only tracking the counter 
on Subsurface side will not help the OSTC to decide to stop sending. It 
needs to be communicated too, and the only way seems the already tried 
resetting it back to 255. What I'm going to try is, indeed tracking the 
counter, and send the newly wanted packets, but taking care not to ask 
more than the 1 byte can handle (that might explain why just asking for 
255 when there al still 50 left does not work) ... what a pain ...

--jan