Hi - I've been debugging on an iMXRT1020, using the FlexSPI/spi NOR flash for XIP code. As part of the first steps in debugging the code the JTrace programs the spi flash (and verifies it). This had been working well until today. I'm not sure what I did to break it, but I did, and then figured out a work-around, and thought I should bring it to your attention in case it is a bug in NXP_IMXRT102x_QSPI.elf.
At some point I must've debugged with "bad" code; that is, the debugger programmed the spi flash but then wasn't able to debug or program after that. I don't remember the exact error message but it was something like "PC of target system has unexpected value!".
Using a logic analyzer, I could see that the iMXRT boot rom was reading the spi flash in both single spi and quad spi mode, and receiving what I knew was valid data. When attempting to connect with the debugger though I could see that CS, CLK, and MOSI (D0) were toggling, but MISO (D1) was not - it was always pulled low.
I was able to recover debugging by using gpio pins to force the mcu to boot in "serial downloader" mode then attempt to debug. That worked - the debugger was able to reprogram the spi flash and hit a breakpoint.
So, is NXP_IMXRT102x_QSPI.elf possibly not initializing the ALT modes/functions of the FlexSPI pins, or something similar?
Thanks
-Kevin
At some point I must've debugged with "bad" code; that is, the debugger programmed the spi flash but then wasn't able to debug or program after that. I don't remember the exact error message but it was something like "PC of target system has unexpected value!".
Using a logic analyzer, I could see that the iMXRT boot rom was reading the spi flash in both single spi and quad spi mode, and receiving what I knew was valid data. When attempting to connect with the debugger though I could see that CS, CLK, and MOSI (D0) were toggling, but MISO (D1) was not - it was always pulled low.
I was able to recover debugging by using gpio pins to force the mcu to boot in "serial downloader" mode then attempt to debug. That worked - the debugger was able to reprogram the spi flash and hit a breakpoint.
So, is NXP_IMXRT102x_QSPI.elf possibly not initializing the ALT modes/functions of the FlexSPI pins, or something similar?
Thanks
-Kevin