SB bit of DMA2D_OPFCCR register missing on STM32H7?

[Martin Meijerman]

Dear Sir/Madam,

It seems that DMA2D_OPFCCR register SB bit described in the reference manual of the the STM32H7 (RM0433, page 721) is not implemented. Code generated by CubeMX is missing the definition completely, an attempt to set the bit directly from code has no effect the bit remains 0:

hdma2d.Instance->OPFCCR |= (1 << 8);

Also tried:

hdma2d.Instance->OPFCCR |= 0xffffffff;

Resulted in 0x300007

It seems that only RBS, AI, CM are implemented...

What could be causing this?

Is this a mistake in the reference manual?

Has the byte swap function of the output FIFO been omitted?

Background:

We have a display connected to an SPI peripheral, DMA is used to send pixel data from a framebuffer to that display.

The display expects RGB565 data in big endian format, like this:

byte0: R0[4:0] G0[5:3]

byte1: G0[2:0] B0[4:0]

byte2: R1[4:0] G1[5:3]

byte3: G1[2:0] B1[4:0]

etc.

This is fine for static artwork, which could be formatted this way. However we are planning to use DMA2D to render texts and alpha blend images. Looking at the RGB565 definition of the DMA2D (RM0433, page 697)

byte0: G0[2:0] B0[4:0]

byte1: R0[4:0] G0[5:3]

byte2: G1[2:0] B1[4:0]

byte3: R1[4:0] G1[5:3]

RGB565 little endian (right?). It seems that the even and odd bytes need to be swapped before they can be sent to the dispay. The SB bit of the OPFCCR register promises to do just that....

Does anybody have a fix for this issue?

Thanks in advance!

Best regards,

Martin Meijerman

[Ixox]

Hello,

I have this exact same problem.

Searching "DMA2D_OPFCCR" with different search engine list this thread as first item.

I use DMA2D with blending to prepare a buffer that i transfer to my ILI9341 display in SPI mode (DMA).

Unfortunately the output rgb565 of DMA2D is swaped.

I saw the SB bit of the OPFCCR register in the reference manual but unfortunately this bit is not referenced in CubeMX and seems useless if i set the bit directly.

SB is described in RM0433 rev 6 page 732.

Does anyone know anything about it or used it successfully ?

Thanks,

Xavier

[Martin Meijerman]

Hi Ixox,

I opened a support issue with ST directly as well, there was no satisfying answer from them, eventually that issue was closed by them with the remark that it had been open for too long.... It seems that ST customer support is trying to lower the number of pending issues by closing issues rather than solving them....

Anyhow, I personally think that it might be a hardware revision issue. If you look at old revisions of the reference manual, the swap bit wasn't mentioned in those, giving me the impression that the feature might have been added later on...

I eventually decided to add an extra MDMA pass to swap all the bytes in the framebuffer to the format that the display required at the cost of a few extra milliseconds of rendering time and extra memory bandwidth usage...

Good luck finding your solution.

Best regards,

Martin Meijerman

[Ixox]

Thanks for the update.

I use blending operation to display charaters on a background. So i use A8 color mode for the foreground layer with a color in register.

I think i'll only use alpha 0x00 and 0xff.

0x00 works fine, it's just copying the background. I don't understand why the result is not broken in that case, but it works fine =)

And alpha=0xff copy the FG and change the color because of the Swap bytes, but i can find color that fits. =)

Xavier

[Martin Meijerman]

Hi,

It seems that you are doing a very similar thing as I have been doing!

I have been doing tests with both A4 and A8 fonts, as it turned out the difference is not visible at all, since the display only has a 16 bit color depth.

Your bitmap fonts become a lot smaller when using A4. Just a thought.

Also have you noticed the official maximum SPI frequency of the ILI9341?

twc = 100ns minimum ==> 10MHz

At that speed the display refresh becomes visible like a slideshow.

I have tested it up to 85MHz using DMA, but our display sample dimmed while communicating at speeds > 10MHz.

Overclocking a component is not what we wanted to do, that is why we moved to the RGB interface of the ILI9341, thereby removing the need to byteswap the frame buffer since that swap can be done by swapping some lines.

Hope this helps!

Best regards,

Martin