SLIP protocol in serial boot-loader

RE: SLIP protocol in serial boot-loader

Phil — Mon, 18 Nov 2019 02:30:27 GMT

Thanks. That would be useful. If a 0xC0 is received immediately after a 0xC0 this can be treated as receiving a zero-length SLIP frame. The SLIP receiver should only indicate when it has received a non-zero length SLIP frame. It shouldn't be necessary to have any special handling for consecutive 0xC0 bytes.

RE: SLIP protocol in serial boot-loader

bjorn-spockeli — Fri, 15 Nov 2019 09:04:19 GMT

Will add the update to the SLIP library as a feature request in our internal issues database.

Thanks for pointing this out. We appreciate the feedback!

Best regards

Bjørn

RE: SLIP protocol in serial boot-loader

Phil — Tue, 12 Nov 2019 21:58:44 GMT

Thanks for your reply. Yes we found a solution. However, instead of updating the documentation, I recommend that Nordic update the SLIP library so that it can handle two or more consecutive END bytes between frames as per the Bluetooth Core Specification. It is a simple thing to do. Another reason for doing this is that the SLIP sending device can send a couple of 0xC0 bytes back-to-back to reset the SLIP receiver at the other end.

RE: SLIP protocol in serial boot-loader

bjorn-spockeli — Tue, 12 Nov 2019 15:21:45 GMT

Hi Phil,

Glad to hear you found a solution. No action needed from me I guess? Will provide this feedback to the developers so that the documentation can be updated to state this.

Best regards

Bjørn

RE: SLIP protocol in serial boot-loader

Phil — Tue, 12 Nov 2019 02:48:47 GMT

RFC1055 specifies an END byte (0xC0) is sent only at the end of a SLIP frame. Therefore there is only one END byte between SLIP frames.

It is optional to send an END byte before and after a SLIP frame, so there will be 2 END bytes between SLIP frames. This is mentioned in RFC1055, and the SLIP decoder should just ignore consecutive END bytes. The Bluetooth Core Specification describes SLIP frame encoding with END byte at the start and end of the frame.

A robust SLIP receiver should be capable of receiving any number of END bytes between SLIP frames. Apparently the SLIP receiver used in the bootloader requires exactly one END byte between SLIP frames.

We modified our SLIP encoder and decoder in the microcontroller to use only one END byte and it now communicates correctly with the boot-loader.