i.MX RT0106 FLEXSPI_TransferBlocking and XIP

[dafela]

Hi,

I'm working on an i.MX RT1060, and am using XIP. I'm aware that our flash chip doesn't support RWW (read-while-write), and so during programming and erasing of sectors interrupts are disabled, and the FlexSPI driver code is placed in RAM.

However, I'm wondering about reads? When reading from flash through the memory map no extra precautions are needed, but what about when calling FLEXSPI_TransferBlocking to e.g. read out the JEDEC ID of the flash chip? Does this behave the same way as when reading using the memory map, or do interrupts need to be disabled here as well? If yes, why, what's the difference in the behavior for the FlexSPI controller?

Kind regards,
Daniel

[diego_charles]

HI @dafela 

This is a very interesting question for which I feel that I do not have definitive answer, let me explain below.  

I generally would keep all the flexSPI related functions linked under SRAM and with interrupts disabled when needed, but for some cases, as you imply, it may  not be necessary to threat all the functions the same.  Are you facing an optimization issue? To avoid linking flexSPI functions to  SRAM  I would recommend to call bootROM APIS, they use FlexSPI too, but they are already embedded into bootROM memory map. Or, do you see any problems within your implementation?

Per my understanding, interrupts are disabled to  avoid any unexpected flash access until write operation completes. Based on this, I would say that triggering an AHB FlexSPI command that does not involve writting ( as reading SFDP commands), should support working along interrupts enabled.  However, testing this on an RTOS environment would be better, as the systick is always interrupting. 

I mention AHB commands because this kind of transfer do not require SW to pull as, we need with IP commands

The function you mention does implement IP commands, wich do require SW polling and monitoring. 

Another aspect to consider is that the reading JEDEC or SFDP parameters is being done before configuring the FlexSPI for the specific flash memory characteristics. Once the flash is configured, we tipically care for R/W commands. So this limits the quantity FlexSPI commands we have to do during runtime. 

I hope this helps!

Diego

[dafela]

HI @diego_charles,

Thank you for your detailed answer!

We're running ThreadX, and in our first implementation of reading the JEDEC ID we haven't disabled interrupts (FlexSPI functions are in RAM). We haven't seen any issues, but were concerned with this mostly working, but strictly speaking not being correct use. The "better safe than sorry" approach would be to just disable interrupts, but generally I don't like doing stuff like that without there being an explanation as to why

As for using the bootROM API, correct me if I'm wrong, but I don't think that can be used for reading the JEDEC ID? And as the JEDEC ID is retrieved before the FlexSPI is initialized, is it possible to read it from somewhere without querying it from the flash chip itself?

Kind regards,
Daniel

[diego_charles]

Hi @dafela 

Thank you for your reply it is my pleasure. 

I understand, I have been there, once I did a Filex and FlexSPI project to create flash based file system. Due to systick I had to temporally disable interrupts.

As you mention I used "'the better safe than sorry" approach,  by putting intialization and RW without interrupts.

Regarding, As for using the bootROM API, correct me if I'm wrong, but I don't think that can be used for reading the JEDEC ID?

I have not analized this further but the bootROM API does let you get configuration from the memory and does support the JEDEC standard. With this you should get able to get basic information from the flash. 

This can be done by calling 

 g_bootloaderTree->flexSpiNorDriver->get_config(instance, config, option

Below the parameters that the bootROM can read in the config argument. 

Attached I left some demo code of the bootROM implementation for the RT1064.

I  hope this helps. 

[dafela]

Thanks again @diego_charles - I'll have a look at this.