[DEV] STM32H7xx support (new)

[mikeprotts]

I've missed the changes to the RDESn & TDESn (hal_mac_lld.h) so that's the next for me to look into.

Mike

[mikeprotts]

And now with those defines updated - there are a lot of differences. Most of the settings for rdes0/tdes0 are now in rdes3/tdes3 and there's no obvious direct swap so a few changes scattered throughout.

A reserved register bit was being used as a lock (STM32_TDES0_LOCKED) which I've not copied as I'm not sure if there's a suitable bit available, but I'm not getting far enough to worry yet..

DMA registers have changed to need start & end pointers and a count so the initialisation part has had to change to match. There's also a minimum four for transmit and receive descriptor length.

DMA initialisation is described on page 2870, starting with software reset using DMAMR. The problem I'm seeing at the moment is with reset never completing, which is a simple update from the MACv1 code ( < MACv1, > MACv2):
< #if defined(STM32_MAC_DMABMR_SR)
< ETH->DMABMR |= ETH_DMABMR_SR;
< while (ETH->DMABMR & ETH_DMABMR_SR)
---
>
> ETH->DMAMR |= ETH_DMAMR_SWR;
> while (ETH->DMAMR & ETH_DMAMR_SWR) //<<<<<< loops here
325d337
< #endif

and the docs page 2906:
DMA mode register (ETH_DMAMR)
Bit 0 SWR: Software Reset
When this bit is set, the MAC and the DMA controller reset the logic and all internal registers of
the DMA, MTL, and MAC. This bit is automatically cleared after the reset operation is complete
in all clock domains. Before reprogramming any register, a value of zero should be read in this
bit.
Note: The reset operation is complete only when all resets in all active clock domains are
deasserted. Therefore, it is essential that all PHY inputs clocks (applicable for the
selected PHY interface) are present for software reset completion. The time to complete
the software reset operation depends on the frequency of the slowest active clock.

So I suspect clocks or DMA as these are the main differences compared with the F4 and F7 range (I have several working).

Mike

[mikeprotts]

Still struggling, but I've also been able to get a demo of CycloneTCP working, so I know the hardware's good (no reason to doubt it, but always good to check).

It seems MACv1 to MACv2 is not a trivial change, but I'll keep working on it.

Mike

[mikeprotts]

Yet another version, still incomplete but getting closer. The LWIP thread is using some CPU, so there's probably some code I can trace now.

I worked out that my issue with DMA reset hang was due to incorrect setting of SYSCFG_PMCR MII/RMII bits (there are now three bits, but only two valid settings). I've just used separate SYSCFG_PMCR_EPIS_SEL_0 1 & 2 bits for now, but I think a better setting might be to have SYSCFG_PMCR_EPIS_RMII and SYSCFG_PMCR_EPIS_MII - I'll look when everything else works.

I think SYSCFG_PMCR_PA1SO may need to be set as well (links to ADC), but that doesn't make any difference at the moment.

Mike

[mikeprotts]

A brief summary of the change from MACv1 to MACv2.
The transmit and receive descriptors have changed a lot, not a simple one to one change, but several differences.

The model for using these, and the related data buffers, is now only ring mode. Previously it used ring and chain structures, with MACv1 using chain. Therefore I've swapped the 'next' pointers to use an index instead.

Most of the bits from [tr]des0 are now in [tr]des3

Some of the DMA settings are now split for transmit and receive.

RMII vs MII selection uses three bits instead of one.


I've followed the instructions from the document, starting at page 2801:
https://www.stmicroelectronics.com.cn/r ... ronics.pdf

The programming model starts at page 2870, and I've tried to follow that, but must have missed something. I'm probably not going to have much time to look at this over the next few days, so if someone has time to see if they can spot anything obvious I'd be grateful.

Mike

[mikeprotts]

Having had time to do a bit more testing with gdb.

At startup a transmit descriptor is requested before the link is active, so the code ignores the request. A receive descriptor is then requested, when the link is up.

The link detection seems to partly work. When the link is detected a transmit descriptor is requested, written and then released. This happens shortly after startup, and again if the network is disconnected and reconnected. However I don't think it's working every time, certainly not if I unplug and replug the cable quickly.

I don't see any output on the TX pins, but it may just get missed by the oscilloscope as it's likely to be a short burst of data. There is no visible network activity (as seen by tcpdump). The ref clock is running correctly.

So I think most of the initialisation is correct, but not all. I'm not sure if I've correctly tied the buffers to the descriptors, and whether I've fully understood the descriptor processing.

Mike

[Giovanni]

Thanks for the update.

When I first wrote MACv1 I debugged by keeping it under continuous ping (with the whole lwIP on top...) that allowed me to find a lot of problems. Of course at least some basic functionality is needed.

I also did stress test with multiple pings with increasing packet size, packet loss is the indicator for problems.

Giovanni

[piers]

- Fixes in driver caused by changes in REV-Y devices.
- Compatibility mode for old REV-V devices (400MHz).

I think you made a mistake here, or I understand it wrongly. The REV-V is the newer 480MHz revision, the REV-Y the older (now obsolete?) one. Maybe good to edit this post to not increase confusion.

As REV-Y should be obsolete by now, it would be nice to make REV-V the default. Also only H743, 753 and 750 have these revision differences, others H7 like H755 are all similar to REV-V, so would always need the STM32_ENFORCE_H7_REV_V flag to works well.

Maybe make an STM32_ENFORCE_H7_REV_Y flag instead? And include that in mcuconf.h instead of in the Makefile?

As for the Nucleo H743 board: As I understand it the ZI2 version has the REV-V and the ZI version the REV-Y. See https://github.com/stm32duino/Arduino_C ... issues/653
Maybe copy (or rename) os/hal/boards/ST_NUCLEO144_H743ZI to ST_NUCLEO144_H743ZI2, and add STM32_ENFORCE_H7_REV_V to board.h, so it can go out of the Makefile. I guess that needs a setting in the board.chcfg files too. Or would mcuconf.h be a better place?

You might also rename demos/STM32/RT-STM32H743ZI_REV_V-NUCLEO144 to RT-STM32H743ZI2_REV_V-NUCLEO144 or even RT-STM32H743ZI2-NUCLEO144, to make it more clear that the ZI2 version is REV-V.

Thanks for the great work!

[Giovanni]

Thanks, it is better to post this kind of things in the bug reports section, it is where I usually look for things to be done.

Giovanni

[piers]

Ok, posted it there in a bit more bug report format.