Hi,
I am using an i.MX RT1064 controller and debugging/flashing through the PEmicro Multilink interface in MCUXpresso IDE.
Occasionally, I encounter the attached "PEmicro Connection Assistant" error while attempting to connect to the target. The issue appears to occur randomly; I have not identified any specific software activity, code change, or hardware event that consistently triggers it.
What I have observed is that when this error occurs, the controller's boot configuration appears to have changed unexpectedly. In this state, I am unable to flash or debug the device. The only way I have been able to recover is by restoring the boot configuration to its original settings - Internal Flash Mode, after which flashing and debugging work normally again.
A few additional details:
Has anyone encountered a similar issue?
I would appreciate any guidance on:
I've attached a screenshot of the error message for reference.
Thank you.
Hi,
Could you help me with the following questions?
Are you using a custom board or the EVK?
What version of the SDK and IDE are you using?
Have you burned any fuses?
You mentioned that you need to restore the boot configuration to internal flash mode—what boot configuration are you currently using?
Best Regards,
Pablo
I am using a custom board, but this issue was also observed on the EVK.
SDK Version : 26.03.00
IDE Version : 25.6.136
We haven't burned any fuse.
We usually use Internal Boot mode to flash our code and normal operation, but it causes some unexpected issues randomly, so we change it to Serial Download Mode, erase the flash and then change it back to Internal Boot mode before flashing code again.
Please find attached image for boot configuration info.
Hi @Subhasri_S,
The BOOT_MODE register is initialized by sampling the BOOT_MODE0 and BOOT_MODE1 inputs on the rising edge of POR_B. After these inputs are sampled, their subsequent state does not affect the contents of the internal BOOT_MODE register.
If BT_FUSE_SEL = 0, the specific boot configuration parameters can be set using the GPIO pins instead of eFuses.
Could you help me measure the BOOT_MODE and BT_CFG pins during reset when the issue occurs?
Another possible conclusion for this issue is described in the following knowledge base article:
Knowledge Base : RT board recovery for debugger connect issues
"When the flash contains an app that is abnormal(access memory does not exist, memory is corrupted, misconfiguration of the clocks, etc.), it will cause the board to end up in an unknown state, then the debugger can’t take control over the core. But, when put the core in serial downloader mode, then it will put the core in a known state, this way, the debugger will be able to take control of the core.
So, when meeting the debugger issues in the RT board, try to mass erase the external flash in serial download mode, then it will recover the board debugger to a normal situation."
Best Regards,
Pablo