STM32H743 possible bug, or two :)

[Oleg Skydan]

Posted on September 22, 2017 at 15:55

Hi, All!

I have made a board with STM32H743 (ES32H743 rev.Z datecode 633) and ported quite a big STM32F746 project to STM32H743. The works is not yet finished, but I have some questions and information that can be useful for others, so I want to share it.

Problem:

DMA2D hangs reading data from the ASIB which actively exchanges data with the other(s) AMIB(s).

Reproduction:

Arrange Cortex-M7 core to actively use AXI SRAM or FLASH A (probably other slaves can be used, but were not checked). Arrange DMA2D to read data from the same slave (AXI SRAM or FLASH A). You should see DMA2D hangs in a short time. Debugger shows the START bit in DMA2D CR register remains set, but no flags are set in the DMA2D ISR register, and DMA2D do nothing (requested operation is not executed).

Solution:

Setting bit 0 (READ_ISS_OVERRIDE) in the AXI_INI5_FN_MOD register completely solves the above problem:*((__IO uint32_t*)0x51046108) = 0x1;

There is also another problem with DMA2D. It works finely if the destination is the internal SRAM, but when its destination is the FMC SDRAM it looks like it writes data only in 8bytes chunks aligned to the 8bytes boundary. So the vertical line in the RGB565 frame buffer looks like the line at the right place with some 'padding to 4pixels' around it. The result (line+padding) is aligned to 4pixels (8bytes in the frame buffer).

If I draw using the CPU everything is ok, the same DMA2D code works nicely for the internal SRAM and on the STM32F746 processor. The different memory tests (SDRAM) shows no errors. The chip is MT48LC32M16A2 running at 100MHz.

The board is a bit unusual in hardware - the low address byte lines are swapped:

* MCU    SDRAM | SDRAM      MCU

* A0 ------ A4 | A0 ------- A7

* A1 ------ A5 | A1 ------- A6

* A2 ------ A6 | A2 ------- A4

* A3 ------ A7 | A3 ------- A5

* A4 ------ A2 | A4 ------- A0

* A5 ------ A3 | A5 ------- A1

* A6 ------ A1 | A6 ------- A2

* A7 ------ A0 | A7 ------- A3

It should not bring any problems according to manuals, but maybe I have missed something? The SDRAM mode register is programmed with address lines swapping in mind.

Thanks!

Oleg

[Tesla DeLorean]

Posted on September 22, 2017 at 17:50

>>It should not bring any problems according to manuals, but maybe I have missed something?

I'd wonder how burst access would keep incrementing internally to the SDRAM

[Oleg Skydan]

Posted on September 22, 2017 at 18:05

Clive One wrote:

I'd wonder how burst access would keep incrementing internally to the SDRAM

FMC uses burst length of 1 that is as far as I understand no real burst actually.

[Oleg Skydan]

Posted on September 23, 2017 at 11:42

So, I did some more detailed investigation of what is going on with DMA2D. Here is a first gdb console screenshoot:

You can see I programmed DMA2D to fill the 8 words (16bit pixels) starting from the 0xD0000000 address with 0xFFFF. This operation was successful cause address and line size were 8byte aligned.

Then I programmed DMA2D to emit one pixel at 0xD0000004 address with 0x5555 ''color''. You saw what I got (the green underline indicates right and expected result, the red underline is the problem) - the unusual thing is that

byteswas changed (notwordsas I thought before). Then I repeated one pixel operation for the 0xD000000A address and got the same result. I have no mind what is going on (chip problems?)...

The next screen shoot demonstrates direct data write to the SDRAM (not using DMA2D), as you can see everything works finely. Of cause it is not the real memory test, but I run tests also and they indicated no problems:

I would like to hear any thoughts, please!

[Oleg Skydan]

Posted on September 23, 2017 at 12:04

Figure 33 from the stm32h743 datasheet gives an explanation why such address bus connection should work:

As you can see FMC issues column address for each word being write to the SDRAM (the same is true for the read as can be seen on the Figure 32). Of cause I expect the datasheet is correct.

[Oleg Skydan · Accepted solution]

Posted on September 23, 2017 at 14:53

Ladies and Gentlemen, I apologies - the second problem was related to hardware failure here (one of the lines between SDRAM and MCU was broken because of PCB defect). 

So:

1. The first problem is there, but the solution works.

2. DMA2D works correctly with the external SDRAM

3. Address lines of the SDRAM can be swapped in the low byte (it is not a general rule, in general you should route pin-to-pin A0-A2 lines, but with current STM32 you can swap all lines in the low byte because of FMC does not issue burst accesses to SDRAM).

Thanks!

Oleg

[Emmanuel COMBETTE DE RYMON]

Posted on September 26, 2017 at 15:23

Hi Oleg,

The first issue is indeed a known DMA2D issue on the STM32H743 revZ which is corrected in the rev.Y today for sales.

This was visible on the example ...\STM32Cube_FW_H7_V1.1.\Projects\STM32H743I_EVAL\Examples\DMA2D\DMA2D_BlendingWithAlphaInversion. These rev.Z are engineering samples, they are not distributed on the market.

Br,

Emmanuel COMBETTE

STMicroelectronics - T.O.M.A.S - Technically Orientated Microcontroller Application Service

[Oleg Skydan]

Posted on September 26, 2017 at 17:22

Hi, 

Emmanuel,

Thanks for clarification! I know the MCU I use is engineering sample.

If you are aware of rev.Z errata can you please tell are there any problems with SPI+DMA data reception in the rev.Z MCUs? I get excessive data in the data stream in that configuration, DMA transmitting works finely.

[Emmanuel COMBETTE DE RYMON]

Posted on September 26, 2017 at 17:41

Hi Oleg,

You should not use this rev.Z since there are different of issue on variaous IPs.

Br,

Emmanuel

[Oleg Skydan]

Posted on September 26, 2017 at 19:49

You should not use this rev.Z since there are different of issue on variaous IPs.

I will use newer revision chips when they will be available here. It is not for production just for evaluation of the new STM32H7 family.