Where to start STM32H7 support

[Giovanni]

I will change all defaults in mcuconf files. It could be a good idea to report this to ST via forum and see if they have an answer.

Giovanni

[tridge]

I will change all defaults in mcuconf files. It could be a good idea to report this to ST via forum and see if they have an answer

good idea, I've posted it here:
https://community.st.com/s/question/0D5 ... m32k743iik

[rew]

Hey Tridge, long time no see! (ran into your name much more often like a decade ago.... I don't think we've met).

Could it be that the SPI module is in byte mode while the FIFO is in word mode. Or the other way around. IIRC the SPI peripheral was designed for a 16-bit CPU, all registers are limited to 16 bits. Does it help if you tell the DMA to use halfword (16-bit) accesses to the SPI data register?

I also remember a bug I ran into a long time ago: chibios was doing half-word accesses to the SPI data register while my CPU had a byte register. Or something like that. Check your manual and check the chibios source. Giovanni is good, but sometimes while most things stay the same, ST suddenly changes a subtle detail of a peripheral in an unexpected way....

[faisal]

What if you disconnect the SPI lines going to the slave device and enable the internal pull-up on MISO? When you do the SPI transaction, you should receive all 0xFF.

[tridge]

@Giovanni, I had a go at SDMMCv2 yesterday for H7. I know you are working on it, but it looked like a fun thing to try (and learn about).
I got it to the stage that I can see appropriate D0 commands on the bus with my Saleae and the clock looks fine, but I got stuck on trying to get the IMDA working. Vector104 for SDMMC1 does trigger if I set the MASK broad enough, but I only get 0x40 (CMDREND). I never see the DATAEND interrupt and the receive buffer for a sdc_lld_read_special() never gets anything written into it. I've tried both with DCache disabled and enabled. I'm doing transfers to AXI SRAM if that matters.
I'm really puzzled by how this is supposed to work. The ref manual says we shouldn't be setting SDMMC_DCTRL_DTEN, and instead the data transfer is started by a trigger between the peripheral and IDMA. It seems there is something called Sdmmc_dataend_trg, related to the MDMA. I don't understand how we are supposed to set that up. Do we really need to configure MDMA for a single IDMA transfer on SDMMC, or do we only need it if we want to do fancy chained transfers?
This is the setup I'm using so I can snoop on the traffic with the Saleae:
https://photos.app.goo.gl/sfrpevUrZ45djej79
despite the very long cables this works fine with SDMMC on a F7.
Cheers, Tridge

[tridge]

Hey Tridge, long time no see! (ran into your name much more often like a decade ago.... I don't think we've met).

Hello! I'm afraid I can't remember 'rew', but my memory for names has always been quite dodgy

Could it be that the SPI module is in byte mode while the FIFO is in word mode. Or the other way around. IIRC the SPI peripheral was designed for a 16-bit CPU, all registers are limited to 16 bits. Does it help if you tell the DMA to use halfword (16-bit) accesses to the SPI data register?

could be, but I don't see why this would be affected by a clock tree setting. That is the big puzzle. With that small clock tree change its all very reliable. I did a flight with this board with the clock tree change on Sunday, and it flew perfectly. Being able to fly a plane is a pretty good test that all the SPI transfers are good, as physics is quite unforgiving of bad sensor data

[tridge]

I made some more progress on SDMMCv2 on a H743. I still don't have IDMA working, but I do have a working polled driver. I can access flight logs in ArduPilot now, and create logs. I've attached the current version.
Only polled transfers work so far. I spent quite a bit of time today trying to get interrupt driven transfers working, but as yet they don't work. I do get some successful transactions, but pretty soon either get a lockup or data corruption. I've left the interrupt driven implementation in the driver, enabled for read and write using the SDMMC_POLLED_READ and SDMMC_POLLED_WRITE defines at the top of the driver. If anyone can spot what the issue is with interrupt driven mode that would be great.
Of course what we really want is IDMA working, but so far I've had no luck with that. See my previous question about triggers.
Cheers, Tridge

[Giovanni]

I will give a DMA driver a try after I am back from travel.

Giovanni

[tridge]

I will give a DMA driver a try after I am back from travel.

I had another go at it this morning, and IDMA now works! Yipee!! The order of register setup is really quite critical.
I attach the working driver. It has defines for polled, interrupt driven and IDMA modes. Only polled and IDMA work at the moment. I still can't figure out why interrupt driven mode doesn't work, but as all I will want to use is IDMA I probably won't spend much time on it.
Note that I used the ArduPilot bouncebuffer hooks for the DMA flush/invalidate and allocation calls. That allows me to keep the FATfs layer simple, and automatically handle transfers to/from any type of memory.
Cheers, Tridge

[tridge]

here is a version that only uses IDMA, and simplifies the structure a bit. It still has the bouncebuffer hooks in it.
The bouncebuffer API is defined here:
https://github.com/ArduPilot/ardupilot/ ... cebuffer.h

@Giovanni, would you consider having a HAL_USE_DMA_BOUNCEBUFFER option, which would enable calls to a bouncebuffer API like this one, but renamed to chDMABouncebuffer_xxx() ? Then the user would need to supply the actual implementation. We could have a simple sample implementation that does invalidate/flush calls. More complex implementations need to worry about dynamically allocating memory from the right heap for the needs of the particular MCU so that could be left out of the scope of the hal, but the user can put it in their implementation if they need it.
This allows everyone to choose their own strategy for coping with the dcache, while allowing them to use the common drivers.
Cheers, Tridge