STM32F4 default config keeps restarting

[ThePiGrepper]

Using arm/stm32f4-discovery default configuration, immediately after exec'ing tish and showing the prompt, it show the following error and restarts.

Started shell [tish] on device [diag]
loading start script:
(...)
> ifconfig lo 127.0.0.1 netmask 255.0.0.0 up
> route add 127.0.0.0 netmask 255.0.0.0 lo
> ifconfig eth0 192.168.1.128 netmask 255.255.255.0 hw ether AA:BB:CC:DD:EE:02 up
> route add 192.168.1.0 netmask 255.255.255.0 eth0
embox>

  ______
 |  ____|                                            __          __
 | |___  _ __ ___            ____  ____  ____  _____/ /   _____ / /
 |  ___|| '_ ` _ \          / __ \/ __ \/ __ \/ ___/ /   |_____| |
 | |____| | | | | |_ _ _   / /_/ / /_/ / /_/ (__  )_/    |_____| |
 |______|_| |_| |_(_|_|_)  \____/\____/ .___/____(_)           | |
                                     /_/                        \_\
 ASSERTION FAILED on CPU 0
        at src/kernel/irq.c:163
        in function irq_dispatch

irq_stack_protection() == 0

        (Stack overflow detected on irq dispatch)
Embox kernel start
        unit: initializing embox.arch.arm.fpu.fpv5:
(...)

After bisecting the tree, the bug started at:
8474757 : third-party: Porting new version of linenoise

Obs:
There are two different observable behaviors:
The one explained previously happens after 8474757, and before 4d092c5: drivers: Refactor cortexm systick.
It changes after 4d092c5, showing the following instead:

> ifconfig lo 127.0.0.1 netmask 255.0.0.0 up
> route add 127.0.0.0 netmask 255.0.0.0 lo
> ifconfig eth0 192.168.1.128 netmask 255.255.255.0 hw ether AA:BB:CC:DD:EE:02 up
> route add 192.168.1.0 netmask 255.255.255.0 eth0

done
runlevel: init level is 3

apparently, leaving 'gracefully' the shell, however leaving the system without ways of interacting with it anymore.

Just reverting 8474757 serves as a workaround, however 4d092c5 probably implies a different bug is occurring.

[anton-bondarev]

@ThePiGrepper Thanks a lot.
I think that fixed it in #1979

[ThePiGrepper]

indeed. that should fix it. 👍
there's still the issue of 4d092c5 though. I find it quite strange that the following lines:

-void (*cortexm_external_clock_hnd)(void);
(...)
-       if (cortexm_external_clock_hnd) {
-               cortexm_external_clock_hnd();
-       }

inside the systick IRQ handler actually make it stop rebooting, instead reaching level 3.
do you know why is that?

[ThePiGrepper]

@ThePiGrepper Thanks a lot.
I think that fixed it in #1979

hm, apparently it doesnt fix it after all. I cherry-picked the commit from master and it manages to reach prompt fine, however it doesnt handle <return> correctly.

[anton-bondarev]

@ThePiGrepper Thanks a lot.
I think that fixed it in #1979

hm, apparently it doesnt fix it after all. I cherry-picked the commit from master and it manages to reach prompt fine, however it doesnt handle correctly.

Hm, It's odd. But I think It's another problem. It's a pity I have not stm32f4 today, only stm32f7 . I checked on it and all work correctly. Can you investigate the trouble more deeply? Rollback to the next after " third-party: Porting new version of linenoise" and cherry-pick diff from #1979

[ThePiGrepper]

@ThePiGrepper Thanks a lot.
I think that fixed it in #1979

hm, apparently it doesnt fix it after all. I cherry-picked the commit from master and it manages to reach prompt fine, however it doesnt handle correctly.

Hm, It's odd. But I think It's another problem. It's a pity I have not stm32f4 today, only stm32f7 . I checked on it and all work correctly. Can you investigate the trouble more deeply? Rollback to the next after " third-party: Porting new version of linenoise" and cherry-pick diff from #1979

Ok, I will. it's weird that it only happens with the stm32f4, and not with the f7 though. btw, do you have an idea of why this happened?

there's still the issue of 4d092c5 though. I find it quite strange that the following lines:

-void (*cortexm_external_clock_hnd)(void);
(...)
-       if (cortexm_external_clock_hnd) {
-               cortexm_external_clock_hnd();
-       }

inside the systick IRQ handler actually made it stop rebooting, and now it just reaches level 3.
do you know why is that?

[anton-bondarev]

@ThePiGrepper Let's try to separate issues (terminal and clock)
Can you create a new issue for cortexm systick? Just copy into a new issue.

About linenoise trouble. Did you revert commits until the new version of linenoise and cherry-pick diff from #1979? Did the problem reproduce?

[ThePiGrepper]

@ThePiGrepper Let's try to separate issues (terminal and clock)
Can you create a new issue for cortexm systick? Just copy into a new issue.

About linenoise trouble. Did you revert commits until the new version of linenoise and cherry-pick diff from #1979? Did the problem reproduce?

the clock 'issue' I dont know if I would even consider an issue. I'm just curious about how something like those three lines can change the behavior of the breakage. Probably @alexkalmuk knows, because he removed those lines.
Nevertheless, putting that aside. Regarding the linenoise issue, I did what you suggested,

Hm, It's odd. But I think It's another problem. It's a pity I have not stm32f4 today, only stm32f7 . I checked on it and all work correctly. Can you investigate the trouble more deeply? Rollback to the next after " third-party: Porting new version of linenoise" and cherry-pick diff from #1979

and it behaves just the same as it does in master after patching. it mishandles <return>, it just treats it as a regular '\n' character instead of actually signaling the shell to start executing the command line.

[alexkalmuk]

@ThePiGrepper Hi! I do not have the cable to see the serial output on F4 right now, sorry.

As far as I understand, removing

-void (*cortexm_external_clock_hnd)(void);
(...)
-       if (cortexm_external_clock_hnd) {
-               cortexm_external_clock_hnd();
-       }

leads to F4 rebooting? When? After route add 192.168.1.0 netmask 255.255.255.0 eth0 executed?

UPD.

If these 3 lines really help, could you please set a breakpoint inside this if to check if cortexm_external_clock_hnd really called.

[ThePiGrepper]

@ThePiGrepper Hi! I do not have the cable to see the serial output on F4 right now, sorry.

As far as I understand, removing

-void (*cortexm_external_clock_hnd)(void);
(...)
-       if (cortexm_external_clock_hnd) {
-               cortexm_external_clock_hnd();
-       }

leads to F4 rebooting? When? After route add 192.168.1.0 netmask 255.255.255.0 eth0 executed?

UPD.

If these 3 lines really help, could you please set a breakpoint inside this if to check if cortexm_external_clock_hnd really called.

That's the weirdest part, I did add a printk() inside the if statement and it actually doesnt enter at all. I just did the test again(you can do it on top of master as well, you only need to add those 4 lines back to src/drivers/clock/cortexm_systick.c with the printk() line inside the if() and change LINENOISE_MAX_LINE back to 4096), and it indeed changes the behavior of the bug.
Should we just ignore it without understanding the root of the behavior because it's already fixed at 6c5d3d5?

[anton-bondarev]

@ThePiGrepper Please try to modify your conf/mods.config with

	//include embox.init.setup_tty_diag
	@Runlevel(3) include embox.init.start_script(shell_name="tish", tty_dev="ttyS0")

and check console input

[ThePiGrepper]

@ThePiGrepper Please try to modify your conf/mods.config with

	//include embox.init.setup_tty_diag
	@Runlevel(3) include embox.init.start_script(shell_name="tish", tty_dev="ttyS0")

and check console input

It's not that. all input is detected normally. the issue happens when I send <return> and instead of treating it like the line delimiter, it just treats it as a regular character, echoing it (going to nextline).

[anton-bondarev]

@ThePiGrepper I want to localize the problem
As I wrote I haven't any stm32f4-discovery today, but I have stm32f7 which working. I analyzed what's different between them, and think that they use different tty (f4 diag serial tty and f7 ttyS0). So I changed my conf/mods.config for f7 board

	@Runlevel(3) include embox.init.start_script(shell_name="tish", tty_dev="ttyS0", shell_start=1, stop_on_error=true)

with

	include embox.init.setup_tty_diag
	@Runlevel(3) include embox.init.start_script(shell_name="tish")

and reproduced behaviour which you described in the issue

The difference between diag and ttySx is that ttySx-s use interrupts but diag-s not.

I'm trying to solve the problem, and if you checked ttyS0 on your board you would help me very much. The information whether it is the same problem or not will be very useful for me :)

[ThePiGrepper]

@ThePiGrepper I want to localize the problem
As I wrote I haven't any stm32f4-discovery today, but I have stm32f7 which working. I analyzed what's different between them, and think that they use different tty (f4 diag serial tty and f7 ttyS0). So I changed my conf/mods.config for f7 board

	@Runlevel(3) include embox.init.start_script(shell_name="tish", tty_dev="ttyS0", shell_start=1, stop_on_error=true)

with

	include embox.init.setup_tty_diag
	@Runlevel(3) include embox.init.start_script(shell_name="tish")

and reproduced behaviour which you described in the issue

The difference between diag and ttySx is that ttySx-s use interrupts but diag-s not.

I'm trying to solve the problem, and if you checked ttyS0 on your board you would help me very much. The information whether it is the same problem or not will be very useful for me :)

oops, sorry, I forgot to say that I did test what you asked, and there's no difference. sorry for the confusion.

[anton-bondarev]

Oh, sorry. I undertood now. Thanks a lot!

[anton-bondarev]

@ThePiGrepper Look at #1990 please.

[ThePiGrepper]

@ThePiGrepper Look at #1990 please.

this solved the issue. :-)

[anton-bondarev]

@ThePiGrepper Thanks
I've merged it to master