New firmware release 1.5.0.b2

[jmarcelino]

@cvp
Could you post your ifconfig line please showing the tulple, like:

wlan.ifconfig(config=('192.168.0.4', '255.255.255.0', '192.168.0.1', '8.8.8.8'))

[cvp]

wlan.ifconfig(config=('192.168.1.48', '255.255.255.0', '192.168.1.1', '8.8.8.8'))

or

wlan.ifconfig(config=('192.168.1.48', '255.255.255.0', '192.168.1.1', '192.168.1.1'))

[livius]

@cvp
are you sure that you have not any other device with .48 IP in network?

[cvp]

When I scan my network (I use Fing on iPad), I see a lot of IP's (Mac, smartphones, tablets, NAS, printer,...) with .47 and .49, two devices I know as fixed IP's, but no .48
Strange
Perhaps in the past because I don't remember why I set 47 and 49, skipping 48 😅

@livius , @jmarcelino I've tried with .46, same problem.
When, in REPL, I type the same line wlan.ifconfig..., and I print wlan.ifconfig(), it has taken the .46 as IP but shows a dns 0.0.0.0 and the IP is not visible in the network

[livius]

@daniel
This is really critical - we can not make work progress :(
to test try to save file e.g. sample about onewire
copy file and look how it is stored

next open it and delete all text and put back by ftp
next once again copy it by ftp and look how it look - it is broken inside

---

i investigate this and it happen after exactly 2920 bytes
and there are 152 bytes eaten and then next bytes looks ok
i still can not find reason in git source code pycom and esp :(
i test with bigger file 16KB
and there is:
2920 bytes then 152 bytes eaten then
and after 4968 once again 152 bytes eaten

between 2920 nad 4968 are also some bytes missed:
after 2484 bytes 588 bytes eaten

[mkharibalaji]

@daniel Can we expect any bug fix release today ?

[jmarcelino]

Good observations @livius . I also replicated the FTP problem here, it seems to happen when transmitting the file from the *Py to your machine. Reading the file on the Py itself appears correct.

So far I'm suspicious of this ftp_send_from_fifo() code in ftp.c (line 569)

            if (E_FTP_RESULT_OK == ftp_send_non_blocking (_sd, fifoelement.data, fifoelement.datasize)) {
                SOCKETFIFO_Pop (&fifoelement);

As the send() call is non-blocking can't a race condition happen where the FIFO (data) element is popped before it had a chance to be transmitted?

It's not conclusive but once I added a small delay before SOCKETFIFO_Pop() I managed to repeatedly GET the full file without any data missing.

I'll investigate more if I have some time today, but thought it was worth sharing.

[livius]

@jmarcelino
i suppose you found second issue
but i think the real problem is deeper inside and is not releated to ftp
especially if we execute_from_lexer in main.c
we got error also for valid buffer :(

e.g. if i try download file throught ftp i have eaten bytes inside
but when i open file by

f = open('myfile.py', 'r+')
d = f.readall()
print(d)

file looks ok
but when i try

exec(d)

i got error on exact line which is eaten when readed by ftp
the same is when i try to:

execfile('myfile.py')
or
import myfile

i have not much time today - but maybe my observation can point you or someone to find real issue

[daniel]

@jmarcelino @livius I'm working on this as we speak. Will update you shortly.