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
[DEV] STM32H7xx support (new)
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32H7xx support (new)
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
Giovanni
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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:
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
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
- Attachments
-
- MACv2.tgz
- (20.4 KiB) Downloaded 165 times
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
Only tested on one board (ST_NUCLEO144_H743ZI) for ping, static IP and home written web server.
Mike
- Attachments
-
- MACv2.tgz
- (20.41 KiB) Downloaded 174 times
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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.
And the compiler:
Mike
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
- Attachments
-
- test.tgz
- (11.47 KiB) Downloaded 181 times
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
- Attachments
-
- testmacv2.tgz
- (28.36 KiB) Downloaded 178 times
-
- Posts: 166
- Joined: Wed Jan 09, 2019 12:37 pm
- Has thanked: 19 times
- Been thanked: 31 times
Re: [DEV] STM32H7xx support (new)
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
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
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [DEV] STM32H7xx support (new)
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
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 24 guests