Where to start STM32H7 support

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderators: barthess, RoccoMarco

tridge
Posts: 86
Joined: Mon Sep 25, 2017 8:27 am
Has thanked: 8 times
Been thanked: 9 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Thu Feb 21, 2019 12:15 am

@Giovanni, do you think it is worth trying MDMA between DTCM and SPIx to work around the SPI DMA issue I'm seeing? SPI is on the APB bus, and the system architecture diagram seems to show that MDMA can access all APB peripherals.
As a side effect it should also be more efficient, as I will have 16 more DMA channels to use, and I won't need to do nearly as much DMA sharing (in fact, I think I could have a dedicated stream per peripheral).

User avatar
Giovanni
Site Admin
Posts: 12021
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 543 times
Been thanked: 455 times
Contact:

Re: Where to start STM32H7 support

Postby Giovanni » Thu Feb 21, 2019 8:21 am

I haven't touched MDMA yet, so cannot answer this. You are assuming the problem is on DMA not SPI anyway.

Giovanni

tridge
Posts: 86
Joined: Mon Sep 25, 2017 8:27 am
Has thanked: 8 times
Been thanked: 9 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Thu Feb 21, 2019 8:49 am

Giovanni wrote:I haven't touched MDMA yet, so cannot answer this. You are assuming the problem is on DMA not SPI anyway.

yes. The problem doesn't happen with SPI polled mode though, which is some evidence it is a DMA issue. Not absolute proof of course.

tridge
Posts: 86
Joined: Mon Sep 25, 2017 8:27 am
Has thanked: 8 times
Been thanked: 9 times
Contact:

Yipee! SPI DMA now working with HSE 16MHz

Postby tridge » Thu Feb 21, 2019 11:42 am

I finally have a working config for SPI DMA with a 16MHz HSE. The key was to change the 4 STM32_DxPPREx values from DIV2 to DIV1.
Basically I took a guess that the DMA engines on the APB buses might be starved of bandwidth and not keeping up with SPI without the FIFO enabled. By changing to DIV1 I get 96MHz on all the APB and AHB peripheral clocks, whereas previously some of them were at 48MHz. I don't really know if that explanation makes sense, but it was the idea I was pursuing when I changed the setting.
It is very strange though, as even at very low SPI bus clocks the problem happened, and it happened on all the SPI buses I tested (SPI1, SPI2 and SPI5).
The actual commit that fixed it is here:
https://github.com/tridge/ardupilot/com ... 0d02941b28
Thanks to everyone for brainstorming ideas on this issue, it is really much appreciated. It drove me nuts for several days.
Cheers, Tridge

User avatar
Giovanni
Site Admin
Posts: 12021
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 543 times
Been thanked: 455 times
Contact:

Re: Where to start STM32H7 support

Postby Giovanni » Thu Feb 21, 2019 12:14 pm

Good to know it works now. But why only on BGA devices?

Could you try DIV4? then try to halve SPI speed using DIV2?

Giovanni

tridge
Posts: 86
Joined: Mon Sep 25, 2017 8:27 am
Has thanked: 8 times
Been thanked: 9 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Thu Feb 21, 2019 12:43 pm

Giovanni wrote:Good to know it works now. But why only on BGA devices?

we don't actually know that it being a BGA was the key factor. It also has a different HSE (16MHz) from the other two boards (they have 8MHz and 24MHz HSE).
I also wonder if the tolerance of the crystal matters. The board with 16MHz HSE has a 20ppm crystal. Hmm, the nucleo is also 20ppm (with 8MHz crystal), so probably not a factor.
Could you try DIV4? then try to halve SPI speed using DIV2?

sure, will do

bluuu
Posts: 5
Joined: Sun Dec 30, 2018 9:27 pm
Been thanked: 1 time

Re: Where to start STM32H7 support

Postby bluuu » Thu Feb 21, 2019 2:24 pm

one thing what i can imagine of this issue is a delay in DMA, if MDMA is dedicated for SPI any you using other one there is a "gap" in data, from other hand, maybe there is other clocking for SPI and DMA and then you increse clocking the "gaps" dissapered

User avatar
Giovanni
Site Admin
Posts: 12021
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 543 times
Been thanked: 455 times
Contact:

Re: Where to start STM32H7 support

Postby Giovanni » Thu Feb 21, 2019 3:04 pm

It must be some kind of glitch, it looks like the DMA is triggered twice for each frame, this is why the output is interleaved with zeros.

Giovanni

steved
Posts: 599
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 4 times
Been thanked: 74 times

Re: Where to start STM32H7 support

Postby steved » Thu Feb 21, 2019 6:52 pm

Giovanni wrote:It must be some kind of glitch, it looks like the DMA is triggered twice for each frame, this is why the output is interleaved with zeros.

Giovanni

Or how about if the DMA is doing an 8-bit read followed by a 16-bit write?

tridge
Posts: 86
Joined: Mon Sep 25, 2017 8:27 am
Has thanked: 8 times
Been thanked: 9 times
Contact:

Re: Where to start STM32H7 support

Postby tridge » Thu Feb 21, 2019 10:04 pm

Giovanni wrote:Could you try DIV4? then try to halve SPI speed using DIV2?

I've tried a lot of combinations now, with lower SPI clock, changing SPISEL etc, and the only thing that I've found that triggers the issue is having STM32_D2PPRE2 set to STM32_D2PPRE2_DIV2. The other STM32_DxPPREx values don't seem to matter (I'm using SPI2 as the test in each case, in case that matters).
I've looked through hal_lld.c and hal_lld.h to see if I can spot anything wrong in the macros related to that part of the clock tree and so far I haven't spotted anything incorrect.
btw, the reason I had D2PPRE2 set to DIV2 in the first place is I had copied it from the USB_CDC example for stm32h743_nucleo144. Perhaps we should change that example to use DIV1? Is there any reason it used DIV2? It shouldn't affect the USB.


Return to “STM32 Support”

Who is online

Users browsing this forum: No registered users and 2 guests