ccspi TX does not write the last byte to TX_FIFO
yannayl opened this issue · comments
The ccspi application implements CCSPI_TX incorrectly. It uses the first byte of the data to send as length of the message including that byte itself, however according to the documentation, the first byte of the packet (PHR) denotes the length of the rest of the packet (PSDU) (see http://www.ti.com/lit/ds/symlink/cc2420.pdf 16.2 - Length Field "Note that the length field does not include
the length field itself").
Therefore the last byte of the packet is not written to the TX_FIFO.
This is the buggy code:
ccspitrans8(CCSPI_TXFIFO);
for(i=0;i<cmddata[0];i++)
ccspitrans8(cmddata[i]);There are two ways to overcome this problem:
- Use autocrc mode, which mean the last two bytes are the CRC and the transceiver will generate them automatically and ignore the last bytes in the TX_FIFO.
- Manually put the packet in the TX_FIFO:
goodfet.writecmd(goodfet.CCSPIAPP,0x03,1,[0x9]) # flush
goodfet.writecmd(goodfet.CCSPIAPP,0x03,len(pkt)+1,[0x3e] + map(ord, pkt)) # write TX fifo
goodfet.writecmd(goodfet.CCSPIAPP,0x03,1,[0x4]) # tx on
time.sleep(0.3) # wait SFD?I haven't tested the workarounds because something is wrong with my setup.
However, I did tried to transmit messages and then peeked the TX_FIFO RAM and found out the last byte is not there.
As this project is not under active development, I don't know if I should also submit a pull request and try to fix it.
@travisgoodspeed is accepting PRs/fixes to this, so any fix would be very welcomed -- ideally with a way to reproduce the original bug and then verify it now works.
@rmspeers @travisgoodspeed
I haven't dig deep enough in the GoodFET protocol, so I will put here my idea for a fix and tell me if it sounds right.
I think the best fix for this bug would be not to mix both lengths.
The firmware should use the length provided to the ccspi_handle_fn and not the first byte of the payload (cmddata).
So the code in ./firmware/apps/radios/ccspi.c line 555 should be:
for(i=0;i+1<len;i++)
ccspitrans8(cmddata[i]);As said, unfortunately I can't build the firmware for my HW, I opened an issue in the Killerbee project and also emailed the vendor asking for the build configuration. Hopefully I will have the required resources soon.
P.S. I think this bug exist in other places in the ccspi.c, grepping for cmddata[0] has a few more instances. I will try to fix all of them once I can build the firmware for my board.
The build configuration is shown in this GoodFET project's firmware/config.mk file, along with all the other boards.
