STM32L4 qspi: reading registers

[Lukasz Przenioslo]

Posted on March 14, 2018 at 13:28

Hello there,

I am using STM32L4 series MCU and I am trying to interface with a M25Q Micron memory using QSPI. Following the examples given from ST I have noticed that there are no HAL functions allowing registers reading, that is:

• READ STATUS REGISTER (05h),
• READ FLAG STATUS REGISTER (70h),
• READ NONVOLATILE CONFIGURATION REGISTER (B5h).

and etc.

In the examples the &sharpdefines for those commands are defined, but never used. Looking into the stm32l4xx_hal_qspi.h/c files, there is no read register command. All I could find is AutoPolling, which I am not sure either it works.

Does those functionalities need to be implemented by myself? I would appreciate all help.

#quad-spi #qspi-flash

[Lukasz Przenioslo]

Hi John,
Using xip mode means that you will run actual code from the qspi flash memory. Theoritically you can place only some functions there of the whole rom. Xip is on my roadmap, but I did not have the time yet to work on this. Thus, I havent really used xip in real application yet and cannot really help. Hal examples for l4 have a xip example as well, where they run a single function from external memory. Hope this helps.

[John3]

Hi Luka,

Many thanks for the reply.

Sorry for the another doubts. How about memorymapped. Can I changed flash access memory to 0x90000000 address. Basically I have bootloader code which looks for main firmware in mt25ql flash address at 0x90000000.

So I have to write my main application to external flash address at 0x90000000 and rest of memory to use for other configuration.

I have found the l4 example code using memory mapped mode. One more doubts suppose if I change mt25ql address to 0x90000000, So the memory map would be 0x90000000 - 0x90FFFFFF?

Thanks,

John

[Lukasz Przenioslo]

Hi John,

I havent used memory mapping either. But I think this is not what you are looking for. For me it seems that memory mapping only allows you to read data from QSPI flash memory like you would from the internal ram memory. It doesnt allow the code to be executed from thsi external memory. Maybe someone smarter can confirm this @Community member​ 

[Tesla DeLorean]

The new forum is a rats nest, the threaded view makes this an invisible older post...

Yes, in memory mapped mode the QSPI is accessed within the 0x90000000..0x9FFFFFFF space, bounded by the space/size of the physical device. Code you put into this memory would need to be complied/linked with the expectation it will reside at this address.

You can't concurrently erase/write the QSPI device, and access it via memory mapped mode. The cache might be able to maintain a partial memory view, but when switching back and forth one would need to consider coherency issues.

A boot loader would need to configure the pins, peripherals and interfaces prior to transferring control.

I haven't looked at the efficiency of executing like this, I'd expect unpacking and running from 32-bit wide SDRAM would be more effective. I've worked with QSPI execution in other contexts, and it was a drag on performance.

[Lukasz Przenioslo]

Thanks for answer,

But is it even possible to run any code in memory mapped mode? Or can you just read the memory from within user code residing in the regular RAM/ ROM? Dont you need to use XIP in order to run any code residing in QSPI flash (no matter how was the code transferred there in the first place)?

[Tesla DeLorean]

XIP requires that you put it in the memory mapped mode, and leave it there.

If you have it flipping back and forth it is likely to break.

When mapped at 0x90000000 you should be able to read/execute from it. There should be examples for multiple platforms.

There are some dual bank QSPI implementations allowing data to be pulled more quickly.

[Lukasz Przenioslo]

Ok, now I understand. So in order to use XIP, memory map has to be used before. Thank you for explanation.

[John3]

Many thanks to both of you for clearing my doubts.

I am planning to use memory mapped mode for my application. Because my boot loader already has written and look for 0x90000000 address to load the main application.

Thanks,

John

[Lukasz Przenioslo]

You are welcome, Please show your results in case you succeed in this approach, I am looking forward to seeing that.

[John3]

Hi @Community member​ :

I have tried to configure STMcube QSPI driver based on "STM32Cube_FW_L4_V1.12.0\Projects\STM32L476G-EVAL\Examples\QSPI\QSPI_MemoryMapped\" example code in memory mapped mode but i'm getting an issue in reading from the address 0x90000000.

Do I need to configure "QSPI_QuadMode" mode and "HAL_QSPI_MemoryMapped" while writing data into it.

Thanks,

John