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> escreveu:

> 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 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 <jrippe...@roboticresearch.com> wrote:
> >> 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
> >> size to the max (1518), the problem seems to disappear, but I am a
> >> little confused why the driver is able to catch the fact that the
> >> received packet was too large and drop it appropriately, but then crash.
> >> After poking around the ethernet driver, I think I understand the issue
> >> to be that because the MAC DMA does not know that the buffer it is
> >> writing into has a size limit, it is overflowing the buffer and writing
> >> into adjacent memory. Am I understanding this correctly?
> >>
> >> My main concern here is that increasing NET_ETH_PKTSIZE to the limit
> >> will only hide the issue for a time instead of solving it. A quick
> >> google search does show that the maximum ethernet frame size is 1518
> >> bytes though, so I am working under the assumption that maxing it out in
> >> my config will account for all possible frame sizes and eliminate this
> >> issue. I have no experience with low level networking protocols and
> >> standards, so I thought it would be prudent to seek out additional help
> >> to make sure I am on the right track.
> >>
> >> Thanks in advance.
> >>
> >> - John
> >>
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1332
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 684
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1364
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1264
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1436
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> stm32_receive: WARNING: DROPPED Too big: 1300
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> ipv4_input: WARNING: Not destined for us; not forwardable... Dropping!
> >> up_hardfault: PANIC!!! Hard fault: 40000000
> >> up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148
> >> task: lpwork
> >> up_registerdump: R0: 24012080 2401206e 0000024e 00000000 24012000
> >> 40029160 24011fc0 00008040
> >> up_registerdump: R8: 40029134 24011f00 24011fe0 240120b8 00000001
> >> 38002f88 080a26a7 080a2538
> >> up_registerdump: xPSR: 81000000 BASEPRI: 000000f0 CONTROL: 00000000
> >> up_registerdump: EXC_RETURN: ffffffe9
> >> up_dumpstate: sp: 24010bb0
> >> up_dumpstate: IRQ stack:
> >> up_dumpstate:   base: 24010c00
> >> up_dumpstate:   size: 00000200
> >> up_dumpstate:   used: 00000140
> >> up_stackdump: 24010ba0: 24010bb0 2400e830 0000064c 080a0fed 000000f0
> >> 00000000 240120b8 00000001
> >> up_stackdump: 24010bc0: 38002f88 080a26a7 080a2538 0816625a 00000000
> >> 080a129f 080a1271 080f754f
> >> up_stackdump: 24010be0: 000000f0 080a2935 000000f0 38002eb4 40029160
> >> 24011fc0 00008040 080a1b8f
> >> up_dumpstate: sp: 38002f88
> >> up_dumpstate: User stack:
> >> up_dumpstate:   base: 38003008
> >> up_dumpstate:   size: 0000064c
> >> up_dumpstate:   used: 000003e0
> >> up_stackdump: 38002f80: 00000010 080a269b 24012050 24012000 00000000
> >> 24012010 2400b430 00000000
> >> up_stackdump: 38002fa0: 000000f0 00000080 00000000 00000000 00005ec8
> >> 0809d2e7 ffffffff ffffffff
> >> up_stackdump: 38002fc0: 00005ec8 00000001 00000010 00020000 39276cac
> >> 2400b430 00000000 00000000
> >> up_stackdump: 38002fe0: 00000000 00000000 00000000 00000000 00000000
> >> 0809c501 0809c4f1 0809bed5
> >> up_stackdump: 38003000: 00000000 00000000 deadbeef 38003014 00000000
> >> 6f77706c de006b72 7b93d153
> >> up_taskdump: Idle Task: PID=0 Stack Used=0 of 0
> >> up_taskdump: hpwork: PID=1 Stack Used=352 of 2028
> >> up_taskdump: lpwork: PID=2 Stack Used=992 of 1612
> >> up_taskdump: init: PID=3 Stack Used=1544 of 2980
> >>
> >>
> >> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential
> >> and privileged material for the sole use of the intended recipient. If
> you
> >> are not the intended recipient, please delete this e-mail and any
> >> attachments permanently.
> >>
> >>
> CONFIDENTIALITY NOTICE: This communication may contain private,
> confidential and privileged material for the sole use of the intended
> recipient. If you are not the intended recipient, please delete this e-mail
> and any attachments permanently.
>
>

Reply via email to