MCUXpresso SPT - de-brick custom board using UART

[bp1979]

Dear NXP,

I am having a hard time to find decent documentation on how to fix bricked IMX boards. It surprises me, because it seems to be a situation which occurs a lot.

I have once had the same issue with my EVKs ("bricked" 8 of them in a few months, by uploading faulty programs). And I have learned a (undocumented?) trick to revive the board using the MCU Secure Provisioning tool, and then in particular the Flash Programmer.

Now we have 3 bricked custom boards (again, caused by a silly mistake in our linker script), but nonetheless, the boards are wasted. Fully produced, quite a waste of money.

So I am spending days already to find a way to revive the boards, but all attempts in vain. It's rather frustrating, and I hope you can help me clear documentation, or some step by step guidance.

What works:

- start CPU in serial download (using a jumper on custom board)

- connect through JLink SWD

- use MCUxpresso to run blinky (linked to SRAM)

What doesn't work:

(pretty much, everything else, e.g)
- unable to connect to CPU when CPU tries to start from flash

- unable to mass erase flash from JLink

- unable to mass erase flash from MCUXpresso GUI flash tool

- unable to run nor-flash app SDK example (linked to SRAM)

- unable to connect SPT through UART

What I am trying to achieve:

- Use the Flash programmer in Secure Provisioning tool to do "something magical" to debrick the board.

- I am practicing on one of many EVKs: all imx rt 1024s first, but I can't even get this to work.

- I connected my FTDI USB to uart chip from PC to EVK (COM8, to UART1 on EVK (IOMUXC_GPIO_AD_B0_06_LPUART1_TX, IOMUXC_GPIO_AD_B0_07_LPUART1_RX)

- Set bootswitches to b0001 to end up in Serial Download

- Verified that CPU is in Serial Download by connecting to EVK using JLink (connect, halt)
J-Link>halt
PC = 0020B9B4

- Start secure provisioning tool (configured for imx rt1024)

- Press the "USB" button, where I can choose UART

- Fill in COM8 (connected to my FTDI chip)

- Leave baud rate to 115200 (which is the only option in the tool)

- Press "test connection" button, and after some dialog appears briefly I get the following warning:

WARNING: SDPHOST connection failed with: SDPHOST connection failed with an exception: SDP: Connection issue -> Timeout Error

And that was that.

My questions:

1) Let's begin with the reason why we end up in this situation. Can you PLEASE explain clearly what happens inside the chip? In flash? So we upload an app which "bricks" the chip. But using the provisioning tool, we can "debrick" it. What EXACTLY happens when we use the Flash programmer? Because if it ONLY did something on flash, why doesn't a mass erase solve the problem? Does that mean, something INSIDE the MCU changed, which is persistent? What is it? This is a very frustrating part, we have simply no clue what goes wrong. It feels very uncomfortable to sell a product with this chip if we have no clue what exactly happens which results in a CPU which no longer can run a program from flash. Only run a program from SRAM. We would appreciate it a LOT if you can shed a light on this mystery.

2) Since we have three rather expensive boards "bricked", we really need a way to get them back alive. We have done the same with EVK boards, where SPT was successful, but on EVK we can use USB OTG, we don't have that on the custom board. So we need to know how this works with UART. We've read the reference manual, but that doesn't explain much, other than we need UART1. Well, we connected UART1, it  doesn't work.

3) Reading related topics on this forum, I see that some client programs require CTS/RTS. I can't find any documentation on SDT regarding this. Does it also require CTS/RTS?

4) IF there is some application note which explains all the above with clarity, please refer me to the official docs.

I hope you can help.

For reference, the error when we try to connect to our custom (bricked?) board:

NOTE: I am still able to connect to the CPU when I force the CPU on the custom board in serial download mode!! So I don't think the CPU is really broken, there is just "something" wrong "somewhere" and we are dying to learn more...

Connecting to J-Link via USB...O.K.
Firmware: J-Link V11 compiled Aug 2 2023 10:34:01
Hardware version: V11.00
J-Link uptime (since boot): 0d 05h 57m 49s
S/N: 601011684
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: High speed (480 MBit/s)
VTref=3.322V

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: MIMXRT1024XXX5A
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
S) SWD
T) cJTAG
TIF>s
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "MIMXRT1024XXX5A" selected.

Connecting to target via SWD
Found SW-DP with ID 0x0BD11477
DPIDR: 0x0BD11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x0BD11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Could not find core in Coresight setup
Found SW-DP with ID 0x0BD11477
DPIDR: 0x0BD11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Attach to CPU failed. Executing connect under reset.
DPIDR: 0x0BD11477
CoreSight SoC-400 or earlier
Scanning AP map to find all available APs
AP[0]: Stopped AP scan as end of AP map seems to be reached
Iterating through AP map to find AHB-AP to use
Could not find core in Coresight setup
Cannot connect to target.

[tbonkers]

is there a way to confirm if the code you're uploading is valid in the sense that it will not brick the device? I have the same thing happen to me multiple times using Zephyr to program MIMXRT1042.

[Kan_Li]

Hi @bp1979 ,

Is it possible to connect the MCU via Jlink after you set it to serial download mode? Can you perform mass erase then? Please kindly clarify. You may refer to https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-board-recovery-for-debugger-connect-issues/ta... for more details on this topic.

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

@Kan_LiThat DOES help, quite a lot to be fair.

We were afraid that we had to do "more" than just mass erase flash from serial download. But it's really that simple..... Board is alive. Thanks! And great article Kerry Zou, dates from april this year. Consider it bookmarked :).

One more question though, could you please detail how on earth we are supposed to get something useful going in serial download mode over UART1? We might not need it now, but I really would like to understand why the SPT is not able to our board using the UART port.

I also tried the exact same on an EVK (which is easier to setup in my case). But there SPT refuses to connect with UART1 on EVK 1024. I am pretty sure I wired it up correctly, but SPT stops on a timeout.

Are you able to connect SPT to any EVK 10xx and show me how? (Preferably a imx 1020 or imx 1024 since I have those myself)

Thanks again, life saver! hope to learn more on that SPT <=> UART1 / EVK trick

[Kan_Li]

Hi @bp1979 ,

Please check the connection between SPT and EVK, not only UART signals, but also the GND signal should be shared between each other.

Alternatively you may use the tool from https://github.com/JayHeng/NXP-MCUBootUtility/releases/tag/v5.3.0 and please kindly refer to https://github.com/JayHeng/NXP-MCUBootUtility for more details.

Hope that helps,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

Hi @Kan_Li 

for the UART signals,

can you confirm, I only need:

- UART1 RX

- UART1 TX

- GND

With these signals properly wired from FTDI converter to device, I should be able to connect with the device in SD mode, from SPT using the COM connected to the FTDI device?

[Kan_Li]

Hi @bp1979 ,

Yes, I am referring to a USB to RS232 TTL UART converter such as FTDI converter, which has RX,TX and GND to be connected with the board in SD mode.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

@Kan_Li 

We again have the same broken situation.

Two "bricked" custom boards.

We can get into SD mode.

We can mass erase flash.

Powering cycle to normal boot mode, and we no longer able to control the CPU.

We repeated the exact steps as previous time.

Here the output of JLinkExe

In serial download mode

J-Link>halt
PC = 00215DBA, CycleCnt = 9155DB5C
R0 = 00000000, R1 = 00215DA9, R2 = 00000001, R3 = 202052BC
R4 = 20200F48, R5 = 20200F70, R6 = 2020526D, R7 = 14A35485
R8 = 00000010, R9 = 00000000, R10= 14A35485, R11= 00000000
R12= 00000004

Mass erased flash

J-Link>erase
No address range specified, 'Erase Chip' will be executed
'erase': Performing implicit reset & halt of MCU.
ResetTarget() start
Core did not halt on flash image verification. Assuming faulty flash settings.
Halting target manually.
ResetTarget() end - Took 316ms
AfterResetTarget() start
MPU was enabled and is now disabled.
AfterResetTarget() end - Took 707us
Erasing device...
J-Link: Flash download: Total time needed: 14.943s (Prepare: 0.067s, Compare: 0.000s, Erase: 14.835s, Program: 0.000s, Verify: 0.000s, Restore: 0.039s)
Erasing done.
J-Link>mem32 0x60000000,10
60000000 = 00000000 00000000 00000000 00000000 
60000010 = 00000000 00000000 00000000 00000000 
60000020 = 00000000 00000000 00000000 00000000 
60000030 = 00000000 00000000 00000000 00000000

Power cycle in normal boot mode and attempt to connect core

S/N: 601011684
License(s): RDI, FlashBP, FlashDL, JFlash, GDB
USB speed mode: High speed (480 MBit/s)
VTref=3.315V
Device "MIMXRT1024XXX5A" selected.


Connecting to target via SWD
Found SW-DP with ID 0x0BD11477
Failed to power up DAP
Found SW-DP with ID 0x0BD11477
Failed to power up DAP
Cannot connect to target.

Hope you can help....

[Kan_Li]

Hi @bp1979 ,

Was the mass erase successful? The content should be 0xFF after a successful mass erase, but you have 0x00 from the log, please use the tool recommended in https://community.nxp.com/t5/i-MX-RT-Knowledge-Base/RT-board-recovery-for-debugger-connect-issues/ta... and try again.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

Hi @Kan_Li 

Thanks again for helping out. We are getting more and more comfortable with restoring "bricked" boards. But we keep struggling really understanding what happens "under the hood".

One of our concerns in indeed if erasing actually does what we think it does. Do you know in more details what happens in the chip/AHB/flash? Or can get to this information internally maybe and share it here?

What we really would like to understand better is this:

When is the flash memory actually accessible from JLinkExe? When I startup to serial download, I can control the CPU, but when I issue mem32 0x60000000,10 from JLink, it gives back very strange results. I also tried to do the same on an EVK, it behaves the same there. So you could reproduce it for yourself if you want. I would expect to read the XIP bytes in 0x6000 0000, but when I am in serial download, I do not read back XIP bytes, I read back some repeating strange sequence of bytes. Why is this? Does that mean the flash memory is not accessible when booted in serial download?

In serial download, I can also erase flash successfully, but once I've done that, and again read back flash memory from 0x6000 0000, I indeed get all zeroes. So the memory is changed, but it seems to be different memory then flash memory (since that would give all 0xFF bytes after a successful erase).

So I think, this is part of the problem why we struggle to get "bricked" boards working again. I think we are missing something crucial for being able to erase flash from serial download mode.

Could you please be so kind and elaborate on this?

PS: the same questions arise on similar questions of my and my colleague on this forum regarding "using secondary flash". You don't have to detail on that topic here, but I just want to explain why we are some annoying and keep asking all these questions in the same area :).

[Kan_Li]

Hi @bp1979 ,

That is might due to the jlink driver incompatible issue, maybe the erase is ok but the data read back is not the real content. Alternatively you may try with MCUBootUtility, which can be downloaded from https://github.com/JayHeng/NXP-MCUBootUtility ,and connect with the board via USB HID interface and mass erase the whole chip, but of course, you have to enable serial download mode at first.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

Would you be able to attempt to reproduce this on your end? If you hook up an EVK with JLink, and make sure that the EVK boots in serial download, can you:

- erase flash?

- read back 0xFF bytes of the sector you erased?

Could you share what you get for result in command line using JLink in serial download?

I am curious if you at least observe the same behavior. I don't see how JLink drivers can be the problem here, because JLink behaves perfect when I boot the board in flexspi mode. When I erase a sector then, and read back the bytes of the erased sector, I do see 0xFF bytes.

The reason I keep bothering you with this, is that it would be very interesting for us to really understand why we have a hard time erasing sectors in serial download mode.

[Kan_Li]

Hi @bp1979 ,

Please kindly refer to the following for details.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

Hi @Kan_Li 

Can this be correct:

- you can erase flash on a 1064 while running in serial download

- I can NOT erase flash on a 1024 while running in serial download

Because DQS is not configured properly in ROM for the 1024.

Can you confirm that this is the reason?

[Kan_Li]

Hi @bp1979 ,

If DQS is not used, you still can read/write/erase at a lower clock frequency, for example, 30MHz ~ 50MHz, and configure flexSPI to LoopInternally.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bp1979]

Thx Kan,

that part was clear already. I wanted to understand why JLink reads garbage when reading flash when booted to serial download.

[MultipleMonomials]

Sorry to butt in to the thread, but wanted to share my two cents on this issue.

Regarding how/why devices get bricked, I have a theory that seems to hold up for real-world cases I've seen. Basically, MIMXRT series devices have an odd quirk where certain types of invalid accesses, e.g. to un-powered peripherals, cause the device to lock up in such a way that it's unusable until a reset is issued. You can reproduce this by, for example, trying to read EDMA registers without enabling the DMA clock, and observing that your debug session dies.

Additionally, when flashing the MIMXRT, flash tools such as the J-Link seem to follow the following process:

1. Issue a reset
2. Allow the core to run for some time so that the low-level bootloader can execute
3. Pause the device, download flashloader program to RAM, and interact with it to load code.

I believe that they do this since the ROM bootloader does some important setup tasks such as disabling the watchdog timer, so they need to allow it to execute after a reset before they can run their own flashloader code.

Where you can get in big trouble is, if you have code that executes very early in your startup process which causes a lockup (e.g. if you access a memory bank that doesn't exist in your startup asm, or you try to use an unpowered peripheral). When code like this exists in flash, it can get run between steps 2 and 3 above, so the device is locked up when the debugger tries to connect to it, so the flashing fails.

The reason that serial downloader mode works is, it stops the bootloader from jumping to the code in flash after initialization completes. So, your broken user code can't run, and the device doesn't hang when the J-Link connects to it. Issuing a mass erase, then, gets rid of the bad code in flash and makes the chip work correctly again.

[bp1979]

Hi@MultipleMonomials 

Thx for your lengthy explanation. I think I can relate to most of what you said.. but....

We are trying to get second flash working, and due to lack of proper understanding of the MCU/flash/and more, we end up with "bricked" boards quite easily. The good news is, that we are able to restore them quite easy nowadays, but I expected exactly what you said. The problem is on the program in flash. We simply should:

- boot to serial download by forcing the boot pins in a certain state,

- connect with JLink, erase,

- and go.

But that doesn't work. It DOES seem to work, when we upload a RAM app (e.g. blinky), and while the RAM app runs, we upload that very same app, but now to flash. Power cycle the board, and we're good to go.

But that's frustrating as hell. I want to know WHY and I can't seem to get to the actual truth.

As a little "proof" of what I am getting at, I hooked up an EVK1024 and:

- set the dipswitches to serial download.

- Power on the EVK,

- JLinkExe => connect

- mem32 0x60000000,10

I would expect some XIP bytes (because I just uploaded the nor flash SDK example a minute ago), but this is what JLink reads back:

J-Link>halt
PC = 0020C3B8, CycleCnt = 7F2B4488
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000010
R4 = 20207A3C, R5 = 401F4400, R6 = 401F4470, R7 = 00000000
R8 = 401F4470, R9 = 20203A00, R10= EE023426, R11= 00000000
R12= 00000001
SP(R13)= 20200FB0, MSP= 20200FB0, PSP= 00000000, R14(LR) = 0020C3B7
XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00

FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
FPS4 = 00000000, FPS5 = 00000000, FPS6 = 00000000, FPS7 = 00000000
FPS8 = 00000000, FPS9 = 00000000, FPS10= 00000000, FPS11= 00000000
FPS12= 00000000, FPS13= 00000000, FPS14= 00000000, FPS15= FFFFFFFF
FPS16= 00000000, FPS17= 00000000, FPS18= 00000000, FPS19= 00000000
FPS20= 00000000, FPS21= 00000000, FPS22= 00000000, FPS23= 00000000
FPS24= 00000000, FPS25= 00000000, FPS26= 00000000, FPS27= 00000000
FPS28= 00000000, FPS29= 00000000, FPS30= 00000000, FPS31= FFFFFFFF
FPSCR= 00000000
J-Link>mem32 0x60000000
Syntax: mem32 <Addr>, <NumItems>
J-Link>mem32 0x60000000,10
60000000 = F3FC7C41 ACE2CBE0 F3FC7C41 ACE2CBE0 
60000010 = F3FC7C41 ACE2CBE0 F3FC7C41 ACE2CBE0 
60000020 = F3FC7C41 ACE2CBE0 F3FC7C41 ACE2CBE0 
60000030 = F3FC7C41 ACE2CBE0 F3FC7C41 ACE2CBE0

That doesn't compute here. What  the $%!@ is it reading now?

Well, lets be dumb, and erase anyway

J-Link>erase
No address range specified, 'Erase Chip' will be executed
'erase': Performing implicit reset & halt of MCU.
ResetTarget() start
Core did not halt on flash image verification. Assuming faulty flash settings.
Halting target manually.
ResetTarget() end - Took 316ms
AfterResetTarget() start
MPU was enabled and is now disabled.
AfterResetTarget() end - Took 701us
Erasing device...

****** Error: Timeout while erasing chip, RAMCode did not respond in time (PC = 0x2000048E, XPSR = 0x81000000, SP = 0x20000A48)!
Failed to erase chip.
Failed to execute RAMCode for chip erase!
J-Link: Flash download: Total time needed: 20.114s (Prepare: 0.064s, Compare: 0.000s, Erase: 20.006s, Program: 0.000s, Verify: 0.000s, Restore: 0.044s)
ERROR: Erase returned with error code -5.

It errors out, so it erased, but returns with -5.

When I now switch back to boot from FlexSPI, and read what is on flash, nothing changed, my SDK example is still sitting there, it runs. The first bytes on flash are XIP config bytes.

J-Link>halt
PC = 60006746, CycleCnt = 3B7612B0
R0 = 00000000, R1 = 402A8210, R2 = E000ED00, R3 = 00060200
R4 = 60002000, R5 = 7F907E2C, R6 = 002002C0, R7 = 2000FDF0
R8 = 401F4470, R9 = 20203A00, R10= 7F907E2C, R11= 00000000
R12= 00000000
SP(R13)= 2000FDD0, MSP= 2000FDD0, PSP= 20010000, R14(LR) = FFFFFFF9
XPSR = 61000003: APSR = nZCvq, EPSR = 01000000, IPSR = 003 (HardFault)
CFBP = 00000001, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 01

FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000
FPS4 = 00000000, FPS5 = 00000000, FPS6 = 00000000, FPS7 = 00000000
FPS8 = 00000000, FPS9 = 00000000, FPS10= 00000000, FPS11= 00000000
FPS12= 00000000, FPS13= 00000000, FPS14= 00000000, FPS15= FFFFFFFF
FPS16= 00000000, FPS17= 00000000, FPS18= 00000000, FPS19= 00000000
FPS20= 00000000, FPS21= 00000000, FPS22= 00000000, FPS23= 00000000
FPS24= 00000000, FPS25= 00000000, FPS26= 00000000, FPS27= 00000000
FPS28= 00000000, FPS29= 00000000, FPS30= 00000000, FPS31= FFFFFFFF
FPSCR= 00000000
J-Link>go
Memory map 'after startup completion point' is active
J-Link>mem32 0x60000000,10
60000000 = 42464346 56010400 00000000 00030300 
60000010 = 00000000 00000000 00000000 00000000 
60000020 = 00000000 00000000 00000000 00000000 
60000030 = 00000000 00000000 00000000 00000000 

I can't erase flash in serial download.

I can do whatever I want when booted from FlexSPI.

Why can't I erase flash in SD? Can you? Are you sure? My board is fine, I have many EVKs and custom boards here, they all behave the same. Well. I assume that to be honest, I did this experiment on 1 custom board and one EVK, both fail to erase in SD boot. With CPU in halt, or in run. It just won't erase. And... it reads "garbage".

Is this because we're using 1024s? They have some special note that DQS is not properly setup in ROM. I am just guessing here, dying to here facts from somebody

[MultipleMonomials · Accepted solution]

Regarding reading memory using the J-Link, I think you're getting weird results because the FlexSPI peripheral isn't configured.

The MIMXRT uses its FlexSPI peripheral to talk to the external flash and to read the program data which is mapped into the 0x60000000 address space. Before it can be used, this FlexSPI peripheral has to be configured with the correct read sequences and other register settings so that it knows how to talk to the flash. This peripheral gets configured in one of three ways:

1. By the MIMXRT boot ROM.  When instructed to boot from flash, the ROM reads the fuses to figure out the basic flash type and pin mappings, then reads the boot header at the start of the flash (using a low speed standard read command) to determine the rest of the settings. (the boot header is part of your application program and is put in the correct place by the linker script). Then the ROM configures the FlexSPI registers and sequence table and then jumps to the application.
2. By your application. Your code can use the FLEXSPI hal driver to reinitialize the peripheral and configure its sequences. Off topic but here's a code example I worked on.
3. By a flashloader. When the flashloader runs it must obtain the correct settings for the flash and then configure them into the FLEXSPI registers. For MCU Boot Utility the flash settings are configured manually. For J-Link I think it works by reading the JEDEC table in the flash?

So the upshot is, if you boot up an MCU in serial downloader mode, and then debug it and try to access the FlexSPI memory space, it's expected that you will get garbage because nothing has configured the FlexSPI registers. However, if you use MCU Boot Utility, the 2nd stage bootloader it downloads takes care of configuring FlexSPI, so you will be able to read memory locations just fine. Alternately, if there's an example project which configures FlexSPI, you could probably load that to RAM and then things should work.