• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 43 subscribers
  • Views 1059 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3100: SimpleLink API hangs scanning SSIDs

Sid Price
Prodigy 245 points

Part Number: CC3100
Other Parts Discussed in Thread: DISCOVERY-ADAPT

I am developing a test instrument using CC3100. My software for the project uses the SimpleLink API/Drivers. I am trying to scan for available SSIDs with the "sl_WlanGetNetworkList" API call. The issue is that most of the time this call never returns, however sometimes it completes correctly listing the SSIDs available.

I thought the issue was the maximum number of SSIDs permitted (20) because the first time this call worked I had reduced the number to 2. However I increased the number incrementally back to 20 and it continued to work. That is until I started to debug my project again this morning when it once again failed. I also tried putting a delay before my call to set the scan policy, this appeared to make it work, however later in testing the issue returned.

I am at a loss as to where to look next, any advice would be much appreciated,

Sid

  • 0
    TI__Mastermind 38980 points
    Hi Sid,

    You might be getting delays in the SimpleLink APIs if the SPI driver is not functioning properly. Please try putting a 100 ms delay after each ASSERT_CS and DEASSRT_CS in SPI read and write. If that resolves the issue, you can test with smaller delays.

    Best regards,
    Sarah
  • 0 in reply to Sarah P
    Prodigy 245 points
    Hi Susan, the issue may be due to the prototype hardware. I have found the SSID scan works just fine if my logic analyzer GND is connected to it. I also tried reducing the SPI clock speed but that didn't help. I may just need to work around this until a PCB is available.

    I am having another issue trying to connect to an AP. The call to connect never returns in spite of requesting a timeout. Any pointers?
    Sid
  • 0 in reply to Sid Price
    Prodigy 245 points

    Well it seems that my assessment of the issue was wrong. Once again I find the SSID scan is not returning.

    I tried adding 100mS wait after asserting and negating the chip select but this only served to cause the whole system to run very slowly, the issue remains.

    Once again, any help on this issue would be much appreciated,

    Sid

  • 0 in reply to Sid Price
    Guru 39650 points
    Hi Sid,

    From my point of view your issue sounds me like a signal integrity issue on SPI or power supply problem. Almost all weird behaviour of CC3100 reported at this forum was caused by hardware issue. Can you provide photos of your testing hardware? We can check if we don't see anything obvious.

    Good start-point how to debug HW problems you find here:
    - processors.wiki.ti.com/.../HardwareDesignReviewProcess.zip
    - processors.wiki.ti.com/.../CC31xx_&_CC32xx_HW_Debugging_AppNote

    Jan
  • 0 in reply to Hnz
    Prodigy 245 points
    Jan, my hardware is a breadboard that uses an ST-Nucleo as the host, a CC31XXBOOST, and some additional circuitry on a breadboard. It may well be that some of the hookup wire between these items may be a little long. Unfortunately the PCB for this project cannot be designed yet because of other research that needs to be done first.
    I suspect the stability of the prototype may be the issue and I hope I can find a way around it until I have "real" hardware,
    Sid
  • 0 in reply to Sid Price
    Guru 80805 points
    Hi Sid,

    It is hard to debug similar type of problem. It can be hardware or software problem. As software problem I mean some issue with porting SimpleLink driver to your STM MCU or wrong usage of SL API in your application. As hardware problem I think crosstalks on SPI, some interferences WiFi with your SPI bus or power supply problems. Good news is that you use CC31XXBOOST. We can eliminate potential problems with design around CC3100 chip.

    I have few questions:
    - You have issue only with sl_WlanGetNetworkList API? All other SL API works without any issue? What type of SL API do you use (sockets, filesystem, etc.)?
    - What version of CC3100 SDK and ServicePack inside CC3100 do you use?
    - SL API calls cannot be called from sl_ asynchronous handlers context. Please check if you not do that.
    - Can you check power supply directly at CC31XXBOOST, for voltage drops?

    Maybe Sarah can give you some other advices.

    Jan
  • 0 in reply to Jan D
    TI__Guru* 91336 points
    Sid -
    have you considered to leverage the board we made available for such non-TI MCUs, for the BoosterPack interface?

    www.ti.com/.../discovery-adapt

    in case you have some breadboard issues, maybe this would be useful/stable platform for you.
  • 0 in reply to Josh Wyatt
    Prodigy 245 points
    Josh, Jan,
    I made a small change to the power supply setup for the prototype. Previously I was powering the CC31XXBOOST with 3V3 from the Nucleo, I changed this to feed 5V from the Nucleo to the CC31XXBOOST and set the jumpers to use the on-board LDO. So far the reliability seems much better.
    I looked at the Discovery-Adapt board and it may offer a "plan-B" if I continue to have issues. It would be nice to have a Nucleo-adapt :o).
    Thank you both for the input,
    Sid
  • 0 in reply to Sid Price
    Guru 39650 points
    Hi Sid,

    It make sense that issue is with power supply. Just look to schematic for your STM board what type of power source is there. Maybe source is not able provide required current for CC31XXBOOST or you have connected Vcc by the very thin wires which causing significant voltage drop.

    Jan