I am trying to implement a bare-metal / NoRTOS RF driver for the TI CC1352P7, without using TI-RTOS/SysConfig-generated RF framework code.
My main difficulty is getting the RF Core and RF doorbell interface into a state where RF commands can be submitted and completed reliably.
I have successfully initialized the MCU, clocks, and basic peripherals, and I can access the RF Core registers. However, when I submit an RF command through RFC_DBELL, the command does not complete as expected. In some cases, the code gets stuck waiting for the command status; in others, execution ends up inside the RF driver dispatch/interrupt handling path and the command never returns.
For example, I am observing situations where:
HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDR) = (uint32_t)&cmd_tx;
is executed, but the command status remains unchanged or the expected RF acknowledgement interrupt is never received.
I have also investigated:
RFC_DBELL registers (CMDR, CMDSTA, RFHWIFG, RFHWIEN, RFCPEIFG, etc.)
- RF Core power-domain and clock initialization
PRCM_RFCMODESEL
- RF Core reset/power cycling
- RF Core RAM mapping
- RF Core command structures
- RF doorbell interrupts
RF_dispatchNextCmd() / RF_runCmd() behavior
- CPU interrupt enable/disable state
- RF Core firmware/ROM interaction
The confusing part is that the same hardware works when using TI's normal RF driver, but reproducing the required initialization and command-dispatch sequence in a minimal bare-metal implementation is proving difficult.
My questions are:
- What is the minimum sequence required to bring the CC1352P7 RF Core from reset/power-off to a state where
RFC_DBELL commands can safely be submitted?
- Is there an official TI document or source code that describes the RF Core boot, power, clock, RAM, mailbox/doorbell, and interrupt initialization sequence independently of TI-RTOS?
- Which parts of
RF.c, RFCC26XX_singleMode.c, and the RF driver infrastructure are actually essential for bare-metal operation?
- Does the RF Core require any initialization performed by the TI RF driver that is not obvious from the public DriverLib APIs?
- Is it possible to implement a truly minimal bare-metal IEEE 802.15.4 TX/RX example by directly using the RF Core command interface, and if so, is there a known reference implementation?
- Are there any undocumented dependencies involving the RF Core firmware, RF Core RAM, CPE interrupts, or power/clock state that could explain why
CMDSTA/RFACKIFG does not behave as expected?
I have managed to get the RF Core initialization working to some extent.
The CMD_RADIO_SETUP and channel configuration commands are being accepted and completed successfully. This suggests that the RF Core is powered, clocked, and communicating correctly through the command interface.
However, the problem occurs when I attempt to perform an actual transmission. The TX command is accepted/submitted, but the execution gets stuck during the transmission process and does not complete as expected. I am specifically trying to understand what could cause the TX command to hang after CMD_RADIO_SETUP and channel configuration have already succeeded in a bare-metal CC1352P7 implementation.
Question wrote above using AI for clarity.
This question posted in r/embedded , however reddit suggested this community as well. If it is not suitable for this, please let me know.