Firmware release 1.7.3.b1



  • Hello,

    A new firmware release is out. The version is 1.7.3.b1. Here's the change log:

    • esp32: Update libraries from the IDF and implement TLS timeouts.

      This fixes some TLS crashes and instability issues.

    • esp32: Add run-time support for the OEM modules based on the ESP32 revision.

    • esp32: Remove unedded initialization of UART 1 and 2.

    • esp32: Reduce SD card max frequency to 10MHz.

      This fixes the crash seen when stressing the SD card drivers.
      This is nedded due to the fact that with the expansion board
      we only use the weak internall pull-ups of the ESP32 for
      the SD card lines.

    • esp32: Always stop BLE scanning before connecting.

    • esp32: Add critical section protection to timer alarm routines.

    • esp32: Reduce priority of the callback thread.

    • esp32/frozen: De-init UART 1 and 2 at the end of _boot.py

    • docs: Document rtc.synced() method.

    • docs: Added win 7 driver info

    • docs: Added interrupt explainations to pysense/track

    • docs: Corrected OEM zip datasheets

    • docs: Fixed the issues with missing datasheets for pytrack/pysense

    The github repo has also been updated accordingly. Make sure to clone the customised IDF from Pycom again as we have pushed new changes.

    Cheers,
    Daniel



  • @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.



  • @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.



  • @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' ...



  • @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?



  • @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).



  • @this-wiederkehr, I am running WPA2.



  • @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?



  • @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 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 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)?



  • @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 :)



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



  • @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.



  • @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.



  • @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, 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.



  • @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 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, 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.


Log in to reply
 

Pycom on Twitter