In AP mode, ESP resets causing restart of punyforth

[RigTig]

Thanks to @zeroflag, who gave me support via esp8266.com I set up a dev board (ESP12E devkit by doit.com). It uses just the USB to supply power to the ESP module. For this test, I just let it boot into punyforth. Note that the punyforth has everything available from the release, not just the core. The setup is just the same as for that project to drive stepper (on hackaday.io). Even though the ESP does remember its IP information, I still load the three lines each time just to be consistent. 192 168 8 88 >ipv4 wifi-set-ip 1 3 0 AUTH_WPA2_PSK str: "1234567890" str: "avago" wifi-softap 4 192 168 8 100 >ipv4 dhcpd-start

Of course, I wait for the prompt '(stack)' before loading the next line, but he line sent is not echoed to the logfile. I've attached a sample log from about 10 minutes connection. Many thanks for looking at this, @zeroflag. The file has 8 fatal exceptions: 1 code (9) and 7 code (28). ESP12Edevkit6c27log.txt freemem . osfreemem . results in

8036(stack) 13456(stack)

PS in station mode, all works just fine. stable and all

[RigTig]

Thanks @zeroflag for hint about memory. So, I just used a few needed modules:

python2.7 modules.py gpio wifi netcon Chosen modules ['gpio', 'wifi', 'netcon'] Analyzing dependencies.. Modules with dependencies: ['core', 'gpio', 'wifi', 'ringbuf', 'tasks', 'netcon'] uber.forth ready. Use flash to install

When loaded, osfreemem . cr freemem . gives 13364 11060(stack) and after creating the dhcp server with 4 192 168 8 100 >ipv4 dhcpd-start gave 9800 11060(stack). No restarts after 30 minutes, so it is a memory issue after all. I'll let @zeroflag sort out the details, but at least I have a workable system to proceed with my big 3D printer (see hackaday.io/rigtig). Yoo Hoo!

[zeroflag]

Thanks @RigTig.

I made an object dump from the punyforth binary then checked the address where the crash happened (epc1=0x4020b154)

xtensa-lx106-elf-objdump -S build/punyforth.out > dump

At that address there is esp-sdk/rtos related timer function that receive timer events from queue. I found issue on the esp-open-rtos page: https://github.com/SuperHouse/esp-open-rtos/issues/140 which describes similar problems. This was fixed in this pull request: https://github.com/SuperHouse/esp-open-rtos/pull/221

I upgraded the esp-open-rtos and recompiled punyforth. Hopefully this will solve this issue as well.

@RigTig could you please try this again using the latest binary and core?

[RigTig]

Thanks @zeroflag. I've downloaded again and tried it on ESP-12-F module. Now it is not causing any restarts of the ESP module, at least. Unfortunately, no connections are stable. Please find attached a 2 minute log from attempts to connect from a laptop. ESPmodule6c29log.txt

Also when I also attempted to connect using another device, I got the message on the log 'max connection!'. I reloaded the three lines of the AP commands (even though only the last one is not permanently stored), but the same situation continued = failing to maintain connection on one and refusing the second. Looks like RTOS is not well-used in AP mode, and it is too hard for me to figure out. Over to you again, I am sorry to say.

[RigTig]

ESP very stable for over an hour. Do you want me to start a new issue for the AP connection refusal and 'max connection!' message?

[zeroflag]

It's ok to discuss this further in this issue. I see a possible workaround for the disconnects here

https://github.com/SuperHouse/esp-open-rtos/issues/140

I'll try this tomorrow.

I suspect the max connection warning message comes because you set the first parameter to 1. Have you tried setting it to more than one?

wifi-softap ( max-connections channels hidden authmode password ssid -- | throws:EWIFI )

[RigTig]

Mmm...I had assumed that the key number was the number of DHCP clients (line 3 below). I changed the number of connections to 5 (line 2 below) and got a very different outcome. Both clients now can connect, but are flaky. At best, they periodically disconnect and usually try reconnecting again. Often, cannot get even one to connect properly. I can send you some logs, but you might find testing yourself to be more useful so you can see what happens as you try to connect. Good luck with your RTOS bugs. If you need something from me, please let me know.

Please assist with some clarification of relationships. Am I correct in my new understanding that the maximum number of connections to AP must always be >= the number of supported DHCP clients. Alternatively, the maximum number of DHCP clients is the lesser of the maximum number of connections to AP and the number of supported DHCP leases.

192 168 8 88 >ipv4 wifi-set-ip 5 3 0 AUTH_WPA2_PSK str: "1234567890" str: "avago" wifi-softap 4 192 168 8 100 >ipv4 dhcpd-start

If so, I suggest two non-functional alterations to your code:

• modify all examples in comments (at least two I can remember)

• describe the relationship between max-connections in wifi-softap (also forth_wifi_set_softap_config) and max-leases in dhcpd-start (also forth_dhcpd_start)

[zeroflag]

I think the max_leases value should be higher (or equal) than the maximum number of allowed connections. If you allow let's say 4 connections, but the dhcp server can assign only 3 ip addresses then it won't work. I updated the readme and the comment in the code accordingly.

[zeroflag]

I uploaded a binary with the workaround:

https://github.com/zeroflag/punyforth/blob/master/arch/esp8266/bin/punyforth-ap-workaround.bin

Tried it with 2 clients and didn't experience disconnects. Could try it with this binary?

[RigTig]

Been away for a while, writing the code for the core GCODE interpreter to run on STM8S103F, based on eForth. I reckon the whole interpreter will run nicely on ESP14 with the two MCUs both running Forth (different versions). If you want to follow where I am up to, see https://hackaday.io/project/13420-rigtigs-big-3d-printer. Anyway, the github link above now gives 404 error, so I'll just download the latest release and give it a try so I can give you an update.

[zeroflag]

@RigTig thanks, that workaround is now part of the standard binary

https://github.com/zeroflag/punyforth/blob/master/arch/esp8266/rtos/user/forth_wifi.c#L9

[RigTig]

Thank you. Just getting some coding done for the ESP, with a lot of exploring of source Forth code. Great work you have done to put together this Forth, without which I have no hope of getting my project up to a minimum viable product. Its lots of fun (and a bit mind-bending) to have two Forths on one SoC working together.