SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By Enkryptikon
#165377
I'm trying to connect to the CC3000 board from Adafruit via the SPI bus by the Fio V3 board and have run into trouble.

While the communications stops in the init-phase, everything I try fails. Has anybody successful run the SPI bus on that board? Because on the Arduino UNO it's working fine.

While I was hunting for the bug, I found out that the Board Specification and the
hardware/SF32u4_boards-master/variants/promicro/pins_arduino.h pin specification is not the same.

.h says:

SS=17
MOSI=16
MISO=14
SCK=15

Board says:

SS=14
MISO=17

I tried both, reassigned the pins. I can't work with pin 2/3 for interrupt for I'm using I2C, but I set it to 7/8 for IRQ/WLAN_ENABLE but still with no success. So I ran out of ideas at the moment.

I tried 17/14 and 14/17, 7/8 and 2/3 and any combination. I found some code to manipulate the wlan_init phase on that CC3000 but nothing helped. I also tried an other Fio V3, which didn't work either. So…

Has anybody an idea what's the matter? Has anybody got a working SPI bus on the Fio V3 yet?

using
https://github.com/sparkfun/SF32u4_boards
https://github.com/adafruit/Adafruit_CC3000_Library / buildtest
Output:
-----------
Hello, CC3000!

RX Buffer : 131 bytes
TX Buffer : 131 bytes
Free RAM: 1237

Initialising the CC3000 ...
-----------
<stopped>

As well as
https://github.com/cmagagna/ArduinoCC3000Test

With always the same result: hung in init.

Anybody with a working SPI bus on the Fio V3?
Last edited by Enkryptikon on Mon Nov 18, 2013 4:23 pm, edited 1 time in total.
By Enkryptikon
#165550
I activated DEBUG_MODE and got this:
Code: Select all
Hello, CC3000!

MISO 17
MOSI 16
SS 14
SCK 15
ADAFRUIT_CC3000_IRQ 7
ADAFRUIT_CC3000_VBAT 8
ADAFRUIT_CC3000_CS 14
RX Buffer : 131 bytes
TX Buffer : 131 bytes
Free RAM: 1685

Initialising the CC3000 ...
CC3000: init_spi
CC3000: Finished init_spi
init
start
CC3000: SpiOpen	CC3000: WlanInterruptEnable.
CC3000: Finished SpiOpen
CC3000: ReadWlanInterruptPin - 001
CC3000: WriteWlanPin - 001
CC3000: ReadWlanInterruptPin - 001
repeating last line 45 times
CC3000: ReadWlanInterruptPin - 001
CC3000	CC3000: Entering SPI_IRQ
CC3000: Leaving SPI_IRQ
: ReadWlanInterruptPin - 000
SimpleLink start
CC3000: SpiWrite
CC3000: SpiWriteFirst
CC3000: SpiWriteDataSynchronous Start
01 00 05 00
CC3000: SpiWriteDataSynchronous End
CC3000: SpiWriteDataSynchronous Start
00 01 00 40 01 00
CC3000: SpiWriteDataSynchronous End
CC3000: Entering SPI_IRQ
CC3000: SpiReadHeader
CC3000: SpiReadDataSynchronous
FF FF FF FF FF FF FF FF FF FF
CC3000: SpiContReadOperation
CC3000: SpiReadDataCont
CC3000: SpiTriggerRxProcessing
CC3000: SpiPauseSpi
CC3000: Leaving SPI_IRQ
CC3000: SpiResumeSpi
CC3000: Entering SPI_IRQ
CC3000: SpiReadHeader
CC3000: SpiReadDataSynchronous
after inserting some code into ccspi.ccp/SpiReadDataSynchronous the last part was this:
Code: Select all
size=010  000  FF  001  FF  002  FF  003  FF  004  FF  005  FF  006  FF  007  FF  008  FF  009  FF
   CC3000: SpiContReadOperation
   CC3000: SpiReadDataCont
   CC3000: SpiTriggerRxProcessing
   CC3000: SpiPauseSpi
   CC3000: Leaving SPI_IRQ
   CC3000: SpiResumeSpi
   CC3000: Entering SPI_IRQ
   CC3000: SpiReadHeader
   CC3000: SpiReadDataSynchronous

then repeating this part forever…
Just checking that the index for pulling the data was correct.

It's a bit tricky, this problem. Anybody ever had results with Fio V3/SPI? I also had problems with the DHT11 sensor, where code from adafruit failed, but I found code that was working. Maybe there's some hidden pullup on the Fio V3/Atmega32U4 or something that need changes in the usual way of serial communication, which would be the same for the sensor as for the SPI?

I mean the sensor was producing streams of zeros, where the SPI pull is producing streams of ones. Could be the wrong assumption, but I'm working on that. I just hope I'm not alone with this problem.

Since the CC3000 was working fine with a standard Arduino UNO board, it's either the frequency (8 to 16 MHz), the voltage (3.3V to 5V) or something on the pins/SPI management that differs. I don't believe in timing because it should result in random 1/0 streams instead of just streams of ones. I don't believe in voltage because we tried a 5V on the CC3000 and a logic converter between all SPI communication.
By Enkryptikon
#165697
We worked on that problem more. First we had the same problem with the Leonardo. Amusingly it was gone after soldering the six SPI pins to the chip. So the CC3000 is working well with the Leonardo now. It's working with the UNO.

I tested the IRQ pins, with the result, that the pins_arduino.h file was correct. It worked fine with D2->IRQ1, D3->IRQ0, D7->IRQ4. Still the CC3000 doesn't answer.

Check correct OUTPUT for pins SS, SCK, MOSI in SPI.cpp/SPIClass::begin()

So I wonder if the SPI is working at all on the Fio V3? At any project? Maybe I can just copy the working SPI code into my project. It's funny that I'm still not finding the reason for the failing.

As you can see the SPI.transfer(); that should give back the readings from SPI input is only returning 0xFF as often as you call it.
By ranthor
#166327
I tried and got it working. Here is how:

1) The board definitions for the Fio v3 seem to be wrong.
  • D14 is routed to the SS pin on the ATmega32u4 (PB0) and is shared with the RX LED
  • D15 is routed to the SCLK pin on the ATmega32u4 (PB1)
  • D16 is routed to the MOSI pin on the ATmega32u4 (PB2)
  • D17 is routed to the MISO pin on the ATmega32u4 (PB3)
A fork of the SFE board definitions with fixed pin assignments can be found here:
https://github.com/ranthor/SF32u4_boards

2) Pin assignment and connection:
  • D7 to IRQ
  • D8 to VBAT
  • D9 to CS (yes, D9 more on that later)
  • D15 to SCLK
  • D16 to MOSI
  • D17 to MISO
  • 3v3 to 3v3 (yes, not to VIN, more on that later)
  • GND to GND
3) Notes:
  • CS could be connected to D14 as well, but its use as the RX LED pin interferes with the operation of the CC3000. The Arduino Leonardo doesn't even break this pin out for user applications, probably for exactly this reason.
  • The ATmega32u4 disables hardware SPI whenever the mode of its SS pin is set to anything but an output. Since D14 is used to drive the RX LED, this should not be an issue, but please keep it in mind when fiddling with that specific pin.
  • VIN can not be used to power the CC3000 breakout because from 3.3v, the on-board regulator seems to drop the board voltage too low for the board to function properly. Using the 3v3 pin on the breakout bypasses the regulator and makes the board work like a charm.
By mellbratt
#174139
ranthor wrote:I tried and got it working. Here is how:
Thanks a bunch, worked really well! Would you create a pull request so it can be fixed in Sparkfun's source?

A