Firmware release 1.7.3.b1

[robert-hh]

@peekay123 Hello, Here's the little script, which by the way is the one @this.wiederkehr was using, with minor tweaks.

import machine
import os
import utime
import gc

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

f = open('/sd/test', 'a')
t1 = utime.ticks_ms()
n = 0
while True:

#    print('about to initialize buffer')
    k = bytearray(1024)
#    print('about to write to file')
    f.write(k)
#    print('about to flush to file')
    f.flush()
    t2 = utime.ticks_ms()
#    print("I'm done ", (t2-t1))
    t1 = t2
    gc.collect()
    n += 1
    print("Round", n, "\r", end="")

I did not see that there is a version 1.7.3.b2

[peekay123]

@robert-hh, thanks for the code. I'll get it to work with the expansion board. I only found out about the new firmware version when I ran the updater.

[peekay123]

@robert-hh, made minor adjustments to get it to work with latest firmware:

import machine
import os
import utime
import gc
from machine import SD

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

# check the content
os.listdir('/sd')

f = open('/sd/test', 'a')
t1 = utime.ticks_ms()
ttot = 0
n = 0
while True:

#    print('about to initialize buffer')
    k = bytearray(1024)
#    print('about to write to file')
    f.write(k)
#    print('about to flush to file')
    f.flush()
    t2 = utime.ticks_ms()
#    print("I'm done ", (t2-t1))
    ttot = (ttot + (t2 - t1)) /2
    gc.collect()
    n += 1
    print("Round", n, ", ", ttot, "ms \n\r", end="")
    t1 = utime.ticks_ms()

I calculate a running average for the write time. The code runs without errors. On the first run where the file is created, after Round 1888 the average time is 37.71667 ms. I break, hard reset and run again without erasing the file and get the same results (Round 1340 , 37.70892 ms). I noticed that the average jumps up to 46ms at time but that may be due to the gccollect() time. I adjusted the code to reset the time AFTER the gccollect and print statements (see above)

At no time did I get an error. I ran the tests with an 8GB Class 10 microSD formatted with FAT32. I am letting the test run a while to see if anything changes.

... after letting it run for a while, the output was Round 143048 , 35.17431 ms and the resulting file was 146MB in size. :)

[robert-hh]

@peekay123 I have seen crashes after about 10000 rounds = 10 MBytes. Just let it run. The speed is not so much in my interest. Tomorrow I'll give it a try too.

[peekay123]

@robert-hh, I ran 300,000 iterations without errors. I'm running it again without erasing the test file, which is at 500MB+ after the first test.

[robert-hh]

@peekay123 That's interesting. I never got beyond 10.000 iterations. I also tried a WiPy build on my LoPy, just in case the Lora stuff being the culprit.

[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?