• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 41 subscribers
  • Views 535 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Problem with interrupt while initializing the CC3000

k c
Prodigy 230 points

Hi,

I am using the CC3000 with a STM32f372 microcontroller. My problem is that the interrupt is not happening after the First packet write to CC3000 device.

Here I am able to the get the response to the simple link start command.

I am requesting 0x01, 0x00, 0x05, 0x00, 0x00, 0x01, 0x00, 0x40, 0x01, 0x00, and I am receiving the response 0x02, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00.

Which same response is given in ti CC3000 document, so I am suspecting my SPI transmit and receive both are working fine.

After receiving the first response from the CC3000 module I am not receiving the interrupt, so that  tSLInformation.usEventOrDataReceived(which is set in the SpiReceiveHandler) is always low. Please anyone help me to solve the problem.

 

Regards,

KC.

  • 0
    Intellectual 695 points

    Hi,

    From the description, you are able to do the first write operation. Driver does the first write only after a 'first' interrupt was received from CC3000 module.

    1) You can check your connection wires to avoid all the doubts about the software.

    2) Have you ported the interrupt enable/disable functions properly ? (May be you are waiting with interrupt disabled )

    3) Is the host controller big or little endian ? If it is configured for big endian mode, then are the macros for converting stream-to-host endian in place ?

    4) Can you check if the 'tSLInformation' structure is declared as 'volatile' ? It is accessed in both main and in ISR, so needs to be declared volatile.

    Thanks,

    -VR Shankar.

  • 0 in reply to VR Shankar
    Prodigy 230 points

    Hi Shankar,

     Thanks for your reply. All the connections are proper. Initially I am getting the interrupt, After that I am writing data and receiving the response.

    My interrupt Enable/Disable functions are proper, because I tested with external interrupt also. that reason enable/disable functions are proper(I guess).

    I am using the stream macros to convert to little endian mode.

    Before I am not using the volatile to tSLInformation structure. But after changing the declaration to volatile also I am receiving the same response.

    Regards,

    KC.

  • 0 in reply to k c
    Prodigy 230 points

    Hi,

     

    Now I am able to receive the interrupt after first packet write. But After interrupt I am not receiving the expected (response header 0x02 ,0x00, 0x00, 0x00, 0x05, response data 0x04, 0x00, 0x40, 0x01, 0x00) simple_link_wait_event response. But every time I am receiving the interrupt correctly. So please  anyone help me to solve the problem.

     

    Regards,

    KC.

  • 0 in reply to k c
    Intellectual 695 points

    Hi,

    Getting interrupts is a good sign. Read happens from the driver in the interrupt context itself. Please add some debug prints/breakpoints to see what happens after the interrupt comes.

    The driver SPI module has a state machine which triggers read/write from interrupt context. Trace the same to get more understanding of where the driver is getting stuck.

    Thanks,

    -VR Shankar.

  • 0 in reply to VR Shankar
    Prodigy 60 points
    KC or others,

    Did you ever find the reason why the CC3000 was returning the "unexpected data". I have the same issue.

    I am able to issue the Write commands - both a SimpleLink Start and a Read Buffer Size. All of the lines (EN, CSn, IRQ) are behaving as expected. The CC3000 even interrupts after a Write command as expected (for both the SimpleLink Start and the Read Buffer Size). So it looks like the CC3000 is actually initializing and starting up properly.

    But... when I send the 0x03 - and the following bytes - via SPI to "clock out" the data - I always get the same kind of data KC got:

    0x02, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 - for the SimpleLink Start Event
    0x02, 0x00, 0xFB, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 - for the Read Buffer Size Event

    - the first set with the 0xFF as the 3rd byte is described as the CC3000 SPI Protocol document as "WRITE protocol in MISO direction" - and that "During WRITE, the CC3000 publishes on MISO line: 0x02, 0x00, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00".

    Can anyone help me understand why I keep getting the "Write" data that the CC3000 publishes on the MISO line - and not the "READ protocol in MISO direction" after I send the 0x03?

    I must be missing something in my understanding of how the CC3000 Events are working.

    Thanks - JD