Firmware release 1.7.1.b1

[daniel]

@peekay123 I guess that you mean: time.localtime() this is related to the same ntp sync issue which has already been solved internally. Thanks.

[peekay123]

@daniel, rtc.local() worked fine before. However, I'll use time.localtime() in the future.

[this.wiederkehr]

Thanks @daniel for letting me know. Is this behavior documented somewhere. It's not basically what I would expect ;-)

Here is a script to reproduce the crash. I could reproduce the crash on address 0x40087eb9 with it. Though, it does not trigger on the first instance but you might have to run it for several minutes till the exception occurs. I'll try further and see if it also triggers the other exceptions I got...

import machine
import os
import utime

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

f = open('/sd/test', 'a')
t1 = utime.ticks_ms()
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 %i"%(t2-t1))
    t1 = t2

Update: Yes, this also triggers the other exception at address 0x400875b9.
Update2: It also reproduces the freeze or at least I can see a slow down of the python interpreter by factors. I just see cycle times which are usually in the range of 10 - 500 ms (500 most likely during gc) going up to ~20000 or even 30000.

Let me know if you can reproduce those issues...

[sthomson]

Hi,
I have used the updater tool to flash 1.7.1.b2 to my LoPy board. I am running the following:

wlan = network.WLAN(mode=network.WLAN.STA)
wlan.connect(ap.ssid, (ap.sec, mypassword))
    while not wlan.isconnected():
        machine.idle() # save power while waiting

This was working without problems with the previous firmware (1.6.7.something), but now it is stuck in the machine.idle() loop and never seems to connect. Is this related to one of the bugs discussed here?

[daniel]

@sthomson I just tried your script and everything seems to work normally. Does it change anything if you replace the machine.idle() line with time.sleep(1) ?

[sthomson]

@daniel I changed it to time.sleep(1) and I have the same issue. I also tried it with a couple of different wifi networks.

When I log onto my router, it actually sees the device as connected, it's just the LoPy that doesn't seem to realize it's connected.

Thanks.

[Frida]

import time

while 1:
    print("Time: ",time.time())
    time.sleep(1)

Why is the time going to count from 1 to 2146, and then the next nummer is
negative and it count's down to -140462611, and repeats it self over and over.

Time: 0 to
Time: 2146 then the next is
Time: -140464759 and down to
Time: -140462611 and then start over again
Time: 0
Time: 2146
Time: -140464758
Time: -140462611
Time: 0
Time: 2146
Time: -140464758
Time: -140462611
Time: 0

>>> os.uname()
(sysname='WiPy', nodename='WiPy', release='1.7.1.b1', version='v1.8.6-640-g585ac892 on 2017-06-02', machine='WiPy with ESP32')
>>> 

[peekay123]

@Frida, on firmware 1.7.1.b2, on a fresh reset, I get:

Time:  572
Time:  573
Time:  574
Time:  575
Time:  576
Time:  577
Time:  578
Time:  579
Time:  580
Time:  581
Time:  582
Time:  583
Time:  584
Time:  585

So it seems to be working. However, I have the same issue as @sthomson regarding the wifi connectivity. The LoPy doesn't think it's connected but I can connect to it via ftp. Also, ntp is not working as we all know.

[robert-hh]

@Frida @peekay123 I observed the same behaviour as @Frida . @peekay123, you have to let it run until 2146, if you read @Frida's comment properly. Then it should look like:

Time:  2141
Time:  2142
Time:  2143
Time:  2144
Time:  2145
Time:  2146
Time:  -140464758
Time:  -140464757
Time:  -140464756
Time:  -140464755
Time:  -140464754
Time:  -140464753

2146 times 1 million is a little bit less than 231, 2147 times 1 million is a little bit larger than 231 . So it looks as if there the overflow in a microseconds counter is not properly treated.

[livius]

@robert-hh
I do not know but long under esp32 is 4 bytes? I suppose that yes.
because timeval fields are long
if yes than calculations like this in sources should be casted as unit64 before

 return mp_obj_new_int(((tv.tv_sec * 1000000) + tv.tv_usec)

[robert-hh]

@livius I do not know the excat reason. I did not look it up in the source code yet. But it look like a overflow counter & signed/unsigned mismatch error.

[livius]

@robert-hh
I see that in current 1.7.2 it is fixed - all calculations are cast to uint64 and also constants are with ull suffix
https://github.com/pycom/pycom-micropython-sigfox/commit/3284efccc8e4488a56c4cc93a494a58d6b348908