[CC3000 bringup] Unknown HCI command opcode from CC3000.

Perhaps a keep alive packet?

#define HCI_EVNT_WLAN_UNSOL_BASE     (0x8000)
#define HCI_EVNT_WLAN_KEEPALIVE          (0x0200  + HCI_EVNT_WLAN_UNSOL_BASE)

Hi Martin,

Keep alive packet may be a possible answer. Yet, I was getting this opcode during the initialization state of CC3000 (SL start command , read buffer etc) much before connecting to an AP. 

I may not be seeing this opcode now as this event is masked after HW initialization state.

Thanks,

-VR Shankar.

Hello VR Shankar,

just one additional hint:Each set bit in mask tells which event to disable.

wlan_set_event_mask(0);

means ENABLE all events.

Best regards,

Martin

Dear VR Shankar,

I have exaclty the same problem you have described in this post. The CC3000 answers in the same wrong way at the Read Buffer command. I'm using MSP430FG4618 with CC3000 EM. In my code the nCS is correctly set as a a GPIO. More precisely, what did you changed in your code in order to make it work?

Thank you in advance and Best Regards,

Mario

Hi Mario,

Please post the byte streams (host->cc3000 and cc3000->host) for information.

I tried the following to get it work :

1) Changing SPI_CS from module pin to GPIO pin and controlling from ASSERT_CS() and DEASSERT_CS() macros. Seems you have done that already.

2) With jumper cables to connect my host and CC3000, SPI clock frequency had issues. With longer wires, I was not getting proper SPI reads with clock frequency more than 1MHz. Try with shorter jumper wires or with clock of 1MHz. Once SPI is stable enough, change it to higher frequency.

3) Added delays in some places (for eg. in hci_event_handler() at the end of while(1) loop)

4) Sometimes prints (which adds random delay) also helped. Later I removed them.

Let me know if any of these helped you.

Thanks,

-VR Shankar.

Hi VR Shankar,

In these days I've tried to figure out what is going wrong in the system. The byte streams are the following:

SIMPLE_LINK_INIT command:

host-->CC3000:   01 00 05 00     00 01 00 40 01 00 command: OK

CC3000-->host :  02 00 00 00 05 04 00 40 01 00 command complete: OK

READ_BUFFER_SIZE command:

host-->CC3000: 01 00 05 00 00 01 0b 40 00 00 command

CC3000-->host: 02 00 00 00 05 04 00 82 01 00 command complete WRONG 

So they are actually the same as the one you have previously posted.

I have followed your useful suggestions: I have reduced the SPI CLK from 4 MHz to 1 MHz but nothing changes. I don't use jumper cables, I use the TI dedicated EM mating connectors to connect the CC3000 EM to the MSP430FG4618 experimenter board. So I think that the physical connection has no problems, at least in principle.

Then I have tried to analyze the situation in details and I have observed the following:

 The first command is totally OK: The host sends the command and the CC3000 device answers in the correct way. I have observed the communication in detail (also with oscilloscope) and everything works fine.But when the CC3000 finished to correctly answer to this first command, the host deasserts the CS but strangely the CC3000 does not deassert the IRQ line, which remains low.

Then the transmission of the second command starts and the piece of code which describes it is the following:

// We need to prevent here race that can occur in case 2 back to back
  // packets are sent to the  device, so the state will move to IDLE and once
  //again to not IDLE due to IRQ
  tSLInformation.WlanInterruptDisable();
  
  while (sSpiInformation.ulSpiState != eSPI_STATE_IDLE)
  {
   ;
  }
  
  sSpiInformation.ulSpiState = eSPI_STATE_WRITE_IRQ;
  sSpiInformation.pTxPacket = pUserBuffer;
  sSpiInformation.usTxPacketLength = usLength;
  
  // Assert the CS line and wait till SSI IRQ line is active and then
  // initialize write operation
  ASSERT_CS();
  
  // Re-enable IRQ - if it was not disabled - this is not a problem...
  tSLInformation.WlanInterruptEnable();

  // check for a missing interrupt between the CS assertion and enabling back the interrupts
  if (tSLInformation.ReadWlanInterruptPin() == 0)
  {
                 SpiWriteDataSynchronous(sSpiInformation.pTxPacket, sSpiInformation.usTxPacketLength);

   sSpiInformation.ulSpiState = eSPI_STATE_IDLE;

   DEASSERT_CS();

When the macro ASSERT_CS() is called, IRQ is still low and so the CC3000 is not ready to receive the command, the handshaking then is wrong.

ReadWlanInterruptpin() detects that the IRQ line has 0 value, this is true, but the line was always at 0 V and so it does not indicate that the CC3000 asserted the IRQ line. Communication take place but in the wrong way, CC3000 has not said that it is ready to accept the command. When CS is then deasserted, something else strange happens: the IRQ line goes high and then immediately low, causing interrupt when unnecessary.

So seems that the CC3000 looks at the CS line in an "inverted" way in this phase. Very strange.

Do you have any idea or possible suggestion for this?

Sorry for the very long post, again thanks for your kind attention and Best Regards,

Mario Demaria

Hi Mario,

CC3000 not asserting the IRQ line after the first command may indicate only that CC3000 did not understand the command itself. SPI configuration seems good, else you wont be seeing the first command reply in proper order.

1) For the first write transaction, there is a delay added between ASSERT_CS() and the first 4 bytes, then a delay and the next 6 bytes. Are these delay in place ? Can you increase the delay in the first write and check what happens ?

2) I used byte-by-byte SPI read/write and not DMA. For debugging, I printed (through UART to teraterm) each SPI read and write bytes which was also adding a delay. May be that could also help.

3) For interrupt pin, can you enable a pull-up resistor ? When the interrupt line is "floating" it will be pulled up so clean state transition can be achieved when CC3000 actually interrupts.

I will post if I get more thoughts on this. You are almost there, some more tweaks are needed.

Thanks,

-VR Shankar.

Hi VR Shankar,

Thanks a lot, I will try with your suggestions. I have a doubt: I have not updated driver and firmware on my CC3000, because I want first to be sure thatr SPI works before updating them. Do you think that incorrect behavior can be caused by the non-updated Driver/Firmware? Well, in my opinion it should not be this the problem. 

Thanks and Best Regards,

Mario

Hi Mario Demaria,

Did you test the CC3000 module against any standard MCU release from TI (MSP430/FRAM/Stellaris) ? If it had worked with TI release, then your problem is porting issue only. 

Pls post your host driver/application/SPI revision and the CC3000 module information. I may have the least info on driver-firmware compatibility, but other members in the community will be able to help once you post.

Thanks,

-VR Shankar.

Mario Demaria said:

ReadWlanInterruptpin() detects that the IRQ line has 0 value, this is true, but the line was always at 0 V and so it does not indicate that the CC3000 asserted the IRQ line. Communication take place but in the wrong way, CC3000 has not said that it is ready to accept the command. When CS is then deasserted, something else strange happens: the IRQ line goes high and then immediately low, causing interrupt when unnecessary.

What happens next ? In the IRQ handler, SPI state will be "IDLE" so a read transaction might be triggered. What does the host "read" from CC3000 ? If you capture the byte stream, please post it here.

Thanks,

-VR Shankar.

Hi VR Shankar,

I didn't have the possibility to test the CC3000 with other TI release, I have only MSP430FG4618 available. What I'm doing is to port the code taken from the BasicWiFiApplication of FRAM. The application version is 1.10.2 and the required patch version (SP) is 1.14 . A long time ago I was able to read that the patch version on my CC3000 is 1.8, so this will need to be updated.

When CS is deasserted, the CC3000 responds with the byte stream:

CC3000-->host: 02 00 00 00 05 04 00 82 01 00 command complete: WRONG

Notice that CC3000 was not able to understand the READ_BUFFER_SIZE command, since in this case the handshaking between CS and IRQ is not correct (IRQ remains always low before and after CS is asserted for transmitting the command). I don't know if the response of CC3000 is meaningful or not.

Thanks again and Regards,

Mario

Hi VR Shankar,

I think I'm arrived to the point of my problem. I was printing the byte streams on the monitor of my PC with a printf(), which actually takes a long time, too long for the CC3000. In fact I think that with this long time needed to print, the device stucks because it does not receive response in reasonable time and so it is not able to complete correctly the handshaking procedure.Now, without printf, the wlan_start() is executed correctly, as the correct byte streams are written to memory.

This may also explain the response of the CC3000; it is actually a KEEP_ALIVE (0x8200) unsolicited event coming from the CC3000 because it is waiting for a very long time the processor, busy in printing operation (i.e. communication with PC). It is like the CC3000 goes in a sort of  " time-out " and sends this unsolicited event to the MCU.

Thank you very much for your precious support and Best Regards,

Mario Demaria

Hi Mario Demaria,

It's great to know that you have solved this issue. :)

As you said, the KEEP_ALIVE was mentioned by Martin Maurer52841 before on this thread. I thought KEEP_ALIVE is similar to TCP keep alive feature so was confused how I could get it without any AP association happening. This seems to be a keep_alive over SPI and not over WiFi (may be this should to be documented clearly in the next release).

All the best with your CC3000 porting.

Thanks,

-VR Shankar.

Hello VR shankar,

I got a problem when send command to cc3000 for simple_link_Start at first 4 bytes. stream as following:

send to cc3000 :   0x01,0x00,0x05,0x00,0x00,0x01,0x00,0x40,0x01,0x00 right command send
receive from cc3000: 0x2c,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02,0x02 wrong command receive

Can you help me?

Thanks