[DEV] STM32H7xx support (new)

[mikeprotts]

A bit more of a clue, ping manages three sequential packets then drops some, which may be a DMA cache issue.

The bogus data in the ping response seems to start with the correct values, then hit a problem with either the marker values, or the response from the web server instead. This may be the ping overlaying and the length being incorrect.

The web pages always seem correct, but I can't drive them fast enough to tell - it's as if the transmit buffers are lower priority than receive, which may be the case - I need to check if allowing transmit to be higher priority would help as I'm sending more than I'm receiving,

The buffers (transmit and receive) seem to be updated in the correct order, but it would seem likely the transmit ones are being overwritten too fast. I've put in a lock as suggested but still seeing the problem.

More puzzles, but promising.

Mike

[Giovanni]

I suggest you avoid the web server initially, better focus on making ping work reliably. If that works with multiple pingers then everything else will likely work as well.

Giovanni

[mikeprotts]

It's getting close, and I'd like to know if it's correct for any other STM32H7 processors (I only have H743ZI).

When I was experimenting with extra buffers, they were too big for the nocache zone, so now back down to 4 each transmit and receive and the cache problem's avoided.

I've given transmit priority with 8:1 ratio against receive.

Ping now mostly working but a little bit erratic - it tends to send three responses at a time so not very realistic times. Note that the first one has been missed here:

Code: Select all

ping -c10 192.168.13.73
PING 192.168.13.73 (192.168.13.73) 56(84) bytes of data.
64 bytes from 192.168.13.73: icmp_seq=2 ttl=253 time=1025 ms
64 bytes from 192.168.13.73: icmp_seq=3 ttl=253 time=1.86 ms
64 bytes from 192.168.13.73: icmp_seq=4 ttl=253 time=2073 ms
64 bytes from 192.168.13.73: icmp_seq=5 ttl=253 time=1026 ms
64 bytes from 192.168.13.73: icmp_seq=6 ttl=253 time=3.12 ms
64 bytes from 192.168.13.73: icmp_seq=7 ttl=253 time=939 ms
64 bytes from 192.168.13.73: icmp_seq=8 ttl=253 time=2033 ms
64 bytes from 192.168.13.73: icmp_seq=9 ttl=253 time=1026 ms
64 bytes from 192.168.13.73: icmp_seq=10 ttl=253 time=2.73 ms

--- 192.168.13.73 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9156ms
rtt min/avg/max/mdev = 1.865/903.617/2073.730/754.773 ms, pipe 3


Web server responds well but still over a second sometimes, and occasional failure writing (something I normally only see if I stress the code on an F4 or F7 board). This suggests to me I may not be enabling the interrupts at the right point.

Mike

[mikeprotts]

I think I've done it . I had a duplicate increment section on the receive buffer index. Attached code can be considered as a candidate for MACv2.

Only tested on one board (ST_NUCLEO144_H743ZI) for ping, static IP and home written web server.

Mike

[mikeprotts]

I realised I should provide my relevant settings. This processor seems to want minimum 4 descriptors each for transmit & receive, and buffer length a multiple of 4.

Code: Select all

/*
 * MAC driver system settings.
 */
#define STM32_MAC_TRANSMIT_BUFFERS          4
#define STM32_MAC_RECEIVE_BUFFERS           4
#define STM32_MAC_BUFFERS_SIZE              1536
#define STM32_MAC_PHY_TIMEOUT               100
#define STM32_MAC_ETH1_CHANGE_PHY_STATE     TRUE
#define STM32_MAC_ETH1_IRQ_PRIORITY         5
#define STM32_MAC_IP_CHECKSUM_OFFLOAD       0


And the compiler:

Code: Select all

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]


Mike

[Giovanni]

Do you have a custom linker file for this?

Giovanni

[mikeprotts]

I've used the standard linker file from ChibiOS_20.3.1. I think my earlier archive included everything I've changed from within the source tree, apart from the change I posted earlier for using lwip without heap.

Attached includes Makefile (Makefile1), mcuconf.h, halconf.h and chconf.h

I have quite a lot enabled (ADC, SPI etc.) although not working yet - I concentrated on the MAC code first. My current problem (unrelated to MAC) is a failure with a simple strncpy (or memcpy), even when I use a simple character by character loop. I suspect a different memory access problem.

Mike

[mikeprotts]

A simplified test web server attached. Note the hard coded IP address 192.168.13.99 and locally administered MAC address 1e:1e:1e:1e:1e:1e.

There is a script for openocd (loadmyapp) and I use this version:
Open On-Chip Debugger 0.10.0+dev-00586-g42f1cc57 (2018-12-04-19:19)

I'm trying to work out my chip version.
Unique id: 884317Q1600098012
Markings:
STM32H743ZIT6U
7B864 VQ
PHL 7B 817

Mike

[mikeprotts]

If I've read this correctly, mine's a REV Y
DBGMCU_IDC 5C001000 10036450

https://www.st.com/resource/en/errata_s ... ronics.pdf

That may mean a bit of difference if using REV V, but I don't think there's anything too critical.

Mike

[Giovanni]

There changes coming for revision V and Y handling (i got those swapped, V is newer), after that I will try to integrate MACv2 in the normal lwIP demo and then see how it goes.

Giovanni