[CC1352P Review] Communication method between wireless CPU and main CPU

cruelfox

[CC1352P Review] Communication method between wireless CPU and main CPU [Copy link]

　　The wireless part of CC1352 is handled by an ARM Cortex-m0 CPU, so how do it and the main CPU use on-chip resources and work together?
　　The SDK does not contain any code related to the Cortex-m0 CPU, so it does not need to be programmed. Unlike the ST STM32WB55, the Cortex-m0 CPU of CC1352 does not use the system Flash to store programs - it uses its own ROM. This does not support software upgrades, and there is no fear of firmware being damaged by misoperation.
　　This diagram in the manual shows how the subsystems of the two CPUs are connected and communicate.

　　According to the manual, both the system RAM and the Radio RAM are accessible to both CPUs, and data can be shared in any RAM for data transfer (DMA can also be used to move data between them). A portion of the Radio RAM can retain data in low-power mode, so that the wireless part can be put into standby mode with extremely low power consumption after the main CPU and SRAM are powered off, and the system can be woken up when needed.

　　Radio Doorbell provides a communication channel between the two CPUs, because Doorbell can generate IRQs to the two CPUs. There are four IRQs on the Cortex-m4 main CPU side: RF_CPE0, RF_CPE1, RF_HW and RF_CMD_ACK. There are not many registers, except for those related to interrupts. The interesting ones are CMDR and CMDSTA.

The meaning of "command" (CMD) here is not the command to the hardware device Doorbell, but the command to be issued to the wireless subsystem, that is, the command to be passed to the Cortex-m0 CPU. The command content represented by the register can only be interpreted by software, but how can this 32-bit register contain all the contents of the command? A closer look at the description of CMDR will roughly understand:
That is, CMDR can pass a "direct" command or a 32-bit aligned address. Recalling the RF command structure I saw when analyzing the rfEasylink_nortos example, I can guess that the address of the RF command structure variable must be written to Doorbell.

　　Let's look at the RF driver code in the SDK. In RFCC26X2_multiMode.c, there is the following code snippet in the RF_dispatchNextCmd() function:

				/* Decode the radio operation itself. */
                RF_Op* pOp = (RF_Op*)pNextCmd->pOp;
                /* Send the radio operation to the RF core. */
                RFCDoorbellSendTo((uint32_t)pOp);

The RFCDoorbellSendTo() function is implemented like this:

uint32_t RFCDoorbellSendTo(uint32_t pOp)
{
    // Wait until the doorbell becomes available
    while(HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDR) != 0);
    RFCAckIntClear();
    // Submit the command to the CM0 through the doorbell
    HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDR) = pOp;
    // Wait until the CM0 starts to parse the command
    while(!HWREG(RFC_DBELL_BASE + RFC_DBELL_O_RFACKIFG));
    RFCAckIntClear();
    // Return with the content of status register
    return(HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDSTA));
}

Yes, the RF_Op type pointer is indeed written into the CMDR register. Then the wireless CPU will parse the command and read the data contained in the command according to the address.

　　The CC13x2 manual uses more than 100 pages to list the data packet structure definitions of various commands. Although developing applications such as BLE and Zigbee does not require understanding such low-level details, TI treats the MCU as a device, and the completeness of its manual is remarkable.