Title: Debugging Challenges in RDP Level 1 Mode on STM32G030
Introduction: I am encountering a puzzling issue while working with the STM32G030 microcontroller under RDP level 1. According to the reference manual, RDP level 1 should allow debugging access to RAM and peripherals but restrict flash memory access. However, my observations suggest that any attempt to access memory regions (RAM or peripherals) using the debug interface results in the CPU halting and eventually locking up. I have thoroughly reviewed the documentation, tried various solutions, and examined the errata sheet, but the root cause remains elusive. I am reaching out to the ST community for insights or shared experiences regarding this behavior.
Description of the Problem:
Setup Overview:
Debugging using the Serial Wire Debug (SWD) interface.
Readout Protection (RDP) is set to level 1.
Attempting to access RAM regions via the Debug Access Port (DAP) using the TAR and DRW registers.
Observed Behavior:
Writing to the Debug Halting Control and Status Register (DHCSR) to enable debug access (0xA05F0003) halts the CPU as expected.
Disabling the halt (writing 0xA05F0001 to DHCSR) does not resume normal CPU operation.
Any attempt to read or write RAM or peripheral addresses using TAR and DRW causes the CPU to lock up, as indicated by the DHCSR.
This behavior persists even when avoiding flash memory accesses entirely.
The problem disappears when RDP is disabled (RDP level 0), confirming that the issue is tied to RDP level 1.
The microcontroller in question is the STM32G030, which uses an ARM Cortex-M0+ core, revision r0p1.
Hypotheses Considered:
RDP Restrictions: According to the STM32G030 documentation, RDP level 1 prohibits flash memory access but should allow RAM access. Could there be undocumented restrictions on RAM or peripheral access?
Configuration Issues: Misconfigurations in the debug interface, such as incorrect setup of CSW or TAR, might inadvertently trigger halt or lockup conditions.
Silicon Errata: I have reviewed the STM32G030 errata sheet but found no direct mention of this issue. However, could this behavior result from an undocumented silicon bug?
Design Intent: Is this behavior an intentional design feature of RDP level 1, possibly for enhanced security?
Questions for the Community:
Have you encountered similar issues with debugging in RDP level 1 on STM32G030 or related devices?
Are there known workarounds to enable RAM access without causing the CPU to halt or lock up?
Thank you for your support and guidance!