Hi,
I'm trying to use the CRC DIN functionality of the device, that is, setting the MODE > RX_CRC_EN bit and checking the STATUS > CRC_ERR bit on each NULL command's response. I've been using a Saleae logic analyzer to double check all the data I'm sending, especially with the CRC stuff being in play. I currently also have the MODE > CRC_TYPE bit cleared, meaning I'm using what the datasheet refers to as "CCITT" (though some call it "CCITT-FALSE").
Using this algorithm, when I send a NULL command, I send the following frame (24b word length): 0x 000000 1D0F00 000000 000000 000000, which has the CRC MSB-aligned immediately after the command (as specified in the datasheet). I believe that '0x1D0F' is the correct CRC-CCITT (seed 0xFFFF), but the response to this in the following frame always seems to have the SPI_CRC_ERR bit set. This is especially confusing to me as prior WREG commands respond correctly with the form 0b 010a aaaa ammm mmmm, rather than with the STATUS register that it would if the CRC was incorrect. So I'm pretty confident that my CRC algorithm (which is using a known-working library, the FastCRC library built-in to the Teensy system) is working correctly, and that the device's input CRC check is working. I've also run the test value (['1','2','3','4','5','6','7','8','9']) through the CRC engine and gotten the correct answer (0x29B1). I was thinking that maybe the device's internal CRC engine wasn't re-seeding itself after each check, but since many writes in a row are successful, I don't think that's the case.
I've attached a sequence of four frames - a WREG, a WREG, a NULL, and a NULL - that demonstrate that the device responds as expected to the WREGs (with the correct CRC), but in the final frame, the response to the prior NULL is 0x3107, which says that the CRC_ERR bit is set, meaning the prior command (0x000 with a CRC of 0x1D04) is wrong.
Can you provide any insight into what might be going wrong here, or some tests I can try to diagnose?
Thanks.
Ben