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.

CC3300MOD: Require information about IRQ, Other configurations, API insight and Porting for TI CC3300 SDK

Part Number: CC3300MOD
Other Parts Discussed in Thread: CC3300

Dear All,

  1. Understood WLAN_IRQ_PIN is pin configured in AM243X LanuchPad Kit example "CC3xx_thick_mac_network_termina" for IRQ from BP‑CC33XXMOD. In which file this WLAN_IRQ_PIN and WLAN_IRQ_TRIG_TYPE is declared.

What is trigger type Falling or raising?

GPIO_setTrigType(gWlanIRQGpioAddr, WLAN_IRQ_PIN, WLAN_IRQ_TRIG_TYPE);

 

  1. We are going to port this IRQ on STM32F412ZG. As part of porting understood need to
  • Configure IRQ pin as per hardware and assign edge as positive or negative
  • Callback will get configured internally in SDK
  • That’s it.
  • If configuration is correct, then IRQ should work without much hassle.
  • Is our understanding correct?
  • Any additional point which we need to consider then please suggest.

 

  1. For BP‑CC33XXMOD SPI interface understood the interface is divided into 2 parts.
    • Part 1: Simple SPI master slave communication, where master will send command and will send dummy clock to read response
    • Part 2: On IRQ, read data from BP‑CC33XXMOD by sending command and read response as Part 1
    • Is this our understanding of SPI communication is correct. Any change please clarify.
    • Wlan_if.c, wlan_commands.h, provide User API function like Wlan_Start, Wlan_Stop, Wlan_RoleUp, Wlan_RoleDown, Wlan_Connect, Wlan_Disconnect, Wlan_Scan, Wlan_Get, Wlan_Set. Just for information, which all command from above list involves IRQ?

 

  1. After porting during testing functionality will not work due to SPI, IRQ or internals of SDK routines. What is you recommendation to investigate exact which component from SPI, IRQ, SDK is not working and how to analyze it in order to make it work.

Thanks.....

  • Hi,

    1. The cc33xx SDK can be looked as a plugin, meaning it needs a base SDK to work with. In this case, the AM243 is the base SDK. In addition, all hardware definitions are handled as part of the syscfg so these defines can be found in the auto generated file ti_driver_config.h and all other defines are in the AM243 SDK. So for your specific question, with AM243 it is a rising edge type.
    2. your understanding is correct. If you have an edge option in STM, you can use it and mimic what AM243 does. Please note that the IRQ handling should be simpler in this case because there is a single source of the interrupt which is the cc33xx chip itself and the chip would not de-assert the interrupt until the host sends the 0xBFFC message. So it is not possible to get (and miss) an interrupt before the host acknowledges the interrupt.
    3. generally there are 3 possible commands: 0xBFFC, 0xBFF8 and 0x BFF0.
      1. 0xBFFC is acknowledging the interrupt and read some important values like the type of the message (command complete, event, data).
      2. 0xBFF8 is just to read some more data from the mailbox between the chip and the host that has not come via the 0xBFF0. Could be for example scan result during wlan_scan.
      3. 0xBFF0 is for actual data/command going in and out. So every command would use it to carry its command payload. Also will be used for actual RX/TX of data, etc.
    4. The actual wlan_xxx() APIs would use all the above. Every command needs to go through all. So wlan_get() for example would send 0xBFF0 for the actual command, then get an interrupt which would trigger the 0xBFFC and eventually the 0xBFF8 to read more data from the mailbox if required.
    5. best way is to use a logic analyzer to probe the lines with some messages on the driver side.

    Regards,

    Shlomi

  •   

    Thanks for explanation.

    while further study found interrupt service routine for IRQ as  

    We are studying further how ISR handle IRQ, 

    1) Understood below function is the one which handled IRQ and 'FwEvent_StateMachine' handles state machine for IRQ.

    Please confirm our understanding.

    2) Please explain little bit about internal working of IRQ handler routine

    3) Based on previous discussion understood about 2 threads as Event Thread and Trasport Thread. How those thread is having relation with IRQ handler routine.

    4) While porting on other microcontroller like STM32, understood we need to use same callback function without any change. Please confirm.

    5) We are going to start our testing with "Wlan_Start" api. Please let us know whether IRQ pin will come in action for this api. If yes, please provide some details.

    6) Also please let us know "Wlan_Start" api, which are different command got exchange between Host and CC3300 over SPI.

    Thanks...

  • Hi,

    Yes, your understanding is correct.

    basically, IRQ main entry point is FwEvent_irq_handler() and then it requests work from the main transport task via trnspt_RequestSchedule().

    Upon initialization, several clients register to the transport task via trnspt_RegisterClient() to get bandwidth, one of those is the event client.

    The callback to be served is FwEvent_NewEvent().

    From this point, the state machine goes over all the states and sending 0xBFFC, 0xBFF8 and 0xBFF0 to the chip fetching/sending commands/events/data.

    Not sure I am following with what callback you refer to.

    AS for wlan_start(), of course IRQ is involved. For every chunk that is sent, you would see an interrupt assertion.

    For your reference, please find a logic capture for initialization phase that I captured some time ago.

    You could use it to understand more and double check yourself.

    Shlomi

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/ThickMAC_5F00_R9_5F00_init_5F00_roleUp_5F00_scan_5F00_connect.sal