This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HW/SW Development Game Plan for CC3000

Other Parts Discussed in Thread: MSP-EXP430FR5739, MSP430F5310

All,


I have two sets of hardware.

A.) The CC3000EM with the MSP-EXP430FR5739.

B.) Our custom PCB with the CC3000 controlled by an Atmel AVR.

I am trying to get up to speed on as fast as possible with all the details that I need to know for the development on my custom board.

1.) I have started off spending some time with the EVM (CC3000EM & MSP-EXP430FR5739) using the basic wifi application, using the SmartConfig tool on my ipad, and send/receiving UDP data. I don't know what else I can do with the EVM at this point. I mainly wanted to verify my access point works correctly and the Smartconfig works correctly with the ipad.

2.) I am now at a point where I believe it makes sense to start working with my custom board. I would like to verify that the CC3000 works correctly, I can connect to an access point and send data back and forth from the module without spending the time right now to have all the code written for my AVR.  I want to verify the hardware is working correctly before I jump into some time consuming software development.  If I set the jumpers so the CC3000 is in test mode should I be able to do all of this?  I have a header on the board for the connections to the WL_RS232_TX and WL_RS232_RX.  I also have a FTDI USB to  TTL serial cable for this connection.

3.) I am also at a point where I need to read all the documentation at:

http://processors.wiki.ti.com/index.php/CC3000

Is it fair to said that I should basically read all the information here?

4.) Any other tips or suggestions to make this ride a little less bumpy? :)


Thank you very much.

-Mike

  • My advice to you is try to save yourself the driver porting effort to the Atmel AVR if you can. Either try to find it already ported or go with an MSP430 MSU instead of Atmel. Otherwise you are risking a lot of wasted effort, should you decide that the CC3000 is not the way to go.

  • Thank you so much for the reply. 

    1.) I am looking for a port for the ATMEGA2560.

    2.) I wanted to know what I am looking for as far as the porting goes so I starting looking at the driver provided from TI that can be found in the SDK (version 1.12).

    3.) There seems to be two sections "CC3000 SPI" and "CC3000HostDriver".

    4.) In the "CC3000 SPI" directory there are only two files:


    spi.c

    spi_version.h

    Are these the only two files that are hardware dependent?

    5.) In the "CC3000HostDriver" directory there files such as:

    cc3000_common.c

    evnt_handler.c

    hci.c

    ...

    netapp.c

    and the associated header files.

    These look very generic, hardware independent and should not need to be modified. Correct?

    6.)  It seems that I should be able to pull all the source code into my project and compile. Assuming the changes to spi.c are correct.


    7.) Here is a link to an ArduinoCC3000 project that runs on the ATmega2560.

    https://github.com/cmagagna/ArduinoCC3000

    Does this look like I should be able to bring in this code without any problems? Any concerns or comments?

    Thanks.

    -Mike

  • Yes, most of the hardware specific code is in SPI.c and board.c and it is not much. You will also have to set up an IRQ line as well as an enable/disable line.

    Also use a dedicated SPI bus for the CC3000, since it does not play nice with other devices on the bus.

    I don't have any experience with the ATMega, but if you have the MSP430 code in one hand and the Arduino in the other you should be good to go.

    Also get the FRAM Experimenter's Board and a CC3000EM if you haven't already. All the CC3000 code works best with those two boards and it allows you to flash to the latest firmware very easily. It saved me so much time when things on my board were not working correctly. And I was porting to MSP430F5310, which should have been straight forward. I also had to make changes, due to the fact that I was using a different compiler.

    Also you will need to modify the rest of the code in few places. There are few instances of the code making your MCU to hang "by design". Just look for all instances of "while(1)".

  • 1.) I do have the FRAM Experimenter's Board and a CC3000EM but I don't see what I can really do with this.  I have been able to run the sample Wifi demo and smart config but that is about it. It doesn't seem to help with my ATmega custom board solution.

    2.) On my custom board with the CC3000 I am not able to update the firmware. It seems I will have to use whatever the CC3000 shipped with.

    3.) Where are you finding the board.c? I don't see this anywhere in the driver source code.

    -Mike

  • Mike Thornhill said:

    1.) I do have the FRAM Experimenter's Board and a CC3000EM but I don't see what I can really do with this.  I have been able to run the sample Wifi demo and smart config but that is about it. It doesn't seem to help with my ATmega custom board solution.

    2.) On my custom board with the CC3000 I am not able to update the firmware. It seems I will have to use whatever the CC3000 shipped with.

    3.) Where are you finding the board.c? I don't see this anywhere in the driver source code.

    -Mike

    Hi Mike,

    1. When you run into issues, you can see how the FRAM board runs compared to to your own board. You can put breakpoints and see the expected code path, etc.

    2. This is absolutely not an option! Your board has to upgrade the firmware. The code that you are porting has to be in sync with the firmware. TI does not specify that they will ship CC3000MOD with any particular version of the firmware. Besides it is pretty straight forward - just port PatchProgrammer_DR_Patch.c and PatchProgrammer_FW_Patch.c once you have everything else working.

    3. If you open the Basic WiFI applicationin in CCS, you will find board.c there. The pio_init() method has hardware specific code.