[DEV] STM32H7xx support (new)

[Giovanni]

Good work, note that failures could depend on GPIO or clock settings, not necessarily the driver itself, careful there.

Giovanni

[mikeprotts]

A good point. I'll check my settings.

Mike

[mikeprotts]

I can't see anything obvious in my settings. I think my best bet is to compare to the F4 and F7 boards I'm using with the H7.

The section for PHY Station Management Agent (SMA), which is not a term I could find in either F746 or F767 documents, but it seems to be equivalent to Station Management Interface (SMI):

https://www.stmicroelectronics.com.cn/r ... ronics.pdf page 2845

https://www.st.com/resource/en/referenc ... ronics.pdf page 1532

https://www.st.com/resource/en/referenc ... ronics.pdf page 1769.

So I'll read those sections to see what's different. That may take a little time.

I've noticed I needed to add support for faster clock so added to hal_mac_lld.c (line 59) and the appropriate define at line 40, but no difference:
/* MII divider optimal value.*/
#if (STM32_HCLK >= 250000000)
#define MACMDIODR_CR ETH_MACMDIOAR_CR_Div124
#elif (STM32_HCLK >= 150000000)


Mike

[mikeprotts]

According to the doc for ETH_MACMDIOAR:
Bits 3:2 GOC[1:0]: MII Operation Command
This bit indicates the operation command to the PHY.
00: Reserved
01: Write
10: Post Read Increment Address for Clause 45 PHY
11: Read
When Clause 22 PHY is enabled, only Write and Read commands are valid.
Bit 1 C45E: Clause 45 PHY Enable
When this bit is set, Clause 45 capable PHY is connected to MDIO. When this bit is reset,
Clause 22 capable PHY is connected to MDIO

In the file stm32h743xx.h:7414

#define ETH_MACMDIOAR_MOC_Pos                         (2U)
#define ETH_MACMDIOAR_MOC_Msk                         (0x3UL << ETH_MACMDIOAR_MOC_Pos) /*!< 0x0000000C */
#define ETH_MACMDIOAR_MOC                             ETH_MACMDIOAR_MOC_Msk    /* MII Operation Command */
#define ETH_MACMDIOAR_MOC_WR_Pos                      (2U)
#define ETH_MACMDIOAR_MOC_WR_Msk                      (0x1UL << ETH_MACMDIOAR_MOC_WR_Pos) /*!< 0x00000004 */
#define ETH_MACMDIOAR_MOC_WR                          ETH_MACMDIOAR_MOC_WR_Msk /* Write */
#define ETH_MACMDIOAR_MOC_PRDIA_Pos                   (3U)
#define ETH_MACMDIOAR_MOC_PRDIA_Msk                   (0x1UL << ETH_MACMDIOAR_MOC_PRDIA_Pos) /*!< 0x00000008 */
#define ETH_MACMDIOAR_MOC_PRDIA                       ETH_MACMDIOAR_MOC_PRDIA_Msk /* Post Read Increment Address for Clause 45 PHY */
#define ETH_MACMDIOAR_MOC_RD_Pos                      (2U)
#define ETH_MACMDIOAR_MOC_RD_Msk                      (0x3UL << ETH_MACMDIOAR_MOC_RD_Pos) /*!< 0x0000000C */
#define ETH_MACMDIOAR_MOC_RD                          ETH_MACMDIOAR_MOC_RD_Msk /* Read */

I think this is the GOC bits called MOC - may be a different doc version? I think that PRD1A should actually be written as Pos (2U) and Msk (0x2UL ...) based on the above, but shouldn't make any difference in my case.

So I added those bits to the appropriate mii_read (ETH_MACMDIOAR_MOC_RD) & mii_write (ETH_MACMDIOAR_MOC_WR) functions, but no change in how far the code reaches, still fails on mii_find.

I've come across this note, so more settings for me to check:
https://community.st.com/s/article/FAQ- ... -STM32H7x3

Mike

[mikeprotts]

Maybe some progress.

In hal_mac_lld.c mii_read (stm32f7 version:
macp->phyaddr = i << 11U;
ETH->MACMIIDR = (i << 6U) | MACMIIDR_CR;

I think that 11 and 6 are the bit positions in the register, so I need to change them for H7:
macp->phyaddr = i << 21U;
ETH->MACMDIODR = (i << 16U) | MACMDIODR_CR;

But it would be cleaner to pick these values from the defines in stm32f743xx.h and stm32H743xx.h etc.

Am I correct?

It does seem to move me on to another problem with DMA, but that's progress.

Mike

[mikeprotts]

I've now got the code to the stage the network initialises, no comms yet, but that's progress . Latest code attached (so it can't get lost), but still not working.

Mostly the problems were the registers splitting and I needed to pick the right bits to split out to the right registers.

Mike

[Giovanni]

The MACv1 driver is quite old (good thing, never needed real rework), the ST headers were missing some constants at that time, of course it is fine to use existing definitions.

Giovanni

[mikeprotts]

My latest version now attached (includes the extra files that I've changed for the board and processor). A diff between MACv1 and MACv2 shows the changes, that are fairly limited.

I think I've now corrected the last of the registers. lwip and tcpip threads start but I don't see any activity, so most likely I've missed a configuration, or possibly a DMA issue.

There are a few questions.

In the MACv1 code, there are two places where poll registers have a value set with the comment /* Any value is OK */ - the DMA transmit and receive poll registers: ETH_DMATPDR & ETH_DMARPDR. That's probably not true for the replacement registers ETH_DMACTXDTPR & ETH_DMACRXDTPR whrere there are two bits reserved. I might have misunderstood this logic as it doesn't seem to be a direct replacement. Any suggestions welcome.
pages 2916 & 2924 of:
https://www.stmicroelectronics.com.cn/r ... ronics.pdf
page 1870 of:
https://www.st.com/resource/en/referenc ... ronics.pdf


In mac_lld_start there's a section #ifdef(STM32_MAC_DISABLE_TX_FLUSH) that seems to be a problem for me (never ending loop). Is that define a processor or board define (I just put it in the hal_mac_lld.c code for now).

If someone can sanity check my changes I'd be grateful. It's likely I've missed something, perhaps I've missed an important bitwise OR.

Mike

[Giovanni]

I remember a stuck loop because a GPIO problem, not sure if it is that one.

Do you get interrupts? if not it is very possible that PHY and MAC are not talking, again clocks or GPIO.

Giovanni

[mikeprotts]

I'll take a look at interrupts again. Interactive debug has gone as far as possible as it's at a wait state (according the the serial console thread information lwip WTOREVT and tcpip QUEUED) - having the main and serial threads working suggests nothing else is running. I need to put in some break points to see where it's got to.

Mike