Hi,
Most probably we need to trace when network init is done. Usually in the
early stages the "# define showprogress(c) arm_lowputc(c)" and
"arm_lowputs" is used to trace the init process, so maybe you can
instrument the code to find out what is going on.
Best regards,
Petro
чт, 19 трав. 2022 р. о 22:15 Nathan Hartman <hartman.nat...@gmail.com> пише:
> On Thu, May 19, 2022 at 12:40 PM Sebastien Lorquet <sebast...@lorquet.fr>
> wrote:
> >
> > Hi,
> >
> > I have a nucleo-h743zi, in which I have enabled network.
> >
> > It seems to work so far.
> >
> > When I enable Network Info Debug, I get a crash.
> >
> > The crash does not happen with Network info disabled (Enabling network
> > warnings and errors is ok)
> >
> > I am writing on the mailing list to get feedback and discussion.
> >
> > Here is the crash, pretty obvious cause:
> >
> > A▒DE
> > stm32_ethinitialize: intf: 0
> > stm32_ifdown: Taking the network down
> > netdev_register: Registered MAC: 2e:7e:27:a2:69:88 as dev: eth0
> > up_assert: Assertion failed at file:init/nx_start.c line: 703 task: Idle
> > Task
> >
> > First of all I dont know where this MAC is obtained but whatever, thats
> > not my problem. I will put the real mac later.
> >
> >
> > Note that nx_start is a pretty general file for nuttx, not related to
> > board or chip.
> >
> > (gdb) break nx_start.c:703
> > Breakpoint 1 at 0x8002b9a: file init/nx_start.c, line 703.
> > Note: automatically using hardware breakpoints for read-only addresses.
> > (gdb) mon reset init
> > SWD DPIDR 0x6ba02477
> > target halted due to debug-request, current mode: Thread
> > xPSR: 0x01000000 pc: 0x080002e0 msp: 0x240059fc
> > (gdb) c
> > Continuing.
> >
> > Breakpoint 1, nx_start () at init/nx_start.c:703
> > 703 DEBUGVERIFY(group_setupidlefiles(&g_idletcb[i]));
> > (gdb) s
> > group_setupidlefiles (tcb=0x24001114 <g_idletcb>) at
> > group/group_setupidlefiles.c:61
> > 61 FAR struct task_group_s *group = tcb->cmn.group;
> > (gdb) n
> > 66 DEBUGASSERT(group != NULL);
> > (gdb) n
> > 74 fd = nx_open("/dev/console", O_RDWR);
> > (gdb) n
> > 75 if (fd == 0)
> > (gdb) n
> > 88 if (fd > 0)
> > (gdb) n
> > 98 return -ENFILE;
> >
> > =>assert
> >
> > This function group_setupidlefiles fails to open /dev/console and
> > triggers an assert.
> >
> > Now please dont tell me that this code will work when I remove debug, I
> > dont care. This is not the root cause.
> >
> >
> > Does this code fails to open the console because some network debug has
> > been emitted first?
> >
> > What to do, then?
> >
> > It is pretty common to have boards emit debug messages before the OS is
> > started. I cant believe I'm the only one that will see this.
> >
> > It seems to happen before I have CONFIG_DEV_CONSOLE, which is the
> > default, and is ok, since i'm just using a serial port with this board.
> >
> > If I disable CONFIG_DEV_CONSOLE, then nsh does not start, so I believe
> > this setting is required.
> >
> > USB console is not enabled nor planned to be used.
> >
> >
> > Can you please help me understand and fix this?
> >
> > It does not look to be recent code.
>
>
> Unfortunately I don't know the cause, but I have actually run into a
> rather similar problem just a few days ago. In my case it's on Tiva
> platform (armv7m-based) and there is an assertion failure related in
> some way to the console device. In my case, the board is a custom
> board that does not have a serial console (though it does have a UART
> which controls an another chip). For everything else, this board has
> only network connectivity. For the time being I have worked around the
> crash by disabling a bunch of Kconfigs. I didn't know it was the
> network debugging but I do remember that being one of the Kconfigs I
> turned off. I will try to look at the specific areas you mentioned and
> I'll post back if I figure out what's going on with that. It might
> take me a few days though. Inundated with other work at the moment...
>
> Nathan
>
