Re: STM32H7 ethernet hardfaults
Wow, nice! Thank you guys!
David, nice description of the descriptors, it looks like zero padding is
being done by the MAC.
Do you guys have any iperf numbers for UDP on H7?
On Fri, Mar 5, 2021 at 7:15 AM John Rippetoe
wrote:
> Wow, that was fast David! Good find
; > CONFIG_NET_ETH_PKTSIZE. All should be happy now. :)
> >
> > https://github.com/apache/incubator-nuttx/pull/2985
> >
> > -Original Message-
> > From: David Sidrane [mailto:david.sidr...@nscdg.com]
> > Sent: Friday, March 05, 2021 1:26 AM
> &
That “thing i quoted” *was* the ethernet spec - THE NORMAL STANDARD
- the latest version 802.3-2018 going for about $1000 USD.
And like I said, there is no such thing as a "Jumbo" frame, it's not
IEEE standard, the spec shows that also.
therefore saying "it's already a jumbo frame" is meaningless
oal now is to harden the driver.
1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: R
7;dev@nuttx.apache.org'
Subject: RE: STM32H7 ethernet hardfaults
Hi,
Thank you all for sharing your Networking and dcache expertise!
The descriptors and buffers are all aligned and sized for the dcache line
size.
The problem is the following. (The value of number do not matter, but help
express the nat
On 2021-03-05 05:35, James Dougherty wrote:
Technically, the MTU should be 1496 of you use VLANs, or else it's
actually already a jumbo frame. The total size according to the ethernet
spec is really 1518. Larger are not allowed. VLAN information is
actually a part of the payload.
Yes, 1518 is
river.
1) Discard frames (all segments) grater then the size of one buffer.
2) Fix the invalidation.
David
-Original Message-
From: Gregory Nutt [mailto:spudan...@gmail.com]
Sent: Thursday, March 04, 2021 5:01 PM
To: dev@nuttx.apache.org
Subject: Re: STM32H7 ethernet hardfaults
>
Yes, that's true. very good discussion. I bring this up since you can do
whatever you want on a point to point link.
For maximum compatibility, using 1500 or 1518 will help you handle all of
the cross-network cases
where you cross a bridge/switch or gateway.
The other unintended side-effect of thi
Technically, the MTU should be 1496 of you use VLANs, or else it's
> actually already a jumbo frame. The total size according to the ethernet
> spec is really 1518. Larger are not allowed. VLAN information is
> actually a part of the payload.
>
>
Yes, 1518 is the size, true. But VLANS are not part
On 2021-03-05 00:21, Gregory Nutt wrote:
On 3/4/2021 4:59 PM, James Dougherty wrote:
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big
Technically, the MTU should be 1496 of you use VLANs, or else it's
actually already a jumbo frame. The total size according to the ethernet
spec is really 1518. Larger are not allowed. VLAN information is
actually a part of the payload.
Also, if we have a length field, then it's an 802.3 frame
My question for Greg was: Is there an assumption that CONFIG_NET_ETH_PKTSIZE
has to be 1514? So that ultimately a frame must be received completely into
one buffer?
Search for packet and frame in the Ethernet section of the reference
manual. The hardware will DMA up to (I think it was) 2048
len);
David
-Original Message-
From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
Sent: Thursday, March 04, 2021 12:46 PM
To: dev@nuttx.apache.org
Subject: STM32H7 ethernet hardfaults
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaul
On 3/4/2021 4:59 PM, James Dougherty wrote:
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a l
Thank you, that is interesting. Doesn't it also imply is that with the
smaller MTU of 590 you'll end up having
fragmentation which will add a little bit of processing overhead? I
understand it is not that big of a deal since
fragmentation happens a lot, but for the best performance yes, both sides
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
One thing I am wondering is if you have properly set up the MAC address
filtering. For TCP, each peer a
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
I think this behavior is pretty clear from reading the H7 reference
manual. The H7 Ethernet MAC supports only three maximum packet size,
standard (1518 or 1522 if tagged), 2K, and Jumbo (9018 or 9022 if
tagged). The Jumbo packet selection is controlled by settings in registers.
So while 590
Disabling DMA is not a option on most Ethernet MACs.
On 3/4/2021 3:00 PM, Alan Carvalho de Assis wrote:
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a
John, to answer your question on ethernet, 1500 is a very common MTU. For
VLAN tagged frame support (802.1Q VLAN ID ), 1518 bytes (1522 bytes on the
wire with 4-byte / 32-bit ETH CRC32), for Jumbo frames (not IEEE) 9122 is
common. Minimum frame size with CRC is 64-bytes and zero padding is common,
Hi John,
You can check this very useful post about Hardfault in Cortex M in the
follow link:
-
https://cwiki.apache.org/confluence/display/NUTTX/Analyzing+Cortex-M+Hardfaults
Regards,
Oliver Miranda
Em qui., 4 de mar. de 2021 às 18:06, John Rippetoe <
jrippe...@roboticresearch.com> esc
Alan,
The MAC in the the H7 has it's own dedicated internal DMA, so I don't
think that disabling the system-wide DMA would have any effect. I can
give it a shot anyways though and report back!
Thanks for the suggestion.
- John
On 3/4/21 4:00 PM, Alan Carvalho de Assis wrote:
Hi John,
Did
Hi John,
Did you try to disable DMA support to see if the issue disappear?
I think other MCUs are using DMA for Ethernet too and this issue
didn't happen. So I think disabling DMA could be a valid test to find
out the root causes.
BR,
Alan
On 3/4/21, John Rippetoe wrote:
> Hello All,
>
> I've
Hello All,
I've been playing around with networking on the STM32H7 and am seeing
hardfaults that appear to be related to NET_ETH_PKTSIZE. From the log
below, the driver would appear to be dropping packets that are too large
to fit into the default packet size of 590. By increasing the packet
24 matches
Mail list logo
