Firmware release 1.7.3.b1

[robert-hh]

@peekay123 @daniel I simplified the test code further, since measuring the time is not in focus, and removed the flush statement. Then it ran up to 50000 iterations, before it keeled over. The sd card was empty before, and after the crash, the file showed a size of 0, even if 50 MBytes should have been written.

import os
import machine

sd = machine.SD()
os.mount(sd, '/sd')

f = open('/sd/test', 'w')
n = 0
k = bytearray(1024)

while True:
    f.write(k)
    n += 1
    print("Round", n)

[peekay123]

@robert-hh, the file shows as zero size since it never gets closed/committed, thus the reason for the flush(). One oddity I did not report is that on one run of 500K, TeraTerm seems to have frozen or it was the console output on the LoPy, I can't be sure which. On my latest code, I only print a "Round" statement every 1000 iterations.

[this.wiederkehr]

@daniel many thanks that you did look into the issues with the sd card!

@peekay123, @robert-hh I currently don't have the possibility to test this firmware myself (eagerly looking foreward to it :-) but as I have reported on the two earlier releases I had three different issues: two different errors (load prohibited with different stack trace) and the freeze/slow down of the of the interpreter which also manifested itself in the cycle time of the loop. Actually by calling flush only each five seconds I got rid of one error and the freezes/slow down.

[robert-hh]

@this.wiederkehr @peekay123 I have run a few test cycles with and without flush in the loop. My impression. It stays unstable. Some results:
Passes without flush()
~50000
~300
292095
Passes with flush()
~150
~1500
541827 (!)
~9000
~4500
Timing is an influencing factor, which could lead to a stable state if found.
One final test I'm going to make is the depedence on power supply. It might be that the coincidence of an SD card write and WiFi activity causes a short power drop. For that, I'll add a stable lab power supply not going through the USB connector, but soldered directly to the board.

[peekay123]

@robert-hh, are you using an expasion board or is the microSD wired independently. I am not seeing any of the issues you are seeing and my expansion board/LoPy is being powered by a USB port on a GOLE1 mini pc.

[robert-hh]

@peekay123 I'm using an expansion board plus USB supply. That was not a problem before. So checking the supply is just for completion.

[livius]

@daniel
I see now that firmware 1.7.4.b1 is available - what are the changes?

(sysname='WiPy', nodename='WiPy', release='1.7.4.b1', version='v1.8.6-679-g0aa833b4 on 2017-06-23', machine='WiPy with ESP32')

UPDATE
i see that pysense now work with Wipy2 :)

[this.wiederkehr]

@peekay123, @robert-hh I still found the sd-card issue with the most recent fw 1.7.5b2. Out of curiosity. While running the test did you guys have wlan enabled and connected to an ap? If yes with what security (wpa, wep, wpa2 or none)?

[robert-hh]

@this.wiederkehr I tested that with 1.7.5.b2 too, and found the same issue. Two runs, one until ~550000 = 550 MByte, the second up to ~20000 = 20 MByte. Yes, Wifi was enabled in STA mode, WPA2 encryption, but not used. I could make a test with WiFi disabled. I read from you question that you have the suspicion of e.g. a stack overflow in certain interrupt conditions. I support that.

[peekay123]

@robert-hh, @this-wiederkehr, I still don't have any kind of failure with 1.7.5.b2. I use USB power as well and have been using a Class 10 8GB microSD. I boot the LoPy with WiFi AP connected and I sync the RTC to via NTP prior to running the SD test. The test runs for 300K iterations and I never get failures.

[this.wiederkehr]

@peekay123 thanks for the additional information. what is the security mode of the wifi you are using to connect during the test wpa, wep, wpa2 or none?

[peekay123]

@this-wiederkehr, I am running WPA2.

[this.wiederkehr]

@peekay123 said in Firmware release 1.7.3.b1:

Class 10

Hmm, interesting. I think I was able to solve the problem with the sd-card by disabling CONFIG_MBEDTLS_HARDWARE_MPI in sdkconfig.h.

https://github.com/espressif/esp-idf/issues/630

According to the infos in this bug report this feature is buggy and also even slower than without the feature enabled. (It involves isr's so it might clash with others .. no clue).

However it only would make sense if in some way mbedtls would be involved, therefore the question regarding the wifi security mode.

The only left difference at that point is probably the network traffic on the wifi or the class of the sd card (mine is most likely slower, got to check).

[peekay123]

@this.wiederkehr, in my case, I have little traffic on the AP (only the link overhead). Any thoughts on how I can stress the AP while I run the test?

[this.wiederkehr]

@peekay123 hmm, the not very scientific approch is: connect to the ftp server of the pycom module with filezilla and put your finger on 'F5' ...

[peekay123]

@this-wiederkehr, with the latest 1.7.6.b1 firmware, the SD test fails after a number of writes. So far, it has failed between 5000 and 6000 writes (I only track thousands) and a second test failed between 34000 and 35000 writes. When I say fail, I mean the LoPy is no longer responsive on the serial console.

[robert-hh]

@this.wiederkehr @peekay123 @daniel It seems, as if with release 1.7.7.b1 this issue is gone. I ran the loop&write test three times up to 2 million passes = 2048000000 Bytes successfully, at which time it stopped intentionally to avoid writing more than 2 GB into a file.