CC3000 and AVR

[LukeW]

The attached schematic is a basic custom board combining an ATmega328 and a TI CC3000.

It doesn't work. It just sits there at "Initialising the CC3000 ..." in a serial terminal and doesn't get past that.

I'd like to know if anyone has any ideas as to why it might not be working. Thanks in advance!

To remove the need for any level translation components, the microcontroller is run at 3.3V, and a 8 MHz crystal is used so that the AVR is running with its crystal oscillator inside the officially supported voltage spec, and the SPI and interrupt/power enable lines from the CC3000 are tied directly to the AVR.

5V is supplied into the board to the 5V rail, although this is not shown on the schematic. The 3.3V LDO used is rated for 500mA output, which should be plenty for the CC3000. Everything should be basically consistent with the TI CC3000 schematic checklist.

For test purposes I'm using the Adafruit CC3000 Arduino library code and "buildtest" example Arduino program, running on top of an Arduino bootloader (Arduino Pro Mini Atmega328 3.3V 8MHz, for compatibility with the 8 MHz clock) on the AVR.

The only thing changed in the Adafruit code is the SSID, password and security type obviously. The same code, same WiFi AP, same network, same settings, same conditions, and same distance to the access point, are confirmed to work successfully using an Adafruit CC3000 shield. CC3000 Int, CC3000 En and CC3000 CS are pins 3, 5 and 10 respectively (in the Arduino numbering) so it's exactly the same as the Adafruit shield and these are left unchanged in the code.

There is no SD card in the card socket, so there is no possible issue with the SPI devices not going tristate properly. The CC3000 is the only SPI device and it doesn't have to share with other devices that may not be relinquishing the bus properly.

For the sake of simplicity, the CC3000 I2C lines are tied directly together without 0-ohm resistors, the CC3000 test UART breakout pins are not broken out, the reserved pins are not broken out. The two mode select pins are tied directly together so the device is always in "normal" mode.

The antenna has been changed from the reference design chip antenna... it's a microstrip meandered inverted-F 2.4 GHz antenna as per TI AN043. The matching/HPF components are kept unchanged as per the datasheet reference values.

IF there is an issue with antenna gain or improper impedance matching or something I would still expect it to have enough link budget to work since the board is only sitting about 3 feet away from the WiFi access point.

The schematic of the Adafruit CC3000 shield is here.
http://learn.adafruit.com/system/assets/assets/000/010/986/original/adafruit_products_ccshield.png?1379351866

Obviously I have omitted the 74HC4050, and I have also omitted the tristate buffer that takes MISO tristate when the CC3000 CS is deasserted (because the CC3000 itself fails to take MISO tristate properly). That may cause a problem with SPI communications with the SD card when the CC3000 is de-asserted, but to be honest I don't really care about using the SD, I mainly just care about having the CC3000 functional.

Other than that there are no significant schematic differences.

When new CC3000 silicon is purchased, does it require any special firmware configuration before use?

[Gustav]

yes you have to use the firmware that the library is written for check out the TI WIKI they have a  lot of useful information http://processors.wiki.ti.com/index.php/CC3000
i have never used the cc3000 with at ATmega but to me the schematic looks okay also if it is for a product you plan to sell i would yous a chip antenna as it will allow you to skip a lot of testing for CE and FCC.