SLIP protocol in serial boot-loader

[Phil]

We are implementing a DFU controller in a microcontroller that communicates with the nRF boot-loader over serial.  The target device is nRF52832 using SDKv15.3.0. The boot-loader is from the example DFU secure serial boot-loader.

According to the Bluetooth Core Specification 4.0, Vol4 PartD CH3 Slip Layer, the SLIP protocol should have a start and end byte (0xC0) around each SLIP packet.  So between SLIP packets there are 2 consecutive 0xCO bytes.  This is shown in Fig 3.1 of the standard.

... C0 C0 [ slip packet 1 ] C0 C0 [ slip packet 2] C0 C0  [ slip packet 3] C0 C0 ...

When we send SLIP packets to the bootloader we get problems if there are start and end bytes as per the Bluetooth Standard

TX: C0 00 C0              Get Protocol Version

RX: 60 00 01 01 C0     Response Get Protocol Version

TX: C0 07 C0             Set MTU

RX: 60 00 01 01        Response Get Protocol Version (missing end C0)

TX C0 00 C0             Get Protocol Version

RX 60 07 01 83 C0 C0   Response Set MTU (with 2 end C0 bytes)

However if we send SLIP packets with only an end byte (C0), so there is only one C0 between SLIP packets, it works correctly in that we get the correct response for each request.

TX: 00 C0              Get Protocol Version

RX: 60 00 01 01 C0     Response Get Protocol Version

TX: 07 C0             Set MTU

RX 60 07 01 83 C0   Response Set MTU

TX: 00 C0              Get Protocol Version

RX: 60 00 01 01 C0     Response Get Protocol Version

What is going on here?  Does the Nordic SLIP library implement the Bluetooth Specification or not?

[Phil]

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.

[bjorn-spockeli]

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

[Phil]

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.

[bjorn-spockeli]

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

[Phil]

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.