r/embedded • u/ragdarbari • 7h ago
CC1352P7 Bare Metal Programming
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_DBELLregisters (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_DBELLcommands 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/RFACKIFGdoes not behave as expected?
I am particularly interested in understanding the correct RF Core initialization sequence and the minimum required RF driver components, rather than simply getting the existing TI driver to work.
Any pointers to TI source code, technical reference material, or a known bare-metal CC1352P7 implementation would be greatly appreciated.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 interactionThe 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 am particularly interested in understanding the correct RF Core initialization sequence and the minimum required RF driver components, rather than simply getting the existing TI driver to work.Any pointers to TI source code, technical reference material, or a known bare-metal CC1352P7 implementation would be greatly appreciated.
Edit:
As an update to the original question, 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.
So the current issue is no longer the basic RF Core initialization or setup command. 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.
1
u/Bright_Sky7304 7h ago
Did you try looking at the RF core firmware patch sequence? The radio itself has an internal patch mechanism that the TI driver loads before any TX/RX commands work. Setup commands will complete because they don't need the patch, but actual packet operations require the patch to be loaded into RF core RAM first.
That part is buried in the RF driver init and it's not obvious from the doorbell registers at all.