NXP X-S32Z27X-DC (DC2)
Overview
The X-S32Z27X-DC (DC2) board is based on the NXP S32Z270 Real-Time Processor, which includes two Real-Time Units (RTU) composed of four ARM Cortex-R52 cores each, with flexible split/lock configurations.
There is one Zephyr board per RTU:
s32z270dc2_rtu0_r52, for RTU0s32z270dc2_rtu1_r52, for RTU1.
Hardware
Information about the hardware and design resources can be found at NXP S32Z2 Real-Time Processors website 1.
Supported Features
The boards support the following hardware features:
Interface |
Controller |
Driver/Component |
|---|---|---|
GIC |
on-chip |
interrupt_controller |
ARM Timer |
on-chip |
timer |
SIUL2 |
on-chip |
pinctrl gpio |
LINFlexD |
on-chip |
serial |
Other hardware features are not currently supported by the port.
Connections and IOs
The SoC’s pads are grouped into ports and pins for consistency with GPIO driver and the HAL drivers used by this Zephyr port. The following table summarizes the mapping between pads and ports/pins. This must be taken into account when using GPIO driver or configuring the pinmuxing for the device drivers.
Pads |
Port/Pins |
|---|---|
PAD_000 - PAD_015 |
PA0 - PA15 |
PAD_016 - PAD_030 |
PB0 - PB14 |
PAD_031 |
PC15 |
PAD_032 - PAD_047 |
PD0 - PD15 |
PAD_048 - PAD_063 |
PE0 - PE15 |
PAD_064 - PAD_079 |
PF0 - PF15 |
PAD_080 - PAD_091 |
PG0 - PG11 |
PAD_092 - PAD_095 |
PH12 - PH15 |
PAD_096 - PAD_111 |
PI0 - PI15 |
PAD_112 - PAD_127 |
PJ0 - PJ15 |
PAD_128 - PAD_143 |
PK0 - PK15 |
PAD_144 - PAD_145 |
PL0 - PL1 |
PAD_146 - PAD_159 |
PM2 - PM15 |
PAD_160 - PAD_169 |
PN0 - PN9 |
PAD_170 - PAD_173 |
PO10 - PO13 |
This board does not include user LED’s or switches, which are needed for some of the samples such as Blinky or Button. Follow the steps described in the sample description to enable support for this board.
System Clock
The Cortex-R52 cores are configured to run at 800 MHz.
Serial Port
The SoC has 12 LINFlexD instances that can be used in UART mode. Instance 0
(defined as uart0 in devicetree) is configured for the console and the
remaining are disabled and not configured.
Programming and Debugging
Applications for the s32z270dc2_rtu0_r52 and s32z270dc2_rtu1_r52 boards
can be built in the usual way as documented in Building an Application.
Currently is only possible to load and execute a Zephyr application binary on this board from the internal SRAM, using Lauterbach TRACE32 2 development tools and debuggers.
Note
Currently, the start-up scripts executed with west flash and
west debug commands perform the same steps to initialize the SoC and
load the application to SRAM. The difference is that west flash hide the
Lauterbach TRACE32 interface, executes the application and exits.
Install Lauterbach TRACE32 Software
Follow the steps described in Lauterbach TRACE32 Debug Host Tools to install and set-up Lauterbach TRACE32 software.
Set-up the Board
Connect the Lauterbach TRACE32 debugger to the board’s JTAG connector (J134)
and to the host computer.
For visualizing the serial output, connect the board’s USB/UART port (J119) to
the host computer and run your favorite terminal program to listen for output.
For example, using the cross-platform pySerial miniterm 3 terminal:
python -m serial.tools.miniterm <port> 115200
Replace <port> with the port where the board can be found. For example,
under Linux, /dev/ttyUSB0.
Flashing
For example, you can build and run the Hello World sample for the board
s32z270dc2_rtu0_r52 with:
# From the root of the zephyr repository
west build -b s32z270dc2_rtu0_r52 samples/hello_world
west flash
You should see the following message in the terminal:
Hello World! s32z270dc2_rtu0_r52
Debugging
To enable debugging using Lauterbach TRACE32 software, run instead:
# From the root of the zephyr repository
west build -b s32z270dc2_rtu0_r52 samples/hello_world
west debug
Step through the application in your debugger, and you should see the following message in the terminal:
Hello World! s32z270dc2_rtu0_r52
RTU and Core Configuration
This Zephyr port can only run single core in any of the Cortex-R52 cores, either in lock-step or split-lock mode. By default, Zephyr runs on the first core of the RTU chosen and in lock-step mode (which is the reset configuration).
To build for split-lock mode, the CONFIG_DCLS must be
disabled from your application Kconfig file.
Additionally, to run in a different core or with a different core configuration than the default, extra parameters must be provided to the runner as follows:
west <command> --startup-args elfFile=<elf_path> rtu=<rtu_id> \
core=<core_id> lockstep=<yes/no>
Where:
<command>isflashordebug<elf_path>is the path to the Zephyr application ELF in the output directory<rtu_id>is the zero-based RTU index (0 fors32z270dc2_rtu0_r52and 1 fors32z270dc2_rtu1_r52)<core_id>is the zero-based core index relative to the RTU on which to run the Zephyr application (0, 1, 2 or 3)<yes/no>can beyesto run in lock-step, ornoto run in split-lock.
For example, to build the Hello World sample for the board
s32z270dc2_rtu0_r52 with split-lock core configuration:
# From the root of the zephyr repository
west build -b s32z270dc2_rtu0_r52 samples/hello_world -- -DCONFIG_DCLS=n
To execute this sample in the second core of RTU0 in split-lock mode:
west flash --startup-args elfFile=build/zephyr/zephyr.elf \
rtu=0 core=1 lockstep=no