New firmware release, version 1.6.4.b1

[jmarcelino]

@Pete
Yes, think of Micropython as an application that runs on the board (which then runs your script). That's what makes it blink, show up as an AP etc. If the Micropython application is broken the board will appear to do nothing (though it might print some debug strings to the UART). However you can do an "upgrade" to reinstall the application again.

When you connect G23-GND and reset you're telling the board to boot into a special download mode where it accepts a new application image (in this case a new Micropython build). This functionaliy is deeply hardcoded on the ESP32 processor so you'd struggle to break it, especially just by doing a regular upgrade.

What does break the process are devices connected to pins with special functionality known as 'strapping' which - much like G23 to GND - set different boot parameters. I think your GPS could have been interfering with these.

I think this new log does suggest the board is communicating.

Since the error was on setting the connection speed can you now try again disabling the high speed option again?

If it still fails can you close the upgrade tool, open a serial terminal application on the board's serial port (at the usual 115200bps) and let us know what messages show up after a reset?

[Pete]

@jmarcelino Brilliant - thanks for the explanation, and the advice - it's back to life :-)

Given how rapidly new firmware versions are coming out, I want to keep the ability to upgrade the module after building it into the rest of the project. Does this mean I'm going to need some kind of switch or jumper to disconnect the serial input from pin P4 during programming? Are there any other pins I need to be careful of?

Thanks,

Pete

[Pete]

OK, now that I have the new firmware, I've noticed a change (regression?) in the UART API.

I'm not sure if it's strictly correct, but with the earlier firmware I was doing:

def readUart():
    while True:
        if uart.any():
            line = str(uart.readline(), "utf-8")
            # do stuff with line

and reliably getting a newline-terminated chunk of input from the serial line each time.

With the new firmware, the same code (with the same serial input) often populates line with a fragment of the actual line, breaking at a random point where there certainly isn't a newline. The next read will continue with the rest of the line. They're breaking into random chunks of roughly 3 to 25 characters. I haven't noticed any instances of it failing to break on a genuine newline. I'm reproducing this with a minimal case where "do stuff" is just printing line in the REPL.

Does Pycom's test suite include any serial tests that would catch this?

EDIT: I've raised this as an issue on Github as more structured than dumping it into the forum pot.

Pete

[zmrzli]

This version is still unable to receive advertising packet via Bluetooth.
Packet that is sent (and captured by TI sniffer) that supposed to be 0x01 followed by all FFs:

is received as:

(mac=b'\xb4\x99Ld\xba\xc9', addr_type=0, adv_type=3, rssi=-45, data=b'\x01\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00')
b'\x01\xff\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
01ff0000000000000000000000000000000000000000000000000000000000

Is it possible that no other user tried to look at advertising packets so far?
If I am doing something wrong, please chime in and show how to receive advertising packets properly...

Daniel, please confirm this bug and give us estimate when will it be fixed. Our project is stuck, without this working properly, and there is pressure to look for alternative platforms...

Robert

[lars]

I just updated my newly bought WiPy 2.0 to this firmware version with the Pycom updater. After reset I get a boot loop with the following messages via serial connection:[0_1488012601074_core_dump.txt](Uploading 100%)

Resetting the firmware via safe mode does not work. Also trying to reinstall the firmware update leads to the same result. Any help?

[livius]

@lars
did you removed wire (G23-GND) after sucesfull upgrade?

[jmarcelino]

@zmrzli
Your BLE advertising data is invalid according to the Bluetooth spec. The first octet is 1 so you're specifying you are sending one byte for that unit. That's exactly what you're getting :-)
Let's move this discussion to your original post https://forum.pycom.io/topic/723/bluetooth-advertising-data

[lars]

@livius yes I removed the G23-GND wire. I tried serveral disconnects to power and only 3v3 and GND plus plus P0,P1 for UART were connected. Even without uart there is no wifi AP available any more, as was before the update.
For safe mode I tried 3v3-p12 for as long as the most rapid flashing of the orange led.

[jmarcelino]

@lars
could you post the serial connection messages again, either pasting here or somewhere like pastebin.com. It seems they didn't show on your other post

[lars]

@jmarcelino You are right of course. There was a message, that I didn't have the rights to upload a file here. Here is the pastbin: http://pastebin.com/3RaMdeJ2

[daniel]

@lars it might be that there's a conflict with the NV storage area on your WiPy and the current firmware. I have just updated the firmware package online in order to erase that area before applying the new firmware. Could you please try the update again and let me know? Thanks!

Cheers,
Daniel

[Pete]

By the way, I do want to thank whoever fixed the OSX GUI firmware updater so that it 1) shows some of the output from the underlying tools, and more importantly 2) knows about pycom.io's TLS certificate. That made my messing about above that little bit easier :-)

Pete

[lars]

@daniel although pycom does still report the same version number 1.6.4.b1 on update I hope, that I got the new version. The behavior is similar but the serial output is slightly different: http://pastebin.com/EN30c4Nk
Thank you all very much for your quick responses!

[rdixey]

This post is deleted!

[livius]

@daniel
I see that some timings/stability improved in pin.
Now i am able read samsung tv codes without any problem from python code without need of C function as previously :)
I tested this i suppose in many previous versions (last tested lower than 1.5) and it was not stable enought but now it work :)