Luckfox Forums

Posted: **2025-07-24 20:08**

Hi,

On the Milk-V Duo I can develop bare metal software on the small core using a JTAG debugger.
I would like to do the same on the rk3506 (Luckfox Lyra Plus). So using openocd and a SWD debugger I would like to contact to the Cortex-M0 core, upload the software from the ide, and debug from the IDE. So the development cycle is about 5 seconds or less.

Now as the RK3506 reference manual is available, there is much more information about the chip.
I switched the UART0 to SWD port M1 with these commands:

Code: Select all

iomux 0 22 2
iomux 0 23 2

I could connect this way with the openocd to the A7 core (using some rk3308 based configuration):

Code: Select all

Info : SWD DPIDR 0x2ba01477
Info : [rk3308.ahb] Examination succeed
Info : rk3308.core0: hardware has 1 breakpoints, 1 watchpoints

So I think my debug probe and hw setup works.

But If I routed the M1 port to the Cortex-M0 core with this:

Code: Select all

devmem 0xFF288000 w 0x00300020

I got no response from the chip using the openocd:

Code: Select all

Error: Error connecting DP: cannot read IDR

I tried to enable the HCLK_M0 and STCLK_M0 clocks with these

Code: Select all

devmem 0xFF9A0814 w 0x04000000
devmem 0xFF9A0820 w 0x00040000

Still no success ("Error: Error connecting DP: cannot read IDR)").
Remark: I did not load any code into the Cortex-M0 memory (at 0xFFF80000).
There is a note in the rk3506 TRM (reference manual):
grf_con_mcu_dbgen: SerialWire Debug Enable, 0 = disable, 1=enable, default=0.
But in the TRM I did not find any register with this name or any register containig containing this switch.

Can someone help me to connect to the Cortex-M0 core with openocd?

I like this board, the rk3506 seems to be an excellent device, but this must also work for me.

Best Regards,
nvitya

Posted: **2025-07-26 3:42**

Hello, this issue is beyond the scope of technical support and we don't have JTAG devices available to verify if the settings are successful. I can only offer some basic suggestions and I won't participate in further discussions.
Based on your description, GRF_SOC_CON0 is set with 5:4 as 10, the default JTAGM0 configuration is SDMMC, and JTAGM1 is used for the MCU. The related pin re-mapping configuration is also fine. I think it might be that the interrupt or clock resources of JTAG are occupied by the AP core, which are typically used by the AP core's fiqdebug.
The AMP configuration we provide defaults to loading the MCU's firmware at 0xfff84000. There is also a possibility that a firmware loading address needs to be allocated to the MCU or the firmware needs to be loaded in order to start JTAG debugging.
grf_con_mcu_dbgen does not provide a base address. It might be for setting the debug serial port. I think the configuration of this register should not affect the JTAG connection.

Posted: **2025-10-28 10:25**

Crocodile wrote: ↑2025-07-26 3:42 Hello, this issue is beyond the scope of technical support and we don't have JTAG devices available to verify if the settings are successful. I can only offer some basic suggestions and I won't participate in further discussions.
Based on your description, GRF_SOC_CON0 is set with 5:4 as 10, the default JTAGM0 configuration is SDMMC, and JTAGM1 is used for the MCU. The related pin re-mapping configuration is also fine. I think it might be that the interrupt or clock resources of JTAG are occupied by the AP core, which are typically used by the AP core's fiqdebug.
The AMP configuration we provide defaults to loading the MCU's firmware at 0xfff84000. There is also a possibility that a firmware loading address needs to be allocated to the MCU or the firmware needs to be loaded in order to start JTAG debugging.
grf_con_mcu_dbgen does not provide a base address. It might be for setting the debug serial port. I think the configuration of this register should not affect the JTAG connection.

The "Rockchip_Developer_Guide_AMP_EN.pdf" guide links to a non-assailable portion of documentation ?
https://github.com/ArmSoM/rk3506-rkr4.2 ... AMP_EN.pdf

Section 15.2 Debugging with OpenOCD - JTAG & SWD Connection Development and Debugging
pg 109

Do you have access to it ?

Posted: **2025-11-01 2:11**

Due to the absence of JTAG & SWD devices, we have not conducted any tests for this function.

Posted: **2025-11-17 4:18**

Hello. I had a same problem and found some workaround to debug M0 core with JTAG debugger.

As you stated, I was also unable to find any more details about `grf_con_mcu_dbgen` register bit, which seems essential to enable JTAG debug access on M0 core.

So I looked through u-boot code from SDK and found the below parts inside u-boot/arch/arm/mach-rockchip/rk3506/rk3506.c

Code: Select all

//inside int arch_cpu_init(void)

/*
	 * Set mcu jtag clock un-gate.
	 * Configure when in use.
	 */
	//writel(0x00220000, 0xff960000);

Once I uncommented writel(0x00220000, 0xff960000); this line, rebuild the SDK and flash the updated firmware, now M0 core is accessible through JTAG debugger.

Again, I couldn't find any details about the register 0xff960000, except the fact that it is called SGRF_PMU.

Anyway there are two ways to access SWD pins of M0 core.

1. If you want to use UART0 pins as SWD pins, then run the below register write codes as you did before.

Code: Select all

devmem 0xFF288000 w 0x00300020		//sgrf_jtag_sel (port M1 to MCU)
devmem 0xFF950014 w 0x33002200		//change UART0 pins to JTAG_M1 pins

2. Or, if you want to keep UART0 and would like extra pins for M0 core debugging, you can use micro-SD breakout board (something like below image).

Then connect
SDMMC_D2(GPIO3_A4) to TCK, and
SDMMC_D3(GPIO3_A5) to TMS

Now run below register write codes

Code: Select all

devmem 0xFF288000 w 0x00300010		//sgrf_jtag_sel (port M0 to MCU)
devmem 0xFF4D8064 w 0x00330022		//change micro SD pins to JTAG_M0 pins

I tested it on Ubuntu22.04 JLinkExe

Code: Select all

yjkimmy:~$ JLinkExe 
SEGGER J-Link Commander V8.86 (Compiled Nov 12 2025 12:28:56)
DLL version V8.86, compiled Nov 12 2025 12:27:53

Connecting to J-Link via USB...O.K.
Firmware: J-Link Pro V4 V11 PLUS Oct compiled 1 2024 13:26:26
Hardware version: V11.00
J-Link uptime (since boot): 0d 00h 04m 03s
License(s): FlashBP, GDB, JFlash, FlashDL, RDI
USB speed mode: High speed (480 MBit/s)
IP-Addr: 255.255.255.255 (DHCP)
VTref=3.322V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: CORTEX-M0
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "CORTEX-M0" selected.


Connecting to target via SWD
Found SW-DP with ID 0x0BB11477
DPIDR: 0x0BB11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x04770021, ADDR: 0x00000000)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410CC200. Implementer code: 0x41 (ARM)
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
[0][0]: E000E000 CID B105E00D PID 000BB008 SCS
[0][1]: E0001000 CID B105E00D PID 000BB00A DWT
[0][2]: E0002000 CID B105E00D PID 000BB00B FPB
Memory zones:
  Zone: "Default" Description: Default access mode
Cortex-M0 identified.
J-Link>

Luckfox Forums

Debugging the Cortex-M0 Core with openocd

Debugging the Cortex-M0 Core with openocd

Re: Debugging the Cortex-M0 Core with openocd

Re: Debugging the Cortex-M0 Core with openocd

Re: Debugging the Cortex-M0 Core with openocd

Re: Debugging the Cortex-M0 Core with openocd