1

A while ago I wrote my own ethernet driver for fun, and most of the time was spent banging my head on the keyboard because it wasn't working - as is tradition.

Problem ended up being that ethernet simply couldn't read from or write to AXI SRAM. I made a very long post about it (along with a couple other matters) on st's community thing, that went unanswered and I eventually forgot about it.

The reason I ask here how it is I should have known, is because it doesn't really seem to mention it anywhere. The bus interconnect table and diagrams don't seem to show any potential problem:
enter image description here enter image description here

And the block diagram: enter image description here

And maybe the ART isn't what I interpret from this: enter image description here
but what I interpret is that it serves as an accelerator for the pre-fetching of instructions to be executed by (assumingly) the M4 processor from D1 memory - and to establish a connection to D1 memory in general.

Is this just me not knowing the meaning of the word "access"? English isn't my first language but I'm pretty sure when you "gain access" to something, that means you get to play around with it, so reading and writing.

This has come to mind after so long because now I want to use an SD card for something I'm doing, and I find it necessary to write from D2 memory into the card, and then from the card into D1 memory.

SDMMC1 is out of question since it can't even interact with D2 memory at all, and for SDMMC2 I'm afraid I'll have the same scenario as I did with ethernet.
I realize I can still regular-dma things around, but that's quite a bit of extra complexity and extra memory use.

So - what did I miss that would have let me know I can't ethernet-dma into axi sram? And should I expect it to prevent me from sdmmc2-dma-ing into axi sram as well?

Thank you!

EDIT:

Apparently there's an ST article about ETH peripheral usage on the H7s, and it does say D2 memory indeed needs to be used for descriptors and buffers alike (aka everything). I'm pretty sure it's something you couldn't really tell from the documentation. I suppose the takeaway is think twice before you make plans for transfers between different bus matrices and domains in general.

I have yet to test SDMMC2, and I likely won't because this throws a big enough wrench in the plans that I've decided to do something else and written a SDMMC1 driver (that was even more of doozie). SDMMC1 of works with AXI SRAM.

TrisT
  • 639
  • 6
  • 19
  • Whilst I sympathize with you over the quality of ST's documentation for their more complex parts, this is not the place for this question. https://electronics.stackexchange.com/ perhaps. But for what it is worth, my opinion is that ST have given up on proper documentation in favour of forcing you to use their CubeMX ecosystem. Sad though that it is. There is even one part of the reference manual that entirely gives up on attempting to document I2C clock configuration and simply tells you to use CubeMX. It is unacceptable IMO, and does not help with variable clock rates. – Clifford Sep 11 '22 at 16:32
  • Looking at the block diagram what I can spot is that the 512KB AXI SRAM is connected directly to the AXI Bus, while both the ETH MAC and SDMMC are connected to the AHB Bus matrix. Maybe that should point out the fact that those peripherals do not have access to the AXI SRAM. (I'm not saying I could spot it for the firts look, but this now seems logical to me.) – balas Feb 09 '23 at 00:10
  • @balas in the meantime I wrote an SDMMC driver as well, and I can confirm it works with AXI SRAM. I'm thinking that ART (instruction cache) might only serve only the purpose of fetching instructions across domains in case the M4 processor wants to execute instructions from AXI SRAM or something. I never updated this post (I will now) but I found [this](https://stcommunity.st.com/t5/stm32-mcus/ethernet-not-working-on-stm32h7x3/ta-p/49479) ST article about reasons why the ethernet peripheral might be failing, and it outright says D2 memory is mandatory for both the buffers and the descriptors. – TrisT Jun 19 '23 at 18:11

2 Answers2

0

I didn't write my own driver, but used Cyclone TCP/IP stack on CM7 core. I had the same problem when trying to put my buffers/descriptors into SRAM4.

I observed ETH_DMACSR all REB, TEB and FBE bits set to 1. After switch to SRAM3 all is working like harm.

Unfortunately, I am unable to answer your question and say how this will work with SDMMC :(

Wojciech Krupski
  • 41
  • 5
0

Err... is it really so?

Form AXI interconnection diagram, it looks like Flash1-2 and AXI SRAM have completely same interconnection pattern. And Flash works OK with M4.

Maybe the real source of issue lies in timings/fetch delays?

Theoristos
  • 1
  • yes, yes it is. check the edit on my original post for the official ST article saying as much. Also AXI SRAM and Flash 1-2 alike are on a different domain from the ETH peripheral which isn't the case for the M4 since it's single-processor and (I assume) therefore single-domain. Also if you're unsure of your answer, perhaps a comment might be a better option. Though timings are a good guess, here they're mostly handled automatically by the bus interconnect provided you set initial bus frequencies that make sense. – TrisT Jun 19 '23 at 18:24
  • @TrisT : Yes, I also find this [link](https://community.st.com/t5/touch-gfx-and-gui-mcu/stm32h7-dcmi-to-sdram-with-dma-overrun-flag/m-p/313199) . So the root of problem is that Eth have internal DMA in D2 domain. Due to differences in D1 and D2 bus widths, D2 DMAs have a problem to correctly access AXI RAM. DMA1-2 can be tuned to do that, maybe for Eth DMA it is impossible or requres special tuning (not checked yet). Also, if one uses M7 core with caches on to control Eth, due to possible out-of-order instruction fetching one need to tune MPU memory regions/(or code itself). – Theoristos Jun 23 '23 at 04:42