Problems after updating to latest master (reproduced in IDF example code)

[permal]

Hi,

So a month spent on designing some hardware, I'm now back to continue working on my software. Since the pthread-support has been added to IDF, I've updated to the latest IDF-master and the latest xtensa-gcc (xtensa-esp32-elf-linux64-1.22.0-73-ge28a011-5.2.0).

The update process itself went fine, but I am now experiencing garbage being printed to the monitor and complete application hangups - no crash dump being printed.

V (436) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): checking args
V (440) intr_alloc: esp_intr_alloc_intrstatus (cpu 0): Args okay. Resulting flags 0xE
D (448) intr_alloc: Connected src 49 to int 17 (cpu 0)
D (1235) event: SYSTEM_EVENT_STA_CONNECTED, ssid:Our place, ssid_len:9, bssid:f0:9f:c2:aa:b0:3f, channel:11, authmode:3
V (1236) event: enter default ca��KV֬��WL�
q Q&&MLJ�Y�Y��: exit default callback
V (1243) Application: ESP32 station`cϹ���ѕ����)գ+L[

I've looked through the commit log for hints on what could cause this, but I've not really found anything except that there seems to have been a few errors regarding the pthread-support. I also had a look at the current issues, but didn't find anything seemingly related.

This code ran fine before recompiling with the new IDF/gcc. It seems to be a threading issue since running only the main thread seems to work fine.

Any help will be welcome, I'm at loss at the moment.

[kolban]

In situations like this, I usually try two quick tests:

1. Delete the build directory which causes everything to be rebuilt
2. Replace the SDKCONFIG with a new one from a fresh template and re-make any necessary changes that you originally made

[permal]

If it only had been something that simple...its not, however.

[permal]

Problems seems to be related to WiFi. I've minimized my app and as soon as I start WiFi, I get this, with a complete hang:

D (1441) tcpip_adapter: dhcp client init ip/mask/gw to all-0
D (1447) tcpip_adapter: if0 start ip lost tmr: enter
D (1452) tcpip_adapter: if0 start ip lost tmr: no need start because netif=0x3ffc����J��+ɱ�a��J���ڴj5R"B����J�����}�W.W�.' dhcp�ƥ��с�х��H�]�cessfully[�jH��&��rJ����}����ѕ��l+�
R�-HZw �ݥ���������B:�ٕ������j5R"B��:��JH���%�}��.W�.'H��eck: remo��� )�V�2����C������Hh�j5R�B����J*ٕ���*��с"����bс���KV�X�F+L[C�� (1h82)
��%��ѥ�����*�&&H.]��i޹������ѕ���=�
Am��j5�

[WiFive]

Can you reproduce with any idf example code?

[permal]

Can you reproduce with any idf example code?

I haven't tried yet. It's too early to point fingers

[permal]

I can actually reproduce it with an IDF-example!

IDF-hash: de750e99214a51c1bcfdb42b5ada931652a3c531
xtensa-gcc: xtensa-esp32-elf-linux64-1.22.0-73-ge28a011-5.2.0.tar.gz

Here is the out from iperf, with verbose logging enabled:

query
query WiFi info

restart
Restart the program

iperf [-sua] [-c <ip>] [-p <port>] [-i <interval>] [-t <time>]
iperf command
-c, --client=<ip> run in client mode, connecting to <host>
-s, --server run in server mode
-u, --udp use UDP rather than TCP
-p, --port=<port> server port to listen on/connect to
-i, --interval=<interval> seconds between periodic bandwidth reports
-t, --time=<time> time in seconds to transmit for (default 10 secs)
-a, --abort abort running iperf

esp32> sta "My SSID" MyPassword
I (14496) iperf: sta connecting to 'Our place'
D (14498) event: SYSTEM_EVENT_STA_START
V (14499) event: enter default callback
D (14510) tcpip_adapter: check: local, if=0 fn=0x40113ab0
0x40113ab0: tcpip_adapter_start_api at /home/permal/esp/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:935


D (14511) tcpip_adapter: call api in lwip: ret=0x0, give sem
D (14522) tcpip_adapter: check: remote, if=0 fn=0x40113ab0
0x40113ab0: tcpip_adapter_start_api at /home/permal/esp/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:935


V (14523) event: exit default callback
D (15301) event: SYSTEM_EVENT_STA_CONNECTED, ssid:Our place, ssid_len:9, bssid:f0:9f:c2:aa:b0:3f, channel:11, authmode:3
V (15303) event: enter default callback
D (15314) tcpip_adapter: check: local, if=0 fn=0x40113d00
0x40113d00: tcpip_adapter_up_api at /home/permal/esp/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:935


D (15315) tcpip_adapter: call api in lwip: ret=0x0, give sem
D (15326) tcpip_adapter: check: remote, if=0 fn=0x40113d00
0x40113d00: tcpip_adapter_up_api at /home/permal/esp/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:935


D (15327) tcpip_adapter: check: local, if=0 fn=0x401141b4
0x401141b4: tcpip_adapter_dhcpc_start_api at /home/permal/esp/esp-idf/components/tcpip_adapter/./tcpip_adapter_lwip.c:935


D (15338) tcpip_adapter: dhcp client init ip/mask/gw to all-0
D (15338) tcpip_adapter: if0 start ip lost tmr: enter
D (15349) tcpip_adapter: if0 start ip lost tmr: no need start because netif=0x3ffce834 interval=120 ip}ӣ+L3
�
B(1Z��'�JH�,\Z��+W�.'HY�,\H,[ZY�� start su

[permal]

I made a local copy of the iperf example to be able to run the same test in older IDF versions and downgraded IDF as far back as commit b70329040d974507a442a46d424b7ee7dbc563d4 Sep 13, 2017 at which the problem still remains. I can't go further back than that as I don't have access to older versions of the xtensa-gcc tool chain.

[jsurfage]

The other thing I've done is erase the flash and then return the image...

[permal]

The other thing I've done is erase the flash and then return the image...

Tried that, didn't help.

Anyone else who has tried the iperf example with the latest xtense-gcc and latest IDF master?