@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).
Where to start STM32H7 support
Moderators: RoccoMarco, barthess
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Where to start STM32H7 support
I haven't touched MDMA yet, so cannot answer this. You are assuming the problem is on DMA not SPI anyway.
Giovanni
Giovanni
-
- Posts: 141
- Joined: Mon Sep 25, 2017 8:27 am
- Location: Canberra, Australia
- Has thanked: 10 times
- Been thanked: 20 times
- Contact:
Re: Where to start STM32H7 support
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.
-
- Posts: 141
- Joined: Mon Sep 25, 2017 8:27 am
- Location: Canberra, Australia
- Has thanked: 10 times
- Been thanked: 20 times
- Contact:
Yipee! SPI DMA now working with HSE 16MHz
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
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Where to start STM32H7 support
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
Could you try DIV4? then try to halve SPI speed using DIV2?
Giovanni
-
- Posts: 141
- Joined: Mon Sep 25, 2017 8:27 am
- Location: Canberra, Australia
- Has thanked: 10 times
- Been thanked: 20 times
- Contact:
Re: Where to start STM32H7 support
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
Re: Where to start STM32H7 support
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
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: Where to start STM32H7 support
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
Giovanni
Re: Where to start STM32H7 support
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?
-
- Posts: 141
- Joined: Mon Sep 25, 2017 8:27 am
- Location: Canberra, Australia
- Has thanked: 10 times
- Been thanked: 20 times
- Contact:
Re: Where to start STM32H7 support
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.
Who is online
Users browsing this forum: No registered users and 26 guests