BOOSTXL-CC3135: sl_Start() returns ROLE_UNKNOWN even after setting AP mode

Additional question:

I have one more question related to this issue.
After calling sl_Start(), I noticed that the IRQ line remains constantly high.
As far as I understand, the IRQ line should normally stay low and go high only when an interrupt is triggered.

Does this constant high state of the IRQ line suggest that the module failed to initialize properly?

Any further insights would be much appreciated.

Best regards,
Shuichi Marutani

Hi Shuichi,

You are correct that normal behavior of IRQ is that it will assert LOW after HIB has been pulsed (high>low>high). IRQ will be HIGH before calling sl_Start() and it should be driven LOW after this API call. 

Can you check if jumper J8 is closed? Double check other Jumper settings as well to make sure that it is as expected.

Regards,

Santhosh

Dear Santhosh,

Thank you for your response.

Please find attached a waveform capture showing the IRQ and nHIB behavior during initialization.

After closing jumper J8, the IRQ pin indeed goes High, and the waveform seems to show correct transitions. The current jumper configuration on the BOOSTXL-CC3135 board is as follows:

• J2: 1–2 (VBAT_CC)

• J3, J4, J5: 2–3 (Pulled Down)

• J7: 2–3 (VCCLDO)

• J8: Closed

  

The IRQ pin (CC_IRQ) is monitored and appears to behave as expected in the waveform. However, despite this, the return value of the following API call:

is still ROLE_UNKNOWN (1), even though the device seems to be operating in AP mode (SSID "mysimplelink-xxxxxx" is visible on the PC).

Is there any condition under which sl_Start() would return ROLE_UNKNOWN, even if the device is in fact operating in AP mode?

Also, just to confirm:

Is it correct to understand that the IRQ line is considered “asserted” when it is High?

Any further insights would be greatly appreciated.

Best regards,
Shuichi Marutani

Hi Shuichi,

sl_Start(NULL, NULL, NULL) in step 1 should return a successful code. What is the application you're using?
Can you run network_terminal application from the SDK plugin? Do you see successful behavior or same as what you see? 

In my set up, I'm able to see that sl_Start() returns '0' for the first call.

Which MCU are you using with CC3135 booster pack? For my set up, I'm using CC26X2R1 launchpad.

Can you share the versions that you see when you run network_terminal application? Below are the versions from my board:

Tried to reproduce your scenario with network_terminal application by modifying it. I'm able to see that sl_Start() returning ROLE_AP (2). See below screenshot.

Regards,

Santhosh

Hi Shuichi,

Were you able to try the above suggestion? Any updates? 

Hi Santhosh,

Sorry for the late reply, and thank you for the suggestions.

I tried multiple approaches on my side, but I was not able to reproduce the behavior you see. In my setup, sl_Start(NULL, NULL, NULL) return ROLE_UNKNOWN (1).

Environment

Module/board: BOOSTXL-CC3135 (CC3135)
Host MCU: MSP430FR2355
SDK I used: CC3100SDK_1.3.0

Observed behavior (AP mode attempt)

sl_Start(NULL, NULL, NULL) → returns ROLE_UNKNOWN (1)
sl_WlanSetMode(ROLE_AP) → returns 0
sl_Stop(0) → returns 0
sl_Start(NULL, NULL, NULL) → returns ROLE_UNKNOWN (1) again

Even though step (4) returns ROLE_UNKNOWN, the SSID like “mysimplelink-xxxxxx” does appear on my PC’s Wi-Fi list, which makes me think the device is actually operating in AP mode.

Questions

Does CC3100SDK_1.3.0 support CC3135 at all, or do I need to move to simplelink_sdk_wifi_plugin_4_20_00_10 for CC3135?

I also found in another thread that CC3100SDK_1.3.0 does not support CC3135. Could this be the reason for the behavior I am seeing?

Thanks again for your help.

Best regards,
Shuichi Marutani

Hi Jan,

Thank you for your detailed explanation.
So, as you mentioned, CC3100SDK is not validated for CC3135 and is not recommended, and in addition, MSP430 does not have sufficient RAM, so reliable operation cannot be guaranteed.

I will purchase an MSP432 series and try with that instead.

I have one additional question:
On the official website, for BOOSTXL-CC3135, the SDK listed is SIMPLELINK-WIFI-CC3120-SDK-PLUGIN (simplelink_sdk_wifi_plugin_4_20_00_10).
Should I instead be using the CC32xx SDK as you suggested?
(Reference: www.ti.com/.../BOOSTXL-CC3135

Best regards,
Shuichi Marutani

Hi,

Why you want to use CC3135? This is not a latest device. Maybe you can check CC33551E.

With CC3135 you should to use WiFi plugin. But if you want to use latest host driver, you can took them from CC32xx SDK copy over host driver in WiFi plugin.

Jan

Hi Jan,

Thank you for your clarification.
I learned from your explanation that when using CC3135, it is necessary to use the WiFi plug-in, and if I want to use the latest host driver, I can copy it from the CC32xx SDK and overwrite the one in the WiFi plug-in.

Currently, we are considering replacing the Wi-Fi module used in an existing product.
Our current system is designed so that the Wi-Fi module is controlled by an external MCU, and we would like to keep this architecture.
(In other words, we are looking for a Wi-Fi module that can be controlled from the external MCU and does not require software development on the Wi-Fi module side.)

From this perspective, CC3135 seemed the most suitable choice, since it allows control from an external MCU without needing application development on the module itself.
However, we are still in the evaluation stage, so if there are other modules more suitable for this kind of use case, could you please advise?

Best regards,
Shuichi Marutani

Hi,

If you have enough resources indie your MCU or if you are using MPU running at Linux, modules CC3301MOD and CC3351MOD may to be a option. These modules are much cheaper than CC3135MOD. But be aware that these modules need more resources at host (TCP and TLS stack is running at your host MCU/MPU).

Jan

Thanks Jan D  for your help here! 

Hi Shuichi,

For reference, I was using 'simplelink_sdk_wifi_plugin_4_20_00_10' with my CC3135 booster pack board, together with CC26X2R1 as the MCU host. 

Let us know the result with MSP432. 

Hi Jan,

Thank you very much for your explanation. I will take this into consideration for our evaluation.

May I ask one more question?
You mentioned that controlling CC3135 requires a certain amount of RAM on the host MCU side. Could you please clarify how much RAM is typically required?

In our production environment, the host MCU is planned to be CYBLE-222014-01 with 32KB RAM.
The conditions are as follows:

• nonOS

• TLS not used (only HTTP and WebSocket communication)

• 4 ports used, with simultaneous communication

Do you think 32KB RAM will be sufficient under these conditions?

Hi Santhosh,

Thank you for your support. I will perform the verification with MSP432 and share the results once available.

Best regards,
Shuichi Marutani

Hi Shuichi,

It is hard to give you such assessment. Technically 32kB RAM will be enough for such sockets application. But not sure how much memory left for you other application code and how big buffers for data processing and exchange you will need. But if you are retrofitting old application you likely know how much you have free RAM from thet 32kB.

Just to be clear. I am not a TI employee, but independent embedded developer with 15 year expires with wired Ethernet and WiFi application. If I should recommend one thing. Not not use non RTOS configuration with any devices which use WiFi or Ethernet. Using network device with superloop or interrupt-based application concept is pretty messy and can cause you many headaches. At the beginning it can looks like a faster way but I guarantee it will not be.

If you want to use BLE+WiFi from my point of view is CC3551E perfect device for you. Issue can be that CC3551E is a brand new device and is not such mature like other TI devices (CC3135/CC3235, etc.). Second issue can be that modules based on CC3551E are not out yet. There are plans for this modules, but at this moment I don't know exact roadmap. But maybe TI guys can give you more details.

Jan

Hi Jan,

Thank you very much for your valuable advice.
Since the existing system was originally developed in a non-OS configuration, we will follow that approach for this project. However, I fully understand your point, and in future designs involving Wi-Fi/Ethernet devices, I will make sure to adopt an RTOS-based architecture.

I also appreciate your explanation about the CC3551E. I will confirm the details directly with TI.

Finally, I understand that 32kB RAM should be technically sufficient for socket applications. I will carefully evaluate how much memory the rest of the application may require and proceed accordingly.

Best regards,
Shuichi