[ABANDONED] Execute iMXRT1020 bootrom when debugging?

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] Execute iMXRT1020 bootrom when debugging?

    Hi

    I'm starting development on an iMXRT1020. The iMXRT1020 allows putting configuration tables in external spi flash so that the bootrom can configure the spi flash for optimal speed, as well as configuration settings for sdram, etc. However, it seems that the debugger (I'm using JTrace-Pro) skips executing the bootrom, thus the spi flash is not set up for optimal execution (XIP runs at low single data line spi speed rather than fast qspi that that should be configured during bootrom), and the sdram doesn't work.

    I tried setting the reset to type 4 (reset core & peripherals, halt after bootloader) but this didn't seem to make a difference.

    I've been able to work around it for now by using the debugger to program the flash, then everything, and then connecting to running target. However, this isn't ideal.

    Any suggestions? Thanks.
    -Kevin
  • Adding a couple updates.

    Now I see that sometimes a debug session will run as quad spi, and other times as single spi. I can see on the logic analyzer that the jlink programs the spi flash in single spi, verifies it, then prior to entering Reset_Handler() (XIP in spi flash) it reads the spi flash as quad. Other times doing the same thing it reads it as single. I haven't figured out a pattern to it, although rebuilding with a very minor change sometimes causes it to occur or not occur. The code changes aren't even executing; that is, I'm infinite while looping on a true variable at the entry to Reset_Handler() so that I can pause and/or attach the debugger at entry.

    Additionally, I've noticed that jlink will very often erase and reprogram the spi flash on each debug session, even though no changes were made. Again, looking at the logic analyzer the first spi flash read, 4 bytes at address 0, will often be FF, even though there's data at that address (the spi flash boot config table). It looks like something is driving the DI line high for that 1st read. This occurs on NXP's EVK dev board (ISSI spi flash) and on our custom board (Winbond spi flash).
  • Update to "jlink will very often erase and reprogram" unchanged code: I think I see what's happening. We're configuring the FlexSPI interface to use the spi flash in fast read quad i/o operation with continuous read (AX mode). This means that the mcu's first time reading the spi flash with fast read quad i/o, the message starts with command 0xEB, but every fast read quad i/o after that just starts with the address (no 0xEB). Thus, when the debugger resets the mcu, the spi flash is not reset but left thinking that the next message it receives will start with an address in quad i/o mode. The debugger's 1st request to the spi flash (command 0x03 in single spi mode) is to read the 1st address for memory comparison. Thus the spi flash returns junk since it is in the wrong mode for that 1st transaction, but then is ok after that.

    Maybe NXP_IMXRT102x_QSPI.elf should consider doing a dummy read, or check vendor ids a couple times, or something similar, for the 1st transaction(s) to put the spi flash into a known state?