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.

cc3000 interfacing with nRF51822: Missing interrupts

Other Parts Discussed in Thread: MSP430G2553

I was trying to interfacecc3000 with nRF51822 arm cortex m0 controller. And i found that the host(nRF51822) misses IRQ interrupt with certain commands.

wlan_ioctl_set_connection_policy

nvmem_read

My host controller operates at 16MHz.

On analysis i found that some of the irq interrupts are missing while processing the received data and it waits infinitely for another irq from cc3000.

I would like to know is there any dependency on the speed of host processor with cc3000?

And how can i handle these missing interrupts?

  • I was trying to interface cc3000 with a host processor nRF51822 operating at 16Mhz.

    Is this possible to port cc3000 host driver for low speed controllers?

    Did anyone succeeded on porting cc3000 host driver with low speed controllers?

  • Hi Pramith,

    CC3000 should work with controllers with speed of 16MHz. The SDK v1.12 has support for MSP430G2553, which also operates at 16 MHz.

    For the missing interrupt problem, please make sure that you have implemented the SpiPause and SpiResume functionality correctly. Here we defer the interrupt processing for a later stage (when we re-enable the interrupt and check the status).

    Also, please make sure that the Service pack version and the host driver versions match as per the below link:
    processors.wiki.ti.com/.../CC3000_Release_Notes

    Regards,
    Raghavendra
  • Hi Raghavendra

    Thanks for your prompt reply.
    On porting the host driver to nrf51822, most of the times it waits for the response for wlan_set_ioctl_connection_policy()
    On this situation host driver hangs in hci_evt_handler().
    Can you help me to recover this condition?


    Thanks
    Pramith
  • On porting the host driver to nrf51822, most of the times it waits for the response for wlan_set_ioctl_connection_policy()

    On this situation host driver hangs in hci_evt_handler().

    Anyone had this problem before? And how it can be solved?



  • Hi,

    This could have something to do with the interrupt handling at the host MCU. We have not such a behavior with wlan_set_ioctl_connection_policy API. Waiting in hci_evt_handler suggests that the IRQ was not detected by the host.

    Also, please check if the command reached the CC3000 at the first place (CS asserted followed by an IRQ assert before sending over MOSI). processors.wiki.ti.com/.../CC3000_Serial_Port_Interface_(SPI)

    As indicated above, please check that you are using the correct versions of host SDK and Service pack.

    Regards,
    Raghavendra