Documentation for Syslink and CRTP packets between the STM32 and the NRF51

[florianvavelin]

Hi, I am currently trying to develop my own firmware for the STM32 on the Crazyflie 2.1.

I'm having some trouble understanding what the packets look like between the main CPU STM32 and the NRF51 chip:

1. The Syslink protocol page indicates that Syslink packets are flowing between both STM32 and NFR51, however in the RADIO_RAW section it is said "The NRF51 is regularly sending CRTP NULL packet or empty packets to the STM32".
   Which one is it? Syslink or CRTP?
   As I understand it, CRTP is a packet with port, channel and a payload (here it would be the Syslink packet). Am I wrong?
2. The LENGTH of the Syslink message is 8 bits, which gives hypothetically a 255-byte long payload data, The syslink.h file provides an MTU of 64 bytes. Why is that?
3. I also don't understand what this CRTP packet looks like bit by bit, even by looking at the documentation.
   The port is 4 bits, channel is 2 bits and payload is 31 bits.
   However, these bits can be ordered in many different ways in a buffer:
   37 bits: [P3, P2, P1, P0, C1, C0, D30, D29, ..., D1, D0] with P0 to P3 are the bits for the port, C0 and C1 the channel bits, and D the payload.
   39 bits: [0, 0, P3, P2, P1, P0, C1, C0, D30, D29, ..., D1, D0] is the same as above but padding 0 to the left so that the port and channel are 8-bit
   Padding can also be applied to the payload so that it fits 32 bits
   In any case, padding is necessary to send information over UART which sends/receives 8 bits.
4. The syslink.h file indicates a start byte of 0xAA for the CRTP packet, which is not documented anywhere in my knowledge.
5. I also noticed that this syslink.h file also gives Syslink packet types that are not documented (e.g. SYSLINK_RADIO_RAW_BROADCAST or SYSLINK_PM_BATTERY_STATE)
6. The "One Wire packets" section is empty

There are probably many more points that I missed, as I did not dive deeper in understanding each message.

It would be great if you can provide answers to the above points (and more I hope) in this thread or by updating the documentation.
Regards

[ataffanel]

Hi, I can answer in order and then discuss a bit more:

1. You seem to be understanding thinks backwards: in the CRTP documentation the CRTP layer is above the LINK layer. In case of syslink, the link layer is syslink. So a RADIO_RAW syslink packet contains a CRTP packet. This CRTP packet may itself be a NULL packet (port F, channel 3).
2. We avoid using dynamic memory or memory pools so we allocate statically full packets for all our queues and everywhere we use them. So it is important to keep the packet as small as possible and 64 bytes is currently the max MTU of the radio (when used in P2P mode), so this is the biggest useful size for a syslink packet at the moment.
3. Bit representation of a CRTP packet is handled by the link. You can find the exact representation in the code and it is true that it could be documented. So far is all our links we encode CRTP port:channel in a header byte with port on bit 7:4 and channel on bit 1:0. Bit 3:2 are reserved to be used by the link. For example it is used by radio link to implement a flow control mechanism. I am not following you on padding though, we do not have any as far as as know. But if we had some, it would be on the syslink layer: the CRTP packet shall be transmitted unchanged from one side to another, if there is needs of padding syslink would handle it.
4. This is most likely a remain from a very old experiment, it should be removed as it is not used anywhere
5. This should indeed be documented, until it is done the code is the documentation
6. Same

So basically, syslink is a communication protocol that is under CRTP, it is not dealing with the content of the CRTP packets in any way and just carries the packets back and forth from the radio to the stm32. It also implement a brunch of other packets that are useful for the communication of both CPU.

We see it as a "private" part of the Crazyflie, in the sense that its API does not leak outside the scope of the the direct communication between nrf51 and stm32, so this explain why the documentation is unfortunately lacking. If you are interested in doing pull requests on the documentation I will very gladly merge it!

[florianvavelin]

Thanks for your quick reply. As I thought, I was indeed wrong on the understanding.
I will continue digging into it and will surely be updating the documentation for that!