Renesas RZ/N2H: Difference between revisions

From SEGGER Knowledge Base
Jump to navigation Jump to search
(Created page with "__TOC__ The RZ/N2H is an high-performance multi-function MPU featuring two Cortex-R52 cores. == QSPI Flash Programming Support == QSPI flash programming requires special handling compared to internal flash. For more information about this, please see the QSPI Flash Programming Support article.<br> J-Link supports XSPI0 and XSPI1 for RZ/N2H for Cortex-R52 and Cortex-A55 cores. {| class="seggertable" |- ! Flash Bank || Base address !!...")
 
No edit summary
 
(One intermediate revision by one other user not shown)
Line 149: Line 149:


==Evaluation Boards==
==Evaluation Boards==
*Renesas RZ/N2H-RSK: https://wiki.segger.com/Renesas_RZ/N2H-RSK
*[[Renesas_RZ/N2H-RSK | Renesas RZ/N2H-RSK]]
 
==Example Application==
*Renesas RZ/N2H-RSK: https://wiki.segger.com/Renesas_RZ/N2H-RSK#Example_Project

Latest revision as of 09:42, 6 February 2025

The RZ/N2H is an high-performance multi-function MPU featuring two Cortex-R52 cores.

QSPI Flash Programming Support

QSPI flash programming requires special handling compared to internal flash. For more information about this, please see the QSPI Flash Programming Support article.
J-Link supports XSPI0 and XSPI1 for RZ/N2H for Cortex-R52 and Cortex-A55 cores.

Flash Bank Base address Size J-Link Support
External QSPI (XSPI0) 0x40000000 Up to 256 MB YES.png
External QSPI (XSPI1) 0x50000000 Up to 256 MB YES.png

The pin configuration is the following:

Flash loader CS CLK IO0 IO1 IO2 IO3 IO4 IO5 IO6 IO7
XSPI0 P05_3 P05_1 P05_6 P05_7 P06_0 P06_1 P06_2 P06_3 P06_4 P06_5
XSPI1 P01_1 P01_0 P01_4 P01_5 P01_6 P01_7 P02_0 P02_1 P02_2 P02_3

Multi-Core Support

Before proceeding with this article, please check out the generic article regarding Multi-Core debugging here.
The RZ/N2H family comes with a a variety of multi-core options (two Cortex-R52 cores and up to four Cortex-A55 cores)
In below, the debug related multi-core behavior of the J-Link is described for each core:

Cortex-R52_0 (main core)

Init/Setup

  • Enables debugging

Reset

  • Device specific reset is performed:
  1. Make sure that the device halts immediately after reset (before it can execute any instruction of the user application) by setting EDECR.RCE == 1
  2. Reset the core and peripherals by toggling the reset pin
  3. Pass through the RZ/N2H Authentication process if necessary
  4. Power core if necessary
  5. Enable debug mode if necessary
  6. Clear the reset catch bit (EDECR.RCE == 0)

Attach

  • Attach is supported

Cortex-R52_1

Init/Setup

  • If the core is not enabled yet, it will be enabled / released from reset
  • If the core is already enabled, a simple attach will be performed

Reset

No reset is performed.

Attach

  • Attach is supported / desired

Cortex-A55_0

Init/Setup

  • If the core is not enabled yet, it will be enabled / released from reset
  • If the core is already enabled, a simple attach will be performed

Reset

No reset is performed.

Attach

  • Attach is supported / desired

Cortex-A55_1

Init/Setup

  • If the core is not enabled yet, it will be enabled / released from reset
  • If the core is already enabled, a simple attach will be performed

Reset

No reset is performed.

Attach

  • Attach is supported / desired

Cortex-A55_2

Init/Setup

  • If the core is not enabled yet, it will be enabled / released from reset
  • If the core is already enabled, a simple attach will be performed

Reset

No reset is performed.

Attach

  • Attach is supported / desired

Cortex-A55_3

Init/Setup

  • If the core is not enabled yet, it will be enabled / released from reset
  • If the core is already enabled, a simple attach will be performed

Reset

No reset is performed.

Attach

  • Attach is supported / desired

Reset

A device specific reset is performed for the main core (R52_0) only. The reset contains the following steps:

  1. Make sure that the device halts immediately after reset (before it can execute any instruction of the user application) by setting EDECR.RCE == 1
  2. Reset the core and peripherals by toggling the reset pin
  3. Pass through the RZ/N2H Authentication process if necessary
  4. Power core if necessary
  5. Enable debug mode if necessary
  6. Clear the reset catch bit (EDECR.RCE == 0)

Debug Authentication

TBD

RTT

J-Link uses the AXI-AP of the device for RTT accesses.

  • Supported since V7.92d of the J-Link software version, when selecting a RZ/N2H device.
  • RTT control block and buffers must be placed in a memory that is accessible via AXI-AP.
  • ATCM and BTCM are not suitable because they are not accessible via AXI-AP.
  • AXI-AP bypasses the cache of the CPU, so RTT control block and buffers need to be in a non-cached memory area.
  • RTT auto-detection: By default, J-Link scans the first 32 KB of the system RAM @ 0x1000_0000 for a RTT control block.
  • Regarding cache etc., the RTT Cortex-R specifics apply.

HSS

J-Link uses the AXI-AP of the device for HSS accesses.

  • Supported since V7.86c of the J-Link software version, when selecting a RZ/N2H device.
  • Variables to monitor must be placed in a memory that is accessible via AXI-AP.
  • ATCM and BTCM are not suitable because they are not accessible via AXI-AP.
  • AXI-AP bypasses the cache of the CPU, so variables need to be in a non-cached memory area. (Otherwise only sporadic or no updates will be seen at all)

Zoned memory access

Supported since V7.92d of the J-Link software version, when selecting a RZ/N2H device.
For more information about what zoned memory accesses are: Dedicated wiki article
The following zones are available for these devices:

Zone Description
Default Default memory view (memory is accessed through the core)
AP0 APB-AP. Not usable for the user
AP1 APB-AP view that connects to the debug registers and other CoreSight components. Not usable for the user
AP2 AXI-AP. Allows DMA-like access (bypasses MMU/MPU/caches) to system memory and most peripheral registers

Evaluation Boards