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.

Bugs found in Host Driver (also in 1.13)

Hi all!

I have been spending too much time now in getting the CC3000 to work on a STM32(M0) microcontroller. Aside from the typical porting issues around SPI, I have run into various bugs in the Host Driver, that I think would be nice to share.

1) nvmem_read: If there is some delay between the 'hci_command_send' and the 'SimpleLinkWaitEvent' calls (which could be caused by debug printf's, debugging using JTAG or even by a run-time interrupt handler), the statemachine locks up. The reason behind this is because the event will be received prior to the SimpleLinkWaitEvent call, the event is incorrectly handled as an unsolicited event, because the state variable tSLInformation.usRxEventOpcode is still at 0. The function 'hci_unsol_event_handler' incorrectly returns '1' in this case, indicating that the event was already handled. So I added this piece of code before the last if in this function:

// handle the case that the event was not unsolicited, but that the RxEventOpcode was not yet set by
// SimpleLinkWaitEvent. Do *NOT* indicate that the event was handled in this case!!
if (tSLInformation.usRxEventOpcode == 0) {
return 0;
}

2) In the function 'wlan_smart_config_set_prefix', the three captical T characters are written back to the memory location that is passed through cNewPrefix. Aside from being a bad practice, it crashed my STM32 because obviously this pointer points to a .rodata area, which resides in Flash. This caused a bus-error trap. I removed the statements, because the pointer to the string "TTT" is valid anyhow. It would be better to ignore the pointer and just use a local static instead.

Still, I am having issues with SmartConfig. It seems that the iOS application that I found in the AppStore does *NOT* use AES encryption at all, which causes the 'wlan_smart_config_process' function to incorrectly decrypt the unencryped pass-key into a nonsense pass-key.. Consequently, the profile that is stored in the module does not connect to the AP. I still have to try using the Android app, because I might be misinterpreting my hex dumps...
So far, I have only managed to get SmartConfig to work without WPA2. Connections can be made to a WPA2 enabled AP by using the manual 'wlan_connect' funcion, though. I still have to try to manually add a profile and see if that profile is correctly used at startup. If that works, I could store the pass-key that I get from SmartConfig in my own EEPROM and use a manual connect.  Dirty hack IMHO.
Any suggestions are very welcome.
Best regards,
Gideon
  • Hi Gideon,

    Thanks for pointing out the various possibilities that crash the system.

    For the first case, can you please paste your sample code, so that we can have a look at it.

    Can you please try smartConfig without encryption? This should avoid the problem of decrypting the unencrypted data. For this, define the flag CC3000_UNENCRYPTED_SMART_CONFIG and call wlan_smart_config_start(0).

    SmartConfig should work with APs secured with WPA2 security.

    Thanks & Regards,
    Raghavendra

  • Hi Gideon,

    thanks to share your analysis with everybody.

    I have a problem with send() that locks forever(always)...while revc works fine...Have you encountered also this issue?

    Raghavendra, is TI going to release a v1.14 this month? will you have a no-blocking implementation?

    Thanks

    Gian