sl_start(0,0,0) stuck

In the meantime some questions arose that may be related to the problem. In the signal analysis above I used HOST_IRQ rising edge as with the CC3000.

Documentation of CC_RegIntHdlr() in "user_template.h" tells only to register an interrupt handler for the HOST_IRQ but not if this handler shall be called on rising or falling edge or both. I read somewhere that when level interrupts are used, two additional functions (sl_IfMaskIntHdlr and sl_IfUnMaskIntHdlr) must be implemented but no more details were revealed either.

I am sorry, in the above post it should be written "the falling edge" as with the CC3000 .
I meant, that I have also tried with rising edge but this did not work either.

Hi Christoph,

Please see the Wiki page here: processors.wiki.ti.com/.../CC31xx_Host_Interface
There is also an example in the CC3100 SDK called "spi_debug_tool" that should help narrow down the issue.

Regards,
Aaron

Dear Aaron

I have consulted this document many times before I dared to start this support request.

The only description related to my question in your hyperlink is the following:

• sl_IfRegIntHdlr Register an interrupt handler routine for the Host IRQ
• This line is active high, and can be treated as either edge or level (per host implementation).

If this interrupt must be registered on the falling or rising edge is not described there.

Also very confusing is the section that requires us to pull down the HOST_IRQ during initialzation. It meantions with no word, when this pulling down can end.

Simmilar can be said about the spi_debug_tool. In several documents it is written about the debug tools. But I have nowhere found a documentation about it. Just refering a SDK is not enough in my opinion. With other words you ask me browse a zip file, lookup a file and reverse engineer it to find out how to use it. All this, just to find out what is wrong with my device? Probably I would have to port these debug tools first to my plattform, just to get stuck somewhere else.

Could you please provide me with information about the debug tool?

My hope was, that my logic analyzer graphs would reveal the source of the problem.

Regards,

Christoph

Dear Aaron

In the meantime I have found the debug tool in the SDK and ported the code to your platform.
Its output is as follows:

Spi Test Begin
Spi Open Passed
Device Disable Passed
Device Enable Passed
Host IRQ Passed
Spi Write Passed

The next step should be a reading but it never ends because the CC3100 never responds.

By the way:

There is a problem with the debug tool. The variable g_irqCounter should be defined voltatile:

volatile int g_irqCounter = 0;

otherwise the loop in TestSpi() never ends because the variable is incremented in IRQ context (DiagIrqHandler) and the optimizer of certain compilers optimize the loop in a way that loop never ends.

I am still in the middle of nowhere. The CC3100 does not respond. It is blocked in the SPI_read test.

Do you suppose the CC3100 is broken when there is no signal on the MISO?

Hello Aron

I have still the problem that the all spi read from CC3100 show no reaction.

How would you expect the CC3100 startup precedure to be? Shall MISO be driven high after startup or after asserting CS?
It is always 0 and therefore the read never succeeds.

May it be a problem that there is a small spike of nHib at startup @0s,

or that spi clock speed is only 2 MHz?

Christoph,

I noticed from your waveform, the SPI is not in mode 0 like the CC3100 requires...
Thanks,
Aaron

Hello Aron

You are right. Thank you for this valuable hint.

CC3000 works with CPHA = 1 (found in http://processors.wiki.ti.com/index.php/CC3000_Serial_Port_Interface_%28SPI%29)

CC3100 instead with CPHA = 0 (swru386.pdf)

Wouldn't it be great to find this info for example in swra470.pdf or http://processors.wiki.ti.com/index.php/CC31xx_Host_Interface?

Why did TI change the clock phase CPHA for a successor of CC3000?

Now the first spi write looks like this:

but all following reads look like that: (means no resonse from CC3100)

Regards,

Christoph Speck

Hello Aron

Your are right. Thank you for this valuable hint.

CC3000 works with CPHA = 1 (found in http://processors.wiki.ti.com/index.php/CC3000_Serial_Port_Interface_%28SPI%29)

CC3100 instead with CPHA = 0 (swru386.pdf)

Wouldn't it be great to find this info for example in swra470.pdf or http://processors.wiki.ti.com/index.php/CC31xx_Host_Interface?

Now the first spi write looks like this:

but all following reads look like that: (means no resonse from CC3100)

Regards,

Christoph Speck

Christoph,

You can re-edit any of your existing Forum posts by clicking on the "More" button and then the "Edit" option. Feel free to use that should you need to update or change anything.

Hopefully here with your questions as well you got all the information that you needed.

Blake

Dear Aron

The small spike at FW startup was due to J5 on CC3100Boost. This problem is solved.

I captured the signal on the CC3100Boost when running the TI Radio Tool GUI and found a completely different startup behavior.

After asserting nHib the CC3100 signals the HOST_IRQ after approx. 85ms.

When the same CC3100Boost is connected to our own HW the startup is very fast (approx. 1 ms)

With the effect, that the CC3100 does not deassert the HOST_IRQ after receiving the Sync Word. With the effect that MISO is always low.

May it be problematic that MOSI is high before nHIB goes high? Shouldn't be the case because CS is high too!