UMI errors in winIDEA

With devices that are supported by UMI, we often encounter UMI-related errors when performing a Download, writing through the Memory Window, or even performing Mass erase.

This topic explains the most common possible solutions and UMI errors, both reported by the monitor (running on the target SoC) and the engine (running in winIDEA), and their possible reasons. Error is displayed in the Progress window.

Possible solutions

Active SBC (watchdog) on your PCB resetting the target

• If yes, investigate how to disable it or put it in TEST/DEBUG mode, so that it does not issue resets while you are trying to debug/program the target.
• If unsure, enable the option Detect watchdog resets via in Hardware / CPU Options / Reset, and enter e.g., 2000ms. Then try to download to the target, and check the Progress window for any warnings indicating watchdog activity. More information via Active Watchdog issues.

Signal integrity issue

• Try to lower the debug clock in Hardware / CPU Option / SoC.
• More information via Signal integrity issue.

Regular RESET method

Try to enable the Regular RESET method via Hardware / CPU Options / Reset.

RAM Initialization

Check settings via Hardware / CPU Options / Reset / RAM Initialization.

Monitor errors

Monitor execution error

Error code: 0x05
This usually indicates that the monitor did not return. The error could occur if e.g. a watchdog could reset the CPU to the reset vector, which prevents the monitor from being executed to completion. In rare cases, an active peripheral (such as DMA) could overwrite a part of the monitor causing it to misbehave.

The data read didn't match the required value

Error code: 0x11
When the read handshake has an unexpected value. It could indicate that the core running the monitor has caching still turned on, or even that some peripheral (such as DMA) is writing to the RAM memory range where the monitor is loaded.

Error loading monitor

Error code: 0x39
The monitor could not be loaded to the intended memory address range. It could indicate uninitialized RAM (for the devices which require initialization before RAM can be used) or memory access failure due to an unstable debug session or perhaps an uninitialized ECC.

FLASH Write operation failed

Error code: 0x41
The monitor could not write to FLASH, possibly due to a configured write protection, or perhaps misconfigured clock frequency/wait states.

FLASH Erase operation failed

Error code: 0x45
The monitor could not erase one or more FLASH sectors, possibly due to a configured write protection, or perhaps misconfigured clock frequency/wait states.

Monitor did not start

Error code: 0x49
The monitor was loaded to the intended memory address, but winIDEA was unable to put the CPU to RUN in order to execute the monitor. Usually indicates issues with the debug session (signal integrity, or an active watchdog that keeps resetting the CPU), since the CPU is controlled by accessing the on-chip debug logic.

UMI engine errors:

Write/Read error!

winIDEA cannot write/read the SoC's RAM, which could indicate an unstable debug session or that SoC is configured in such a way that it does not allow access to RAM.

No applicable monitor available

winIDEA cannot find the monitor to use in this specific memory location or with the specified core. This error might occur when attempting to use SPI (HyperFLASH,...) with a device for which we do not have a suitable monitor or if the specified core is not stopped.

Error loading monitor!

UMI monitor could not be loaded and/or initialized due to memory access failure. This could indicate problems with the debug session, or perhaps an uninitialized ECC. If the error is accompanied by the text Run-mode monitor failed to run! Initialization failed, then winIDEA was unable to put the SoC to "RUN".

UMI Operation timeout!

A read/write/erase operation was started, but a timeout has occurred. The monitor failure could happen due to a crash, but it is also possible that a timeout is set to a too low value for long operations (e.g. mass erase).

Target device is out of device scope!

UMI operation (read/write/erase) cannot be performed since the target address is outside of FLASH's addressable space. It could mean that the download file is linked to a different device (hence the wrong address range) or that the offset is configured incorrectly.

Monitor RAM presence check has failed!

This means that start and/or end of the SoC's RAM cannot be accessed correctly. This can happen due to an unstable debug session or when SoC is configured in such a way that it does not allow RAM access. This could also happen when ECC needs special initialization. Try to set On-chip RAM Initialization to Always in CPU Options.

Operation is not allowed! Check device configuration!

UMI operation was requested, but the operation is not allowed in the current device configuration. For instance, this error would occur if you would enable Program empty cells and Use hashing at the same time, in the UMI configuration dialogue.

Programming not permitted during live session!

Flash modification is permitted only on download. This error would be shown if you enable the option Allow download only in the UMI configuration dialogue, and then tried to modify the FLASH contents through a Memory Window.

More resources:

• Accessing UMI configuration - winIDEA Help