STM32H7 FMC and 16bits device

[Alex_J]

Hello,

I'm kind of newbie in the STM32 world, I'm more used with another brand of 32bits microcontroller that also have a "parrallel port" for interfacing external ram device.

My concern is about the FMC on the STM32H7.

I want to read/write a 16bits device.

Currently I'm using this configuration (almost the default one) :

My code for testing a write operation :

....

 

I can't see any problem in the code but when I check signals with an oscilloscope, I can see that the CPU is issuing 4 consecutive write operation :

 

A0 / A1 are also increasing as if the CPU is writing to 4 different places.

How can it be possible.

I have seen in the datasheet that when AXI bus and external bus is different size, it can occurs. But in that case how to perform a correct 16 bit operation ??

Other people seems to have this kind of trouble but nobody replied with a solution :

https://community.st.com/t5/stm32-mcus-products/h7-series-fmc-question/td-p/131535

https://community.st.com/t5/stm32-mcus-embedded-software/fmc-accessed-in-32-bit-but-cs-asserted-for-twice-long-64-bits/m-p/274657

Thanks in advance for any help

 

 

[TDK]

The HAL_SRAM_Write_16b function only does 32-bit word-aligned accesses. There may be an underlying hardware reason for this. To write 16 bits, it reads 32 bits, applies the mask, then writes 32 bits.

stm32h7xx-hal-driver/Src/stm32h7xx_hal_sram.c at 85d65b023f9621e417177a87553d25b7b387239f · STMicroelectronics/stm32h7xx-hal-driver

Four CS operations matches this behavior. Two 16-bit reads plus two 16-bit writes.

 

If you want a 16-bit access, I'd just do a 16-bit access write.

*(volatile uint16_t*)address = value;

[Alex_J]

@TDK Thanks for your fast answer, but I quickly tried your solution :

But I still get the 4 write operations.

The goal is to write to a peripheral that will only accept one write operation by 16bits data. 

[Pavel A.]

While waiting for better answers, can you do another quick experiment?

Using the MPU disable caching on your external memory window.

Per AN4839, the 0x60000000-0x7FFFFFFF range on STM32H7 is "normal memory", cacheable. What you see could be loading the 32-byte cache line and write back.

Also, check the suitable memory mode for FMC: should it be "SRAM" or other? 

 

[Alex_J]

@Pavel A.

Thanks for your answer, but currently, caching is disable for this region :

 

 

[waclawek.jan]

> when I check signals with an oscilloscope, I can see that the CPU is issuing 4 consecutive write operation :

How do you know those are *write* operations? Which signal do you display there?

Do you have that area set as Device or as Memory in MPU?

JW

[Alex_J]

I'm sorry that I forgot to mention that the signal shown is the WE send from the STM32 to the device.

[waclawek.jan]

Do you have the used FMC memory area set as Device or as Memory in MPU?

JW

[Alex_J]

@waclawek.jan 

Either I don't know where to search for this option, either it did not exist xD :

 

 

 

Edit :

I also try to deactivate the MPU without success, I still have 4 write cycle.

[waclawek.jan]

I don't use CubeMX and have no idea how those clickable things translate to the MPU settings, sorry. Maybe somebody more versed in Cube/CubeMX will chime in.

(I should have written "Normal" instead of "Memory" above).

I don't know which 'H7 you are using, so I looked into RM0433 (for 'H743 and kin) and there's an option to remap the SRAM/NOR area of FMC to a different address, which is by default set to Device:

The remap in the 'H743 is accomplished through setting the FMC_BCR1.BMAP bitfield

 

However, if you apply MPU settings onto a memory area, its those MPU settings which override the defaults, so here you would perhaps want to do only the remap without using MPU at all.

Again, I have no idea how is this clicked in CubeMX.

And still, this is just one thing to try, I don't say this will certainly solve your problem. The Cortex-M7 is an overcomplicated beast and the 'H7 in particular adds a couple of extra layers of complexities to it.

JW

 

[Pavel A.]

I'm looking at one project for STM32H753 with FPGA, there we defined the FMC "instance" type as NOR, not as SRAM. The windows addresses are in 0x60000000 range; set in MPU as non-shared device; not remapped.

32-bit accesses to the FPGA work just fine, no unexpected behavior.