MIMXRT1170-EVKB | MCU-LINK | no code execution

[scalarion]

MIMXRT1170-EVKB | MCU-LINK | no code execution

[Yatekii]

Does the MIMXRT1170-EVKB have the reset line properly connected?

[scalarion]

The reset circuit on the MIMXRT1170-EVKB looks like this:

Among others, TRG_RST can trigger an POR_PIN_RST_B:

However, TRG_RST seems not to be connected to the on-board debug probe which requires JP5 to be OPEN:

Connecting an external J-Link or MCU-Link debug probe to J87 and closing JP5 does not work and brings the error Arm(Dap(NoAcknowledge)):

However, using J-Link with JLinkGDBServer either via on board probe or external probe and the VSCode Cortex-Debug extension seems to reset the the device correctly and allows step debugging from within VSCode connected to the source:

Does probe-rs need the "hard-reset" line POR_PIN_RST_B?

[Yatekii]

Hmm actually, we use a soft reset for the tools you are working with. I had a hunch it might be HW reset.

So it's possible the reset sequence for this target is broken :/

[apparentlymart]

I don't have experience with this particular target, but while I was working on the support for another model in the same series -- starting over in #1642 -- I found that it required some special handling of reset due to some details of how the boot ROM works.

Specifically, the boot ROM runs in a state where halting debug is disabled and so the typical reset catch doesn't work properly. Instead, there's a documented workaround of placing a watchpoint on a particular address which the boot ROM then accesses just before it passes control to the user application. However, my symptom of having this wrong initially was just being unable to halt-before-boot, which you aren't trying to do here, so this particular thing probably isn't your immediate concern.

The other interesting quirk of the i.MX RT5xx series is that they require a carefully-formatted "header" data structure in the boot ROM, which includes some data interleaved into some architectually-reserved fields in the initial vector table and so it's incompatible with the way the cortex-m-rt crate works. However, I see that you are already using imx_rt::entry instead of cortex_m_rt::entry, so hopefully you've already dealt with this part. I'm mentioning it just because my initial attempts failed with similar symptoms as reported here, and the fix was to correct the header to indicate that my code should run in non-secure mode.

The reference manual for this chip is structured completely differently to the one I was referring to and so I wasn't able to confirm whether similar concerns apply here, but hopefully this comment gives some clues for things that might be worth investigating!