[DEV] STM32H7xx support (new)

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
mikeprotts
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Wed Jun 17, 2020 10:12 am

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
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Wed Jun 17, 2020 7:49 pm

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
Attachments
MACv2.tgz
(200 KiB) Downloaded 3 times

mikeprotts
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Thu Jun 18, 2020 4:39 pm

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
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Mon Jun 22, 2020 2:43 pm

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
Attachments
MACv2.tgz
(200 KiB) Downloaded 2 times

mikeprotts
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Wed Jun 24, 2020 1:26 pm

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
Attachments
MACv2.tgz
(35.09 KiB) Downloaded 4 times

mikeprotts
Posts: 141
Joined: Wed Jan 09, 2019 12:37 pm
Has thanked: 16 times
Been thanked: 21 times

Re: [DEV] STM32H7xx support (new)

Postby mikeprotts » Wed Jun 24, 2020 9:46 pm

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

User avatar
Giovanni
Site Admin
Posts: 12947
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 731 times
Been thanked: 609 times
Contact:

Re: [DEV] STM32H7xx support (new)

Postby Giovanni » Wed Jun 24, 2020 9:56 pm

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

User avatar
piers
Posts: 34
Joined: Fri Apr 06, 2012 1:02 am
Location: Netherlands
Been thanked: 11 times
Contact:

Re: [DEV] STM32H7xx support (new)

Postby piers » Thu Jun 25, 2020 1:25 pm

Giovanni wrote:- 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!

User avatar
Giovanni
Site Admin
Posts: 12947
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 731 times
Been thanked: 609 times
Contact:

Re: [DEV] STM32H7xx support (new)

Postby Giovanni » Thu Jun 25, 2020 2:26 pm

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

User avatar
piers
Posts: 34
Joined: Fri Apr 06, 2012 1:02 am
Location: Netherlands
Been thanked: 11 times
Contact:

Re: [DEV] STM32H7xx support (new)

Postby piers » Thu Jun 25, 2020 4:10 pm

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


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 3 guests