Skip to content

Add custom i.MX95 support for Cortex-M cores and Macronix MX25UM flash - #1899

Open
PetervdPerk-NXP wants to merge 4 commits into
pyocd:mainfrom
NXP-Robotics:pr-imx95
Open

PetervdPerk-NXP wants to merge 4 commits into
pyocd:mainfrom
NXP-Robotics:pr-imx95

Conversation

@PetervdPerk-NXP

Copy link
Copy Markdown
Contributor
  • Implement target support for NXP i.MX95 SoC (Cortex-M cores only):
    • Cortex-M33
    • Cortex-M7
  • Add custom reset sequence for Cortex-M7
  • Add flash algorithm for Macronix MX25UM series
  • Update board configuration and memory map for i.MX95

- Implement target support for NXP i.MX95 SoC (Cortex-M cores only):
  * Cortex-M33
  * Cortex-M7
- Add custom reset sequence for Cortex-M7
- Add flash algorithm for Macronix MX25UM series
- Update board configuration and memory map for i.MX95

Signed-off-by: Peter van der Perk <peter.vanderperk@nxp.com>
To hold M7 core we need a safe loop in the vtor so it won't run of.
Before we can halt it to run the flash algorithms.

Also increase the page transfer size to improve transfer speed.
The CM7 targets now work next to a running System Manager on the M33. Every
reset path stays on the CM7 side: connect no longer reconfigures the M33 debug
blocks or the slice reset, every reset type except SYSRESETREQ is a core-only
restart that sets VTOR, SP and PC from the application vector table, restores
FPCCR and clears the fault status, and connect waits for the core to leave reset
and keeps the first DHCSR read so a script can see that the core was reset.

A CM7 that the System Manager keeps resetting after a lockup is parked by a loop
written over its boot vector, using the lockup state the reset wait observed and
a fresh AP2 CSW on every try, so a later restart can start the application.
Before a restart the CM7's own eDMA channels are quiesced; the channel set is
found from the System Manager's access control by probing which channel pages
the CM7 port can read.

The flash algorithm programs in 16 KB pages with the CRC analyzer, so a confirm
flash with --trust-crc skips unchanged pages without reading them over the
probe, each sector is erased while its data downloads, and the controller is put
back into its read setup after the builder's uninit so the application restarts
on a working AHB read path. The chip erase entry is dropped because the blob's
chip erase is a plain-SPI command that never waits.

The CM33 flash target runs the CM7 algorithm with the MPU off, keeps WDOG2 fed
on every call and holds the CM7 for the duration, and ends in a chip reset. The
CM33 code and system TCM sit at their real addresses, and the CM33 is resumed
with its debug control cleared on disconnect. Unit tests run without a probe
attached; the README says how, because the semihosting test opens the first
probe it finds.
Flash.init only halts the core before prepare_target, so a gdb load programs
the NOR under a core that was running the previous image with its caches,
NVIC, SysTick and eDMA live, and the new image then starts through stale
cache lines. pyocd flash avoided this only because load_cmd resets first.
Restart the core in prepare_target so every programming path starts from
the same state.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants