Skip to main content
Start with a controlled first-success path so you can confirm the platform, image, and debug setup before expanding into interface or power validation. You establish the minimum working baseline, verify that the MCU can run a known-good image, and use one simple path to confirm expected behavior. This helps you isolate setup issues early and avoid debugging advanced flows before the basic bring-up path is stable.
  1. Confirm the target board is powered, clocked, and debuggable.
  2. Load the default MCU image and verify execution from DDR.
  3. Validate timer, GPIO wake, and serial-engine interrupt routing.
  4. Bring up one basic path, such as UART logging or an I2C register read.
  5. Only after the basic path works, enable GPI or deeper power-state testing.
2.1 Prerequisites â–  CQ2390/IQ2390/CQ2390/IQ2390S with required clocks, the CX power domain, and DDR access available.
â–  A delivered BSP or Zephyr-compatible MCU software package. â–  Early debug visibility so boot hangs, timeouts, and power-transition failures are visible. â–  At least one known-good path: UART loopback or console output, or an I2C device register path. â–  The authoritative TRM, security collateral, release notes, and image packaging notes. 2.2 Build and run your first MCU application Build the MCU image with the delivered Zephyr-compatible flow, load it from the application processor, and validate one basic interface path. Prerequisites â– Use the delivered CQ2390/IQ2390/CQ2390/IQ2390S MCU board configuration and project configuration files. â–  Pick a first-success path: UART logging or an I2C register read. â–  Keep logging enabled and preserve symbol and map files. Procedure
  1. Select the CQ2390/IQ2390/CQ2390/IQ2390S MCU board or SoC configuration that matches the delivered package.
  2. Apply project settings for logging, console, serial support, I2C support, DMA or GPI enablement, and memory placement as needed.
  3. Build the image and generate the ELF file, map file, and packaged MCU image.
  4. Load the packaged image from the application processor, program the reset vector as required, and start the MCU.
  5. Check that the MCU executes from DDR and that your chosen first path shows clear signs of life
Expected result. The MCU reaches first instruction fetch, starts the runtime, and produces repeatable UART output or a stable register read. NOTE: If final command lines or board names are not yet public, pull them from the release note and delivered BSP instead of adding placeholders to the published guide. 2.3 Common setup issues â–  Missing clocks or an unavailable CX rail blocks bring-up early. â–  Interrupts are enabled in software but not routed correctly at the platform level. â–  DDR access is not stable enough for predictable image execution. â–  GPI is enabled before the simpler programmed-I/O or interrupt path is validated. â–  Symbol files and logs are not preserved, which slows fault triage later.