Introduction

This training module will teach you how to migrate a graphics application based on MPLAB^_® Harmony v3, and developed for below is a practical, step-by-step migration guide to move a QSPI-based application from the SAME70 Xplained Ultra board (Cortex-M based MCU) to the SAM9X75 Arm^®-based MPU Curiosity Development Board.(ARM9z6EJS based MPU).

It includes the hardware pin-mapping method, software/firmware changes, boot considerations, verification & tuning steps, and a ready-to-use mapping template you can fill with exact pin names from the two user guides.

Refer the SAME70 Xplained Ultra user guide and SAM9X75 Curiosity user guide references while preparing this.

Step 1: Gather required documentation & data

• SAME70 Xplained Ultra User Guide , Identify:

  • The external flash part number and its schematic (Page N
  • The board signal names and mapping to SAME70 MCU pins (schematics section).

• SAM9X75-Curiosity User Guide / board schematic:

  • Find the QSPI interface pins and which connector they are exposed on (board schematics / “connector” section).
  • The target MPU datasheet (SAM9X7 series DS60001813) for QSPI peripheral pinmux & electrical constraints.
• Flash datasheet (SST / Winbond / Micron) used on SAME70 board — for opcodes, timing, page/sector size, quad-enable procedure.

Tip: use the “Hardware / Schematics” sections in both user guides to find the exact net names and the flash part reference (Sx on SAME70 board).

3. Hardware pin mapping (how to do it, and template)

3.1 Identify SAME70 flash signals

Open SAME70 Xplained Ultra PDF → search for “SQI” / “QSPI” / “SST26” / “SQI external Flash” and find schematic fragment showing the flash chip. Note the nets and the MCU pins they connect to. Example SAME70 signals (example names — replace using your schematic):

• FLASH_SCK → connected to SAME70 pin PAXX/SCK
• FLASH_CS0 → connected to SAME70 pin PAXX/NPCS0
• FLASH_IO0 → connected to SAME70 pin PAXX/SPI_MOSI (or IO0)
• FLASH_IO1 → connected to SAME70 pin PAXX/SPI_MISO (or IO1)
• FLASH_IO2 → connected to SAME70 pin PAXX/QSPI_IO2
• FLASH_IO3 → connected to SAME70 pin PAXX/QSPI_IO3
• FLASH_WP → connected to GPIO or tied to Vcc/GND
• FLASH_HOLD → connected to GPIO or Vcc/GND
• VCC/VIO → usually 3.3 V (verify)

3.2 Identify SAM9X75 QSPI pins

Open SAM9X75 Curiosity User Guide (or SAM9X7 datasheet) and find:

• QSPI controller signals (often labelled QSPCK / QSPI_SCK, QCS / NPCS0 , QD0..QD3 or IO0..IO3) and the board net names. Also check whether they are exposed on an expansion header or on the SOM interface.

Typical SAM9X75 QSPI signals (replace with exact names from board guide):

• QSPI_SPCK → (e.g., PAx or QSPCK)
• QSPI_NPCS0 → chip select (NPCS0)
• QSPI_IO0 → IO0 / MOSI
• QSPI_IO1 → IO1 / MISO
• QSPI_IO2 → IO2
• QSPI_IO3 → IO3
• QSPI_CS_POL → (chip select polarity config in controller)
• QSPI_HOLD/WP → optional GPIOs you must route to (or tie)

3.3 Mapping template

Use this template to record actual mapping between the two boards:

4. Electrical checks & wiring

1. Voltage levels — Confirm both boards/flash use the same IO voltage (almost always 3.3 V). If not, add level shifters.
2. Signal integrity — Keep QSPI traces short; minimize stubs. If you are wiring between two dev boards, use short twisted pairs or ribbon cable.
3. Pull-ups / pull-downs — Observe the flash datasheet for WP/HOLD required pull values.
4. Chip select polarity — Most flashes use active-low CS. Ensure SAM9X75 NPCS0 polarity matches (controller can often configure polarity).
5. Drive capability — Ensure the MPU GPIO alternate function can drive the flash at target frequency.

5. Software migration: peripheral & driver differences

5.1 Low-level peripheral differences

• SAME70 typically uses the QSPI/SQI peripheral with Atmel START/HAL APIs or Harmony drivers.
• SAM9X75 provides a QSPI (or SMC/SPI) peripheral accessible via Linux BSP driver (if running Linux) or baremetal drivers in Harmony/SDK. The register layout and init sequence differ.

5.2 If you are porting a bare-metal firmware (no OS)

• Implement/replace the HAL init: enable peripheral clock, configure pinmux/PIO for QSPI, set QSPI clock divisor, configure mode (CPOL/CPHA), data width, and DMA if used.

• Map your SAME70 HAL calls to SAM9X75 driver calls or re-implement:

  • qspi_init(...) → set up Master/Peripheral registers
  • qspi_write() / qspi_read() → manage DMA or polling
  • qspi_transfer_cmd() → send opcodes + address + dummy cycles
• Pay attention to cache: SAM9X75 is an MPU with caches — when reading code executed from QSPI or reading/writing memory mapped QSPI flash, ensure proper cache invalidation / write-back sequences.

5.3 If you are running Linux (typical on SAM9X75)

• Use the Linux SPI/QSPI flash MTD subsystem or the mtd/mtdchar drivers and the sf (spi-nor) driver. You’ll likely enable the QSPI controller in the Device Tree and declare the flash part with compatible string (e.g., jedec,spi-nor or exact vendor part).

• Steps:

  1. Enable QSPI controller driver in kernel config.
  2. Add Device Tree nodes: qspi@... with pinctrl, cs-gpios, spi-max-frequency, and child node for the flash with compatible = "jedec,spi-nor" and spi-max-frequency.
  3. Test with flashrom/mtd utilities, cat /proc/mtd.
• If you used SAM-BA or U-Boot on SAME70 for programming the flash, you need corresponding U-Boot config for SAM9X75 QSPI. U-Boot on SAM9X75 often supports sf probe, sf read, sf write if QSPI is enabled.

6. Flash-specific behavior & commands

• Confirm flash opcodes (Read, Fast Read, Quad Read, Page Program, Sector Erase, Bulk Erase, Read Status, Write Enable).
• Quad-Enable: Some flashes require a status/config write to turn on quad IO. Ensure your SAM9X75 driver sets QE bit if needed.
• Addressing mode: For >16 MB flashes you may need 4-byte addressing; adapt commands accordingly.
• Dummy cycles: Quad mode often requires additional dummy cycles on reads — ensure the controller dummy-cycle configuration matches the flash datasheet.
• Erase sizes: sector/block/page sizes determine your erase/program algorithm.

7. Boot / execution from QSPI (if applicable)

If you need to boot directly from QSPI on SAM9X75:

• Check SAM9X75 boot ROM/bootloader capability: does the boot ROM support QSPI/SPI boot? (Check SAM9X75 datasheet/boot sequence in the user guide).

• If SAM9X75’s primary boot supports QSPI, ensure:

  • QSPI pins are available at reset (not remapped).
  • Flash is connected to boot-capable QSPI controller (some MCUs have multiple SPI/QSPI controllers and only some are used in boot ROM).
  • The flash contents are formatted for the bootloader (image format, headers).
• Often easier: use SPL/U-Boot on NAND/SD/eMMC or boot from serial with SAM-BA and then load from QSPI.

8. Step-by-step migration checklist

Hardware

1. Record SAME70 flash part and pin nets.
2. Open SAM9X75 Curiosity schematic and find QSPI pins.
3. Fill the mapping table (see template).
4. Physically connect wires or modify PCB connector; ensure 3.3 V compatibility.
5. Tie WP/HOLD appropriately or connect to GPIOs.

Software

1. Create or adapt QSPI init on SAM9X75:

   • Enable controller clock, set pinmux, set mode, set clock divider.
2. Implement low-level transfer code (polling or DMA).
3. Implement flash command sequences (Read, Quad Read, Page Program, Erase).
4. Test simple read of flash ID (JEDEC ID) and compare to flash datasheet (this validates wiring & mode).
5. Enable quad mode (if desired) and test quad read.
6. Test program/erase on a small test sector and verify contents.
7. If using Linux/U-Boot: update Device Tree and enable drivers; test with sf probe, flashcp, nandwrite as applicable.
8. If booting from QSPI, update bootloader image & test cold boot.

9. Debugging & verification tips

• Read JEDEC ID first: opcode 9F returns manufacturer & capacity; if this works, wiring/pinmux is correct.
• Scope or logic analyzer: capture SCK and IO lines at the flash to verify the controller toggles the correct pins and opcodes.
• Slow down clock during bring-up (start at e.g., 1–4 MHz) to avoid signal integrity issues.
• Check controller remapping: ensure the SAM9X75 pinmux actually assigns those pins to QSPI peripheral.
• Cache management: if mapping flash into XIP space, ensure you configure memory region as non-cacheable or use proper cache maintenance when writing to flash.
• Voltage / grounding: ensure common ground when wiring two boards.

10. Performance tuning

• After functional bring-up, increase QSPI clock to target frequency and confirm signal integrity.
• Tune dummy cycles to match flash timing (some controllers allow setting dummy cycles).
• Use DMA for large transfers for better throughput.
• If executing code in place (XIP), ensure flash latency settings are correct.

11. What I did not assume & what I can provide next

• I did not hard-code exact SAM9X75 pin names (because exact net names come from the Curiosity schematic and may differ by board revision).
• I can extract the exact pin names and produce a completed mapping table if you want — I can fetch the SAM9X75 Curiosity user guide/schematic and the SAME70 schematic and fill the mapping for you.

If you want that, I can:

• Pull the SAME70 Xplained Ultra schematic page that shows the SQI flash nets and give the exact SAME70 pin names.
• Pull the SAM9X75 Curiosity schematic page that shows the QSPI signals and give the exact SAM9X75 pin names.
• Produce a completed one-to-one mapping plus a wiring diagram and sample initialization code for bare-metal or for Device Tree snippet for Linux.

Quick checklist to proceed now

1. Confirm the flash part number on your SAME70 board (or paste the relevant schematic snippet).
2. Confirm whether you will run bare-metal code on SAM9X75 or Linux/U-Boot.
3. Tell me whether you need a Device Tree node or bare-metal driver sample.

Reply with any of the above and I’ll produce the exact pin mapping and code snippets for your chosen environment.

Summary

In this training, an automotive dashboard application of the PIC32MZDA-Curiosity Development Kit was migrated to the SAM9X75 Curiosity Development Board using MGS under MPLAB X IDE.

Back to Top

Learn More

• Hybrid MCUs Introduction
• Key Considerations When Migrating From MCUs to Hybrid MCUs
• Migrating a Graphics Application from a PIC32MZDA MCU to a SAM9X60 Hybrid MCU Curiosity Development Board
• Getting Started with Graphics on SAM9X60 Curiosity Development Board
• 32-bit Microprocessor (MPU) Evaluation Kits and Development Boards

Back to Top