256 replies to this topic

[hanzibal]

Ah, over air firmware updates - cool!

[piwi]

I just bought a new cc3000 chip with the new symbolization, but it had the old firmware.  So, I decided this weekend to start work on a C# based firmware flasher.  Nearly all the code is done, but it likely has bugs, but I am going to test extensively before I try anything on my guinea pig cc3000.  Also, I have added several key tests in the initialization to give useful errors when the communications are not working...  This will easily enable a remote update because the patch location can be anywhere.  

 

 

man .... this is so cool .... tell me, can you walk on water as well ....

[baxter]

I wrote a Visual Basic program to do the CC3000 startup in order to gain a better understanding of why we are not getting consistent startup results with modules that likely do no have any hardware flaws. The program does not employ generalized command/response handling, but rather just goes straight inline with SPI writereads interspersed with waiting for the CC3000 IRQ to go low as outlined in these documents,   (1) CC3000 Serial Port Interface (SPI) (2) Embedded Adventures WRL-CC3000V2 datasheet

 

The code is well documented and should be easy to follow. It runs through the "magic" startup sequence and then reads the CC3000 buffers. A successful read of the buffers is a necessary and sufficient condition for a succesful start. To further prove the start, I then read the SP_Version.

Sub Main()        Try            CC3000.StartCC3000(0)            Debug.Print("CC3000 Buffers" & vbCrLf & CC3000.CC3000Buffers)            Debug.Print("")            Debug.Print("CC3000 Service Pack Version " & vbCrLf & CC3000.SP_Version)        Catch ex As CC3000Module.CC3000Exception            Debug.Print(ex.Message)        End TryEnd SubOutput:CC3000 Buffers    Number of buffers: 6    Buffer size:       1500CC3000 Service Pack Version     SPVersion: 6.1.19

Waiting for the CC3000 to pull the IRQ line low is combined with a an interval timer that will throw an exception if an interrupt is not received within the specified time. I believe that I have identified the critical part of the startup.

 

The magic startup is: (1) power up acknowledgement (2) send the first 4 bytes of the HCI_COMMAND_SIMPLE_LINK_START (3) wait 50 uSec (netduino latency ok) (4) send the remaining 6 bytes (5) wait for CC3000 IRQ low   Code: IRQ_WaitForLow(2.0, Msg2) 'wait 2 sec

 

Item (5) is the critical part. The minimum wait interval is about 1 sec; if the wait is set to 0.5 sec, the CC3000 will fail to initialize. The wait time interval is of course not necessary. A wait such as the following will suffice,   While (IRQ.Read = True): End While

 

The module I am currently using is the WRL-CC3000V2 (v1.11) and it will start consistently with the program. My other WRL-CC3000V2 with the factory firmware also starts just fine. I haven't tried the program with the Boost modules; I am tired of re-wiring. SPI seems stable with a clock setting from 200kHz to 10 MHz. I am also using a 4.7k pullup on the IRQ line, but I don't think it matters having it or not.

 

The program is here,

 

https://www.dropbox....000_Startup.zip

[Valkyrie-MT]

I wrote a Visual Basic program to do the CC3000 startup in order to gain a better understanding of why we are not getting consistent startup results 

 

...

 

Item (5) is the critical part. The minimum wait interval is about 1 sec; if the wait is set to 0.5 sec, the CC3000 will fail to initialize. The wait time interval is of course not necessary. A wait such as the following will suffice,  

 

Thanks baxter.  Definitely useful information.  I have spent little time fine tuning the startup sequence.  

[Valkyrie-MT]

First firmware flashing success!!!  

 

Before: Response Received -- SP Version is 0.6.1.10

After: Response Received -- SP Version is 0.6.1.19

 

There is a lot of debugging output in here I think folks will get the idea...

CC3000 Wifi Patch ProgrammerStarting up CC3000...Sending - Simple Link StartHandling Response for OpCode: 4000, Payload: 0400400100Response Received -- Simple Link Start ConfirmedSetting Event MaskHandling Response for OpCode: 0008, Payload: 040800050000000000Response Received -- Event Mask confirmedRequesting SP VersionHandling Response for OpCode: 0207, Payload: 04070205000006010AResponse Received -- SP Version is 0.6.1.10Requesting Buffer SizeHandling Response for OpCode: 400B, Payload: 040B40040006DC0500Response Received -- Buffer Available: 6, Size: 1500Configuring DHCPHandling Response for OpCode: 2001, Payload: 0401200100Response Received -- DHCP Configured. The thread '<No Name>' (0x4) has exited with code 0 (0x0).Starting up CC3000...Shutting down CC3000...Sending - Simple Link Start (2)Handling Response for OpCode: 4000, Payload: 0400400100Response Received -- Simple Link Start ConfirmedHandling Response for OpCode: 0201, Payload: 0401020100Handling Response for OpCode: 1891, Payload: 0291181E00060000000600000000000000000000000000000000000000080028XXXXXXHandling Response for OpCode: 0201, Payload: 0401020100Handling Response for OpCode: 1891, Payload: 02911898000B000000800000000000000000000000000000000000000003000101101000272727272727272727272727272723252525252525252525232323230000000000000000000000000000000000000000005050505050505050505050505050505050505050505050505050505050505050505050017780501F22252527501F22252527501F222525271E2D01020202020011111511150F0EFFHandling Response for OpCode: 0201, Payload: 0401020100Handling Response for OpCode: 1891, Payload: 0291185C001000000044000000000000000000000000000000000000004C530000F301A0015100A0019303001093130010932300209343002093631000A1631000B3634000F3634000316400043368000200000000000000000000000000000000FAT: 4C530000F301A0015100A0019303001093130010932300209343002093631000A1631000B3634000F3634000316400043368000200000000000000000000000000000000Your MAC address is: 080028XXXXXXWRITE IT DOWN!!!!!!!!!!!!!!!!!!  If this patch fails, you may need to restore it manually!  If you lose your MAC address, it is gone forever!Radio Stuff: 03000101101000272727272727272727272727272723252525252525252525232323230000000000000000000000000000000000000000005050505050505050505050505050505050505050505050505050505050505050505050017780501F22252527501F22252527501F222525271E2D01020202020011111511150F0EFF****  PATHCING FIRMWARE NOW *****   -- PLEASE WAIT!Writing File 4Handling Response for OpCode: 0202, Payload: 040202050000000000....Handling Response for OpCode: 0202, Payload: 040202050000000000Writing File 5Handling Response for OpCode: 0202, Payload: 040202050000000000....Handling Response for OpCode: 0202, Payload: 040202050000000000******* FIRMWARE UPDATE COMPLETE *******Rebooting with new firmware (fingers crossed)Starting up CC3000...Shutting down CC3000...Sending - Simple Link StartHandling Response for OpCode: 4000, Payload: 0400400100Response Received -- Simple Link Start ConfirmedSetting Event MaskHandling Response for OpCode: 0008, Payload: 040800050000000000Response Received -- Event Mask confirmedRequesting SP VersionHandling Response for OpCode: 0207, Payload: 040702050000060113Response Received -- SP Version is 0.6.1.19Requesting Buffer SizeHandling Response for OpCode: 400B, Payload: 040B40040006DC0500Response Received -- Buffer Available: 6, Size: 1500Configuring DHCPHandling Response for OpCode: 2001, Payload: 0401200100Response Received -- DHCP Configured. The thread '<No Name>' (0x5) has exited with code 0 (0x0).WOO HOO, Firmware successfully patched!The thread '<No Name>' (0x1) has exited with code 0 (0x0).Done.Waiting for debug commands...The program '[200] Micro Framework application: Managed' has exited with code 0 (0x0).

Sadly, my cc3000em made the ultimate sacrifice and is eternally bricked (pretty sure).  I wrote a file allocation table with a starting offset that was off by 2 bytes and as far as I can tell, that is a fatal screw up.  I corrected the mistake, and then decided to skip the FAT rewrite entirely.  So, I actually believe that the FAT update is likely unnecessary and if I skip it, I would avoid having to backup and restore the user bits (including the radio params and MAC address).  Since bricking my cc3000em, I have tried the FAT-free version  on 2 different devices now and both survived.  The log from that last one is shown above.  I will be flashing a few more of these and if I don't brick anymore... I'll give it the 'ole hacker seal of approval and check in to codeplex!    

[baxter]

Whoa, this is outstanding. It's really a pain to go back to the TI platforms for updating. I think you may be able to recover your CC3000em by reflashing with the TI patch Programmer software. This reference claims that the Programmer is robust enough to recover from a bad flash,

http://www.sharebrai...for-10-dollars/

[Valkyrie-MT]

Have upgraded three cc3000 modules today.  All successful.  I think it's looking good.  But, I am a bit hesitant to release it without some wider testing...  I'd hate for anyone to brick their device.  Anyone want to be a guinea pig? 

[baxter]

I will volunteer a Boost ...

[Valkyrie-MT]

I will volunteer a Boost ...

 

baxter, 

 

send me an e-mail.  I will reply with the url for the zip.  

[Valkyrie-MT]

I just got Network Discovery working: 

 

Found 3 WiFi Networks: SSID - Signal Strength - Security----------------------------------2WIRE156 - 63 - Secured2WIRE416 - 49 - Securedlinksys - 83 - SecuredDone.

And it's easy to use: 

var wifi = new WifiAdapter("CC3000", InterfaceProfile.VTech_Device2);var networks = wifi.NetworkScan();if (networks.Length > 0){     Debug.Print("nFound " + networks.Length + " WiFi Networks: ");     Debug.Print("SSID - Signal Strength - Security");     Debug.Print("----------------------------------");     foreach (var aNetwork in networks)          Debug.Print(aNetwork.Ssid + " - " + aNetwork.SignalStrength + (aNetwork.Security == WifiSecurityType.Open ? " - Open" : " - Secured"));}

It will be in the next codeplex check-in.  

[baxter]

@Valkyrie-MT:

Wonderful news, again ... Your implementation is shaping up to be the most full featured and robust of all the current ports of the CC3000. The CC3000 rarely fails to start and when it does it is due to SPI gone sour for some unknown reason. I took a look at your thread on the GHI forum. Toward the end, poster MikeCormier's traces show that there is something wrong with SPI because the clock is idling high and your code correctly configures SPI mode 1. Since this is showing up on GHI hardware, it must mean that there is a bad glich in the MF (or who knows where).

 

Any plans to implement SmartConfig?

[Valkyrie-MT]

 

Any plans to implement SmartConfig?

 

Actually, I am working on Smartconfig now.  It is perhaps the last Major feature that does not work at all.  I have ping, dns lookup, network discovery, and mdns working.  The network discovery was tough because it was failing because of a .NET mf bug, but I have worked around that.  But, the mDNS had a major bug in the firmware that cannot be worked around.  It works for some things, but for name lookup, they hardcoded 'target.local' as the name for local resolution.  Hopefully TI can get that fixed sooner rather than later, but that is one of 3 bugs in the TI firmware.  I'll be submitting a list to TI soon.   

[Valkyrie-MT]

Any plans to implement SmartConfig?

 

I have smartconfig almost finished.  I'll be debugging it this week.  I sniffed all the SPI traffic and watched the stellaris work and I have everything figured out.  Unfortunately, I was not able to sniff the encrypted version of smartconfig because the iOS app does not seem to allow it.  But, a version of smartconfig will be working in about a week. 

 

I still have no clue though how the iPad, which is on the wifi network can communicate with the cc3000 which is connected to no access points at all.  I just don't understand this.  And yet, I type in an ssid and password and it appears moments later on the cc3000.  TI really does not explain how they do this... I really want to understand it though. 

[baxter]

I made numerous attempts to get SmartConfig to work with my MSP430G2553 and a Boost, but no luck. I tried both the iPad App and the PC Java program. You might get some insight into the workings from the Java program. I think the source is available.

 

I started on a Mini board for the CC3000. The problem is I don't use Eagle very often and I forget everything between sesions. My present thinking is to just use a CC3000 module as a daughter board; in particular, the WRL-CC3000V2 from embedded Adventures. It only costs ~$25 and the parts alone come pretty close to this number.

 

I am implementing the following functionality (comments welcome):

 

(1) Socketed Mini plus 2 female 12 pin long leg Arduino style headers. Need to do a little surgery for 12 pins.

 

(2) 8 pin female header for CC3000 daughter. Need to do some measuring for pancake arrangement. Vertical mount is a fallback option. Direct hookup to SPI and control pins.

 

(3) 2 gate Schmitt-trigger inverter circuit (74LVC2G14) on COM2 with a switch interface to a serial TTL adapter to select either COM2 for deploy or COM1 for applications.

 

(4) Micrel MIC5219 fixed 3.3V, 500Ma for power to the CC3000

 

(5) 8k byte I2C FRAM for secondary memory (8k pretty cheap, bigger more expensive)

 

(6) power eveything from a 1 or 2.1A, 5V tablet style charger.

 

(7) Maybe throw in an I2C DS3232MZ+ RTC

 

 

[Valkyrie-MT]

WOOT!  Smartconfig just worked!  It's Awesome!  I still don't understand how TI does it.  It's magic...  but it's awesome magic.  

 

If I can figure out how to AES encrypt the password from the iPad app, I'll try an tackle that.  But, right now, I am excited.  After I have SmartConfig all done, I am going to circle back and try to make the TCP/IP bullet proof and easy.  Then I might implement my own mDNS because TI did it wrong and they won't acknowledge my complaint.  

[Valkyrie-MT]

Here is a video of some of the new features in action!

 

http://www.youtube.c...h?v=LjZbpr2qPqU

[piwi]

Here is a video of some of the new features in action!

 

http://www.youtube.c...h?v=LjZbpr2qPqU

 

Just Awesome !! 

 

Any ATA of the software ?

 

Can the CC3000 be powered through a gadgeteer socket ?

[baxter]

Looks like a new service pack is available(V1.11.1),

http://processors.wi...atch_Programmer

http://processors.wi...#Version_1.11.1

It seems to be mostly network bug fixes.

[piwi]

Looks like a new service pack is available(V1.11.1),

http://processors.wi...atch_Programmer

http://processors.wi...#Version_1.11.1

It seems to be mostly network bug fixes.

 

@Baxter, thanks for the hint.

[piwi]

the patching worked ....

Example App:driver version 5.14.7.13MAC 08:00:28:01:6F:DBSP: 0.6.1.24

trying the software is again a complete different story ...

'Microsoft.SPOT.Debugger.CorDebug.dll' (Managed): Loaded 'C:UsersPeterCloudStationDevCerbuino4.3CC3KWifiExampleAppbinDebugleWifiExampleApp.exe', Symbols loaded.The thread '<No Name>' (0x2) has exited with code 0 (0x0).CC3000 Internet Time ExampleSending - Simple Link StartSend 4000 startingSetting Event MaskSend 0008 startingSend 400B startingConfiguring DHCPSend 2001 starting

and there it waits forever ...