simplelink in IAR, code optimization high - endless loop

Hi Rami,

First, it is highly recommended to align on the latest SDK and ServicePack (1.1.0 and 1.0.0.10.0 respectively).

Second, it is possible that optimization change the behavior - depends on the level of optimization. Compiler may choose to use registers for intermeddiate storage for example that may cause trouble, etc.

Are you working with UART or SPI? OS or non-OS? What are you expecting when hanging on _SlDrvRxHdrRead()?

Do you have the ability to capture the interface lines?

Shlomi

Hi, thanks.

I'm in process of moving to the 1.1.0/1.0.0.10.0 version, just burned the FW to a cc3100BOOST.
My problem is that I'm working directly on the proprietary board, not the development board, and connecting to the UNIFLASH is a bummer.
I also have a single board with a functional cc3100, so care is needed.
Next week I'll have a few of the new version of our boards.

I'm using SPI, non-OS.
I have a Saleae logic analyzer, I can attach a log-file (which can be opened with their free software) - is there a better solution?

Within _SlDrvRxHdrRead():
 - never exits the while loop.
 - VERIFY_PROTOCOL is defined as _SL_ASSERT, which finally goes to #define _SlDrvAssert(line )  { while(1); } <- should have caught that earlier... a few threads about it, but no solution...
 - can't use SL_PROTOCOL_HANDLING == SL_HANDLING_ERROR, too many compilation errors.
 
Obviously, high optimization requires 'volatile', etc. That is my question!
Most state-machine data in the simplelink are pointers to data-structures, which should hold through high optimization, but has it been tested? For the STM32 family with high optimization (for size)?

Rami,

Saleae is perfect, thanks.

What you are experiencing is sync loss over the SPI. The logic may shed light on it.

Testing cycle has been applied but bugs may still exist.

Regards,

Shlomi

I've attached 4 files, 2 runs - cc3100-Size-Good-4 and cc3100-Size-Bad-Short.
It's the same code running.
Seems that in 'Bad' the IRQ isn't called.

This is with the 0.5.2 version.
I couldn't get to upgrade the cc3100 within our board - it's a very early cc3100.

cc3100.zip

Hi Rami,

For some reason the logic is openned but no signals are shown. The size of the logic captures is very small so something went wrong.

In any case, the txt shows that the bad case does not even pass the sl_start()!!!

Can you tell the discrepancy between the two runs? does it happen sporadicaly or can you tell what steps you are taking to make it stuck?

In any case, it does not seem to relate to the SPI interface yet as you do not get the initialization done interrupt from the device. So it seems like the device hasn't completed initialization (could also be it is not powered or nHib is not toggled properly).

Can you make sure you follow the Wake-Up Sequence in the datasheet?

Also, it is highly recommended to upgrade to the latest SDK and ServicePack. v0.5.2 is really old and there are many fixes in the latest.

Shlomi

Hi Rami,

Did the above post answer your query? please verify the answer.

Shlomi

Hi,
I'm sorry for the delayed reply.
This whole project is being pushed aside every other week/month, with me (and you) hanging.
I finally received new boards, with the new cc3100.
When the project is back I'll upgrade to simplelink 1.1.0 (FW servicepack_1.0.0.10.0).

Regarding the analyzer logs:
If you look at the line descriptions, they're tagged as nHIB, RESET, MISO, etc. They're all in the logs.
It seems the wake-up sequence is correct (timing-wise).
The 2 runs are the same, simply resetting the device and the code goes through it's basic init; no IOs or any other peripheral or event.

The major thing that bothers me is not the missing IRQ, but the fact that the host gets stuck due to it.
I'm calling, in an 'endless loop' _SlNonOsMainLoopTask(), giving simplelink CPU time - I'd presume it'll exit on this or that timeout... after all - peripherals can fail.

Anyway, I'll update when I have the new simplelink running.
Thanks.

Rami,

Please let me know once you check it.

Regarding the host getting stuck, you are right. Since the driver permits a single command at a time, it waits for a signal when sending any command. The command complete event should release the semaphore. The non-OS flavor is "blocking" in this sense. If you use an OS, then the task is blocked but other tasks can still execute. In any case, we intend to introduce a mechanism to overcome it using timeouts. However, I cannot share any date as it is in developement.

Thanks,

Shlomi