Issue with Linux 64 bits version (possibly 32 bits too)

[treepleks]

After having fought for 2 weeks to have a specific firmware running on an ESP01 module, I think I have nailed down an issue and it seems to be in the Linux 64 bits version of the distributed ESP 2.0.0.

The fimware I tried to run is https://github.com/luc-github/ESP8266 It's a wifi/web interface for 3D printers. By default, it will open an AP with name ESP8266 (pwd: 12345678, IP 192.168.0.1). Connecting there and authenticating yourself with login admin and password admin, you will be able to select various web pages including a Station and Access point web page.

I compiled and flashed the firmware (and associated SPIFFS) on a new (black) ESP01 with 1MB + 128kB SPIFFs using:

• Arduino 1.6.5, directly installed from the 64 bits tar.xz linux archive on Ubuntu Wily with ESP 2.0.0 installed from the Board Manager using the json file. and the SPIFFS uploader.
• Arduino 1.6.5, directly installed from the Windows installer on a VBox Windows 7 instance (running on the same Ubuntu machine) with ESP 2.0.0 installed from the Board Manager using the json file and the SPIFFS uploader.

On the Linux version, the firmware compiles, uploads fine, and the SPIFFS file too. The resulting ESP module runs very imperfectly. It systematically oops (exception 3) when either the "Station" or the "Access Point" web pages are accessed after authentification. I initially thought I had found a heap corruption bug then found many people advising for super stabilized hardware.

After 2 weeks of removing long wires, soldering 100nF decoupling and adding 470µF capacitors as well as 10 kOhm pull-up resistors, upgrading the power source to an external regulated source, changing the FTDI, buying new modules from different sources (all 1MB black), comparing new modules, I was surprised to see that...

From the Windows 7 version, the resulting ESP firmware runs fine!

It looks like there are discrepencies between the Windows and Linux 64 bit versions of the distributed ESP 2.0.0 packages. The Linux version is sometimes older and apparently still contains bugs that the Windows version does not.

By comparing the trees of both packages it appears that the hardware folder looks identical in both versions but some includes files in the tools folders have different versions. For example, the pthreads.h is 1.8 for linux and 1.9 for Windows. This leads me to think that thre may be libraries or binaries that are not of the same versions either. My current assumption is that this explains the problem under Linux. This may affect all Linux users AFAIK.

I haven't been beyond this point and I do not intend to but I will be available to produce more evidence if needed (mostly during week-ends). Just ask.

[igrr]

There was indeed a heap corruption bug which is now fixed in 2.1.0. Could you please try the latest version of the package? Regarding tools, toolset versions on Linux and OS X are identical so if there was an issue it would affect OS X users as well.

[luc-github]

I can reproduce issue also under linux when no problem under window with 2.1.0

Exception (3):
epc1=0x4000bf64 epc2=0x00000000 epc3=0x00000000 excvaddr=0x40246375 depc=0x00000000

ctx: cont 
sp: 3fff1450 end: 3fff18b0 offset: 01a0

>>>stack>>>
3fff15f0:  3ffe88d9 40245ca6 3fff1610 40218244  
3fff1600:  3ffe88d9 40245ca6 00000001 40207106  
3fff1610:  00000000 00000000 00000000 00000003  
3fff1620:  3ffe88d9 3fff0270 00000000 4020ddbe  
3fff1630:  ffffffff ffffffff 3ffe8468 0000001c  
3fff1640:  3fff5bac 3fff46ac 00000000 00000000  
3fff1650:  00000000 ffffffff ffffffff 3ffe8468  
3fff1660:  0000001d 3fff22fc 3fff46ec 00000000  
3fff1670:  00000000 00000000 40246447 4024643f  
3fff1680:  40246443 40246447 00000001 00000002  
3fff1690:  00000003 ffffffff 00000000 00000000  
3fff16a0:  00000000 00000000 00000000 00000000  
3fff16b0:  3fff0644 000003db 000003db 4010020c  
3fff16c0:  3fff0644 00000397 00000397 4010020c  
3fff16d0:  00000020 3fff37dc 3fff35b4 401008c8  
3fff16e0:  00ffffff 00000884 00000884 3fff5b4c  
3fff16f0:  0000000f 0000000b 3fff5b2c 0000000f  
3fff1700:  0000000d 3fff5b0c 0000000f 0000000b  
3fff1710:  3fff5aec 0000000f 0000000b 3fff5acc  
3fff1720:  0000000f 0000000e 3fff425c 0000001f  
3fff1730:  00000015 3fff379c 0000000f 00000000  
3fff1740:  3fff4374 0000006f 00000011 0100a8c0  
3fff1750:  0100a8c0 3fff0102 3fff17b0 4021829e  
3fff1760:  00000000 00000003 00000003 402182f6  
3fff1770:  3fff0644 000003e1 000003e1 40212160  
3fff1780:  00000001 00000001 3fff2f44 4021705a  
3fff1790:  00000000 00000866 3fff17b0 40212156  
3fff17a0:  3fff2f44 3fff23d8 3fff2f44 40212192  
3fff17b0:  00000000 00000000 00000000 4021844c  
3fff17c0:  3fff2f44 3fff23d8 3fff239c 40212225  
3fff17d0:  3fff35bc 0000000f 0000000a 4021074c  
3fff17e0:  3fff23d8 00000037 3fff0890 00000001  
3fff17f0:  00000001 00000006 40216c00 3fff0890  
3fff1800:  00000000 3fff0190 3fff239c 3fff1850  
3fff1810:  00000001 3fff23bc 3fff239c 402123fb  
3fff1820:  3ffe8d40 00000000 000003e8 401008c8  
3fff1830:  402387ae 3fff0879 00000000 3fffdad0  
3fff1840:  3fffdad0 3fff0190 3fff0879 4020fa39  
3fff1850:  00000000 00000000 00000000 00000000  
3fff1860:  00000000 00000000 3ffe8996 00002580  
3fff1870:  feefeffe feefeffe feefeffe feefeffe  
3fff1880:  00000000 00000000 00000001 3fff0880  
3fff1890:  3fffdad0 00000000 3fff0879 40216c4c  
3fff18a0:  feefeffe feefeffe 3fff0890 40100958  

I will try to generate a simple sketch to reproduce the issue, and give a try under osx

[igrr]

Thanks for the report, could you please decode the stack dump with https://github.com/me-no-dev/EspExceptionDecoder?

[luc-github]

Yes will do and report all when done

[luc-github]

I did not test OSX yet but here is the decode stack dump of the exception 3: I guess there is a way to export result but did not found it :disappointed: so I did a 2 screenshots and merged them

[luc-github]

@igrr I just tested this issue on 2.2.0 and still happen - I do not have OSX system available Same code works on windows when it crash if compiled under linux (linuxmint 17.1 64bits) - as ESP core is identical could issue come from tools ? I am willing to help to debug but no clue what direction take sorry

[igrr]

I will try to generate a simple sketch to reproduce the issue, and give a try under osx

@luc-github I've got a linux-64 system, can test. Do you have some simple sketch which reproduces this?

[luc-github]

Well that is the problem - I was not able to find yet - still trying to isolate what part of the code crash but it is inconsistent

[luc-github]

@igrr that all on me :blush: - I deserve the punishment :sweat: Sorry for the trouble....

I found some missing FPSTR that generate the crash - but it is weird crash happen only when compilation is done under linux and not under windows

I think you can close issue - I cannot as I am not owner