[Testing] TI CC3000 1.28 Firmware

[Carl-SolderSplash]

Update 11/07/14 : mbed udp example has been sending/receiving UDP data for 24hours with out a problem
Update 10/07/14 : Work around for UDP issue by calling gethostname twice for the host "localhost" - mbed UDP example project updated to show this
Update 09/07/14 : Issue narrowed down to sending UDP message to IP address 224.0.0.251 - Otherwise it appears to be working well
Update 08/07/14 : There appears to be mbed UDP issues with this TI update - please only use this version for testing for now

Previous Release 1.12 can be found here : viewtopic.php?f=15&t=88

TI have released an updated version of the CC3000 firmware the latest is now 1.28.

Release package 1.13 = Service pack version 1.28

TI Release notes say :

Network Fixing the automatic ARP updates in the network stack which would make the long running TCP operations to hang.
Network Fixing the assert behavior, which would hang the CC3000 device and never allows it to recover.

Before continuing : Updating the CC3000 firmware carries some risk, do not interrupt power while the update is in progress, only update if you need to.

If you would like to update your CC3000 to 1.28 follow these steps :

1. Download this .bin file
2. Put your WIFI dipcortex in to bootloader mode by holding the boot button while inserting a connected USB lead into the Wifi DipCortex
3. Delete the firmware.bin from the mass storage device that appears
4. Copy over the bin file you have just downloaded - NOTE : MAC and Linux users will have to use DD
5. Reboot and connect to the CDC serial port using putty
6. Issue the command "cc3000 delete" to delete all saved connection details
7. Next "cc3000 init 1"
8. Followed by "cc3000 readp" - this reads the cc3000 config saved to the module by TI including the MAC address. It should say "Successfully read CC3000 eeprom parameters" when successful. Make a note of your MAC address in case things go wrong
9. To start the update "cc3000 patch now" - the screen will scroll as each chunk is written to the cc3000's eeprom
10. After a few seconds it should report "Successfully patched the CC3000 Driver"
11. If a failure is reported, do not repower (The modules MAC address is held in RAM), type "cc3000 init 1" and then try "cc3000 patch now" again.
12. Type "status" and the module should report "Version : 1.28"
13. Remove power, reconnect putty and then either use smart config by issuing the "cc3000 smart" command or manually connect using the "connect" command. Details here
14. Once connected "ipconfig" will show the connection details

[jhalfpen]

Hi Carl,

Thanks for this. I've updated our WiFiDipcortexes and I have a problem with UDP sending which wasn't there in cc3000 firmware 1.26 or 1.24. The TI release notes are very cryptic (to be polite . With 1.28, when I use socket.sendTo with a UDP socket, nothing is transmitted and the system hangs a short while later. Prior to this, the cc3000 has connected correctly to an AP using a stored profile and DHCP works correctly. With cc3000 firmware V1.26, a wireshark trace shows the UDP packets being correctly transmitted. Here's a piece of code which demonstrates the problem (wifidipcortex is connecting correctly to stored profile) :

#include "mbed.h"
#include "cc3000.h"
#include "UDPSocket.h"

cc3000 wifi(p28, p27, p30, SPI(p21, p14, p37));

// aaaaaa.local
#define MDNS_QUERY {0,0,0,0,0,1,0,0,0,0,0,0,6,0x61,0x61,0x61,0x61,0x61,0x61,5,0x6c,0x6f,0x63,0x61,0x6c,0,0,1,0,1}
const char* mDNS_BROADCAST_IP = "224.0.0.251";
const int mDNS_BROADCAST_PORT_UDP = 5353;
const uint8_t mDNS_query[30] = MDNS_QUERY;

// Set StaticIP, SubnetMask, DefaultGateway and DNSServer to zero for DHCP
uint32_t StaticIP=0;
uint32_t SubnetMask=0;
uint32_t DefaultGateway=0;
uint32_t DNSServer=0;

int main(void)
{
UDPSocket socket;
Endpoint outEndpoint;

wifi.start(0);
wifi._netapp.dhcp(&StaticIP, &SubnetMask, &DefaultGateway, &DNSServer); // Configure CC3000 for DHCP (Parms.==0)
wifi._wlan.ioctl_set_connection_policy(0, 1, 1); // Enable auto connection to profiles

wifi.stop();
wait(1);
wifi.start(0);

while ( !wifi.is_dhcp_configured() )
{
}

if (0 == socket.bind(mDNS_BROADCAST_PORT_UDP) )
{
// 2 second timeout
socket.set_blocking(false, 2000);

outEndpoint.set_address(mDNS_BROADCAST_IP, mDNS_BROADCAST_PORT_UDP) ;

while(1)
{
socket.sendTo( outEndpoint, (char*)mDNS_query, 30) ;
wait (1);
}
}
}

Do you know if there is any better release info from TI on this version of cc3000 firmware?
Thanks
John

[Carl-SolderSplash]

Hi,

Thanks for the test report. I share you frustration with TI's release notes, hopefully they will improve. I haven't found anything with more detail.

I've re-produced it with the mbed library + kitchensink demo. it's works okay with the LPCxpresso library where I am using sendto to send UDP packets.

I've created a new mbed project to purely focus on the sending UDP packets only and it works, so I need to find the difference, but the good news is that UDP still works.

Can you give it a go : http://mbed.org/users/SolderSplashLabs/ ... x-UDPDemo/

[Carl-SolderSplash]

I then added your mdns broadcast IP, port and mdns message and got the CC3000/mbed library to stop..

By a process of elimination it appears to be the IP address it has a problem with, changing that to a unicast address or subnet broadcast and the UDP message is sent. this is with version 1.28.

192.168.0.255 = Works
192.168.0.10 = Works
224.0.0.251 = Doesn't on 1.28 does on 1.26

Logging the CC3000 coms it does appear that this is a CC3000 firmware issue, the first request to send data is accepted and the 0x100F HCI_EVNT_SENDTO event returned by the module. The next request to send then hangs waiting for the HCI_EVNT_SENDTO event from the module, which never arrives.
TI's stack is sat waiting for this message.

I have posted to the TI e2e forum to ask for help.

In the mean time, if you want to use this version (which may be more stable in other areas) you will need to use the broadcast address instead.

[jhalfpen]

Hi Carl
As per the TI forum post, I tried the recommended (by who?) work - around by adding a couple of calls to GetHostbyname and it works. Question is where can we find these 'known bugs' and 'workarounds' - it would be tremendously time-saving
John

[Carl-SolderSplash]

Yeah I have just seen the reply myself, glad to know its working for you! As you, would love to know where TI are keeping a list of these issues.

Updated my UDP example mbed project with the gethostname suggestion and it's working as well, I can see messages being sent to 224.0.0.251.

Edit : Referring to the TI E2E thread, I've found one where the poster had a reply from TI telling him to call gethostname for UDP issues with 1.28 (1.13)

[martinbogo]

I was able to upgrade my WiFi DipCortex successfully to 1.28 using the .bin file. I cannot, however, currently compile any valid installable example code from the mbed website.

Is thare an issue with the code that the mbed website is generating for firmware.bin files?