That’s great! Thanks for taking the time to do this and Happy New Year!
I’m sorry for the trouble. I neglected to put the information about the replies and I missed param 10 and tail. I’ve fixed the IMU-f documentation. Please let me know if there’s anything else I can help you with.
Adding in the 10th’s param and tail will probably fix it. The IMU-f won’t communicate correctly if the CRC is wrong, and the CRC will most definitely be wrong if only 9 params are being sent.
There are two replies for every command sent to the IMU-f in setup mode. The first reply is included in the data received from the IMU-f when the IMU-f is first sent a command during a full duplex SPI read/write. It will either read 108 “IMUF_COMMAND_LISTENING”, or 32 “BL_LISTENING” and is there to tell you the IMU-f was listening for a command when the command was sent.
When the SPI read/write completes and you received either 108 or 32 then set the command word to 0 “IMUF_COMMAND_NONE”, recalculate the CRC, and do another SPI read/write to verify the IMU-f got the command successfully. The IMU-f will set the command word in that reply to the command you originally sent.
I send IMUF_COMMAND_SETUP along with a setup packet and a CRC and during the SPI transaction the IMU-f sends IMUF_COMMAND_LISTENING.
I then send IMUF_COMMAND_NONE with a CRC and during the SPI transaction the IMU-f sends IMUF_COMMAND_SETUP to verify it received and was able to work with the command you sent it.
When you send the second SPI transaction you can just set the command word and calculate the CRC. What’s in the packet and tail doesn’t matter but the CRC should still be calculated based on what’s in the entire packet.
While SPI is full duplex due to the speed of the STM32F3 and the rate the SPI can run at it was important to break up commands into two SPI transactions since trying to handle the setup data during an SPI transaction running at 24 MHz was pretty much impossible on an F3.