Well I have bad news, good news, and bad news.
I finished porting the library’s SPI routines but the init routine locks, I traced that down to it waiting and never receiving an init reply from the CC3000.
I put the library to the side and went back to trying to communicate with it directly by bit-banging the handshake pins and manually sending the init string via SPI, and it’s failing the same way the library fails. I wanted to rule out the Teensy so I swapped it for a Nano + some voltage dividers (Arduino pin → 5.6K R → CC3000 pin + 10K R → GND).
I’m now able to do the initial handshaking, send the SPI init string, and get the SPI init response. (I’m not sure why the Teensy wasn’t working but I’ll come back to that later)
The problem now is the data I’m getting back is 1 bit off. Both the received bytes in the init string, and the bytes in the init response, have a leading 1 bit:
02 00 FF 00 00 00 00 00 00 00 (expected)
81 00 7F 80 00 00 00 00 00 00 (observed)
02 00 00 00 05 04 00 40 01 00 (expected)
81 00 00 00 02 82 00 20 00 80 (observed)
TI’s documentation (http://processors.wiki.ti.com/index.php/CC3000_Host_Programming_Guide) says:
The SPI protocol is used to communicate with the CC3000 device from the host MCU that is acting as the SPI master while the CC3000 device is the SPI slave. The protocol is an extension of the existing standard SPI. The endianness on transport is assumed to be most-significant bit (MSB) first.
The clock and phase settings for the SPI are configured such that the data is sampled on the falling edge of the clock cycle. Note that different MCU may use different naming conventions in order to configure SPI clock phase and polarity, For example, MSP430 uses UCCKPL and UCCKPH for clock polarity and phase respectively. Both are set to 0, indicating that the data is sampled on the falling edge of the clock cycle. The more generic convention is CPOL and CPHA, however, in order to configure sampling on the falling edge of the clock cycle, CPHA is set to 1.
I take this as CPOL=0 CPHA=1, which for Arduino is SPI.setDataMode(1), but that isn’t working. I’ve tried modes 0, 2, and 3 as well, and get the exact same results. I’ve also tried changing the SPI clock with DIV2, DIV4, DIV8 with no changes.
Short of bit-banging the SPI protocol to the CC3000, does anyone have any ideas on how to fix this?
I’m attaching my useless code, maybe I’m overlooking something obvious here?
cc3000.ino (3.62 KB)