FlexSPI ROM API get_config

[MulattoKid]

Hi,

I've got a question regarding using the get_config function in the FlexSPI ROM API:

On the RT1060 I have a flash configuration block in the first 4KiB of my image (starting from 0x60000000). However, when calling

g_bootloaderTree->flexSpiNorDriver->get_config

the configuration returned doesn't match the one in flash, which I assumed it would. So, I'm wondering what the function actually does, does it 1) return the configuration that's in flash, or does it 2) communicate with the flash chip to determine the configuration, or does it 3) do something else?

Thanks,
Daniel

[diego_charles · Accepted solution]

Hi @MulattoKid 

As you saw, the bootROM does get some LUT information from the Memory, discovering its specific configuration, if it is compliant to the related JEDEC SFPD standard. See an example from the i.MX RT1170 ROMAPI demo.

You can see that after calling the get_config API of the bootROM, the FlexSPI LUT contents get updated.  Additionally the config structure that the API resides, this structure is located in RAM and used later on by the example. 

The bootROM development team considered that in the market will be a very wide range of memory manufacturers, so they decided to not save the configuration of any memory, as we can use the JEDEC standard.

As a related topic to the memory parameter discovery, the MCUXPresso IDE integrates some generic or in some cases more specific flash drivers. The generic drivers use the bootROM for parameter discovery. The below chapter from the IDE user guide introduce this.

I hope this could help, let me know if you are still having any more questions or comments. 

Diego

[asmvolatile]

I also want to echo the need for an answer to @MulattoKid 's question

Notably, does the get_config() ROM API eliminate the need for our applications to even have a LUT if we want to be able to read/program/erase from QSPI or HyperFlash? Also does this have anything to do with the image FCB? If the get_config() ROM API can somehow obtain a valid LUT, then why does the FCB need to exist? Perhaps for flash parts that don't support that JDEC command?

I don't quite understand the interplay between the get_config() ROM API and the need for a LUT (and additionally, the FCB).

If you could please clarify whether or not 1060/1064 applications need to even have a LUT if using QSPI or Hyperflash (and why) that would be great.

[MulattoKid]

I was wondering the same thing, so I tried without a LUT and that didn't work. The smallest LUT I got working was one with a read command. My assumption is that at minimum a read command is needed when using XIP, as the code needs to be read from the flash chip. Without it, get_config won't even get to run.

[MulattoKid]

Thanks for sharing this information, @diego_charles!

[MulattoKid]

From some reading it seems that the MCU most likely will send the "Read JEDEC ID" command, which will return the JEDEC ID++, and the size of the flash chip. So that tells me how the size for the given chip is determined, but what about the command LUT? Does the boot ROM have a table for the various flash chips it supports, and performs a look-up based on the JEDEC ID to the correct LUT table version?

[MulattoKid]

Upon further reading, does the SFDP command return the LUT? I see it returns 256 bytes, which is the size of the LUT, correct?