# Software Deep Dive and Usage

## Thick-MAC threads

A Thick-MAC application is composed of 4 Threads.

> - Application: Main thread that calls/creates additional threads. Typically where the main application is found and executes from.
> - Networking stack: In a TCP/IP application this would be the LWIP thread but it can also be the Nimble thread in application with BLE enabled.
> - Host/WLAN: This thread handles requests to the radio.
> - Transport: Receives and sends commands & data directly to the radio.

### The Transport Thread

The Transfer Thread waits on a sync object that can be signaled by the following modules:

> - FW Events, types of events include:
>     - Rx available
>     - HW is ready
>     - Command complete
>     - Event for the driver
> - Tx, types of frames that can be tarnsmitted:
>     - Management
>     - Data
> - Command

The transport layer cycles through the clients and serves them one by one until no more events needs to be served

Fig. 5 Transport Thread

#### Power Management

Power management on the CC33xx is managed independently from the host. The CC33xx is always available to receive commands / data. The Host device can treat the CC33XX device as always awake(Power management is agnostic to the host).

There is a register that needs to be asserted when the interface is needed by the host.

Upon assertion (bit is changed from 0 to 1), the device will issue an IRQ with FwEvent telling us that the HW is available.

Fig. 6 FW Power management host state machine

#### FW events

IRQ handler receives an interrupt from the host IRQ if the FWEvents state machine is IDLE, ask for transport layer schedule to deal with state machine. Else set bit for pending events

- Transport layer context -
    1. Call the FwEvent state machine
    2. Set the power state machine for HW available
    3. Send all queued transactions over the interface
    4. Read the FW status register
    5. Serve the FwEvents
    6. Check if there were other events happening during serving
         - got to 4
         - else return

Fig. 7 FW Events

#### Send TX

The transaction over the interface needs to take into consideration the power mode of the device. The device’s interface power up is not autonomous and need to be manually monitored and the power state needs to be saved in the transport layer.

1. Enqueue the transaction
2. Check the power state
     - if the SM is awake - go to 4
     - if the state machine is asleep, write the ELP register for wakeup and return status PENDING to the inserted of the transaction
3. When receiving HW available from FwEvents, call send transactions in queue
4. Send transactions in queue -
     - send all transaction
         - if the current transaction was queued when we were asleep, call a CB to notify transaction was done
         - else (the transaction was just queued without moving context), return transaction complete status on the return value

The following chart shows us inserting a transaction

Fig. 8 TX Flow diagram

#### Commands

1. Send command
     - called from different context
     - allocate a command
         - sync obj
         - in buffer
         - out buffer
         - status
     - ask for Transport thread schedule
     - enqueue command
     - wait on sync obj until status is returned
2. Command schedule
     - dequeue a command
     - send command over transport layer
         - no matter if the device is asleep, we should get command complete or timeout so we don’t provide call back for the insert transaction
     - if timeout - timer context, preform context switch to the Transport thread
         - request schedule with cmd_SM with status timeout
     - if command complete - called from FwEvent (Transport Thread)
     - signal the sync object of the current command with the status

Fig. 9 event-flow diagram

### Common Guidelines to Follow

Known WLAN Command Sequence pitfalls

- Nested scanning → The application can trigger a nested scan (new scan started during an existing scan operation), but it will result in the nested scan returning -4123 error until the original scan completes.
- Nested connection → The application can trigger a connection attempt, first connection attempt is canceled and new connection attempt is applied instead.
- Scan while connecting → Not supported. Attempting a scan during a connection operation will result in a firmware crash.
- Connect while scanning → Not supported. Attempting a connection during a scan operation will result in a firmware crash.
- Scan while disconnecting → The application can trigger a scan while disconnecting.
- Disconnect while connecting → Operation is blocked by host driver since STATUS_BIT_ STA_CONNECTION is not set.
- Disconnect while scanning (and connected) → The application can trigger a disconnect operation while scanning, it disconnects from the AP and then shows the scan results.
- Station role down while scanning → Not supported. Attempting a STA role down command during a scan operation will result in a firmware crash.
- Station role down while connecting → Not supported. Attempting a STA role down command during a connection operation will result in a firmware crash.
- Station role down while disconnecting → The application can trigger a STA role down operation while disconnecting, station role is brought down successfully.