Go Down

Topic: discussion on supporting the TI CC3000 WiFi module (Read 59 times) previous topic - next topic

Graynomad

Welcome to the world of porting code.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

martin_bg

I'd love to see this ported.

Some similar qustions being discussed here: http://e2e.ti.com/support/low_power_rf/f/851/p/260521/911920.aspx

Quote
void SpiPauseSpi(void)
{
   SPI_IRQ_PORT &= ~SPI_IRQ_PIN;
}
void SpiResumeSpi(void)
{
   SPI_IRQ_PORT |= SPI_IRQ_PIN;
}
As far I understand these functions enable or disabled the IRQ_SPI Line in your Microcontroller, and in case of CC3000 produce a falling edge in the IRQ Pin it would not be treated

I do the same using a Flag
void SpiPauseSpi(void)
{
  irq_flag=0;
}
void SpiResumeSpi(void)
{
  irq_flag=1;
}



magagna

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:

First string:
02 00 FF 00 00 00 00 00 00 00 (expected)
81 00 7F 80 00 00 00 00 00 00 (observed)

Second string:
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:

Quote
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?
http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.

westfw

#13
Jun 19, 2013, 02:17 am Last Edit: Jun 19, 2013, 02:19 am by westfw Reason: 1
I would find it difficult to believe that the TI module is incompatible with AVR's SPI...

It looks like SPI.setDataMode() is:
Code: [Select]
void SPIClass::setDataMode(uint8_t mode)
{
 SPCR = (SPCR & ~SPI_MODE_MASK) | mode;
}

Which means that you should be calling it with: SPI.setDataMode(1<<CPHA); instead of SPI.setDataMode(1)

There are a lot of complaints on the TI forums about the state of the CC3000 documentation (or lack thereof.)  :-(

magagna

#14
Jun 19, 2013, 02:31 am Last Edit: Jun 19, 2013, 02:34 am by magagna Reason: 1
I apologize for that error. I caught that a while ago. I've tried using the built in constants, e.g. SPI_MODE1, but get the same results no matter what option I pick.

Quote
There are a lot of complaints on the TI forums about the state of the CC3000 documentation (or lack thereof.)  :-(


Yes...it hasn't been as much fun as I'd hoped...

http://en.wiktionary.org/wiki/magagna <-- My last name.  Pretty apt.

Go Up