New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support)

[incognico]

Tried to do this update on a new FIPY for ~60 mins with no success. It would fail at 15% every time.

Out of desperation I tried a different USB cable... and it worked first time. Never had an issue with the original cable before, it's been used for years on dozens of devices. New cable is Belkin branded. Just something else you can try if you're having issues. Heh, Pournelle's law!

[ledbelly2142]

Downloaded the new updater and attempted to update a LoPy with expansion board. After update, LoPy does not completely boot. LoPy hangs on reset:

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff9028,len:8
load:0x3fff9030,len:1060
load:0x4009fa00,len:0
ho 12 tail 0 room 4
load:0x4009fa00,len:15160
entry 0x400a0644

Bricked 2 LoPys this way, attempted firmware reset with 3.3V pin and P12 with no effect. Safeboot does not work.

[daniel]

@ledbelly2142 is the LED blinking in orange when you try a safe boot? Are you sure the device is not running any code?

[ledbelly2142]

@daniel Yes, the LED is blinking orange. Using the factory reset documented HERE should have removed any existing code. Please correct me if I'm wront. Used the final 1.5 second window to reset factory firmware.

I have tried safe boot a number of times on both LoPys I attempted to update. Reset/Reboot hangs.
What can I try next?

[ledbelly2142]

@daniel I have also attempted to reinstall the firmware update with slow and fast connection. Firmware update appears to connect to the device and confirm update. I can update the firmware from the update utility. It's not totally bricked. Just hangs on reset/reboot.

[Xykon]

@ledbelly2142 Can you please confirm the OS you are using? I can send you the instructions necessary to completely erase your device and (optionally) dump the current flash memory so we can try to replicate the issue to hopefully find a more permanent solution?

[ledbelly2142]

@xykon using Win10 with VS Code and Pymakr extension.

[ledbelly2142]

@xykon The code I updated before works with the one of the last firmware versions. Uses the Pycom mqtt.py booting with wifi and Lora, and the Lora Raw example.

[ledbelly2142]

@xykon I went line by line through my code. Visual Studio code was acting strange... I had to reinstall VS Code, manually uninstall the Pymakr extension and reinstall it... again.
I have been able to get my code working without freezing up. Thanks to @Xykon 's help, I narrowed it down to freezing up caused by my code, not the firmware. I had a line in my boot.py that was redundant, 'Upload' worked after I removed the machine.main('main.py')

Thank you for your help

[dbrgn]

@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):

Breaking change: the default MISO pin for SPI has been moved from P12 to P14. Remember that SPI, UART, I2C pins can be assigned pretty much anywhere.

That's a pretty small mention for a breaking change. Also, I could not find this change reflected in the pinout docs (https://docs.pycom.io/chapter/datasheets/development/lopy.html). A lot of people will also have a version of that pinout printed out or stored in a project directory, without any expectation of pinout changes.

If I had already made hardware that relies on the MISO pin to be on P12, would I have to compile my own patched version of the firmware for every release? Or is this configurable in boot.py? Was there a technical reason for the change (indicating that it's better to have MISO on P14 than P12)?

[seb]

@dbrgn

You would only need to change the way you instantiate the SPI class to use the old pin layout, you can find an example of this here: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/SPI.html
No need to recompile the whole firmware. The reason this has been changed is because on new devices P12 controls the external WiFi antenna switch and therefor should not be used for SPI. The pinout diagrams will soon be updated to reflect these changes.

[livius]

@dbrgn
It is good practice that if you have default configuration which can by changed by params,
to specify default params also. It is helpfull for self documenting (you do not need to look into docs what is default or place some comments) and then such changes do not affect you at all.
But this is only my little POV.

[daniel]

There’s no need to recompile firmware. Every peripheral (except for the SD card) allows to assign its pins anywhere (by passing the pins argument to the constructor). However, if no pins argument is given, a set of default pins is used. P12 is also the safeboot pin and the antenna select pin in the WiPy3, LoPy4, GPy and FiPy.

Just use the pins argument in the constructor and specify P12 for MISO and that’s it.

I hope that this is clear.

Cheers,
Daniel

[seb]

@livius

Hi, thanks for the feedback, the documentation will be undergoing a lot of improvements soon and we will definitely keep this in mind.

[robert-hh]

@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):

P12 is also the safeboot pin and the antenna select pin in the WiPy3, LoPy4, GPy and FiPy

If you look into the Pin-out diagrams, there is still a mess about that topic.

[seb]

@robert-hh said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):

@daniel said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):

P12 is also the safeboot pin and the antenna select pin in the WiPy3, LoPy4, GPy and FiPy

If you look into the Pin-out diagrams, there is still a mess about that topic.

Hi,
I just looked over all of the pinouts, only the LoPy4 remained to fixed and has now been resolved. The pinouts now all accurately reflect where each module has its antenna select. I will soon be improving the documentation around the other issue you raised with safe boot.

[robert-hh]

@seb Thanks, and in case we do not talk again: Merry Christmas

[dbrgn]

@seb said in New firmware release v1.11.0.b1 and new updater tool version v1.1.4.b1 (FiPy and GPy support):

@dbrgn

You would only need to change the way you instantiate the SPI class to use the old pin layout, you can find an example of this here: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/SPI.html
No need to recompile the whole firmware. The reason this has been changed is because on new devices P12 controls the external WiFi antenna switch and therefor should not be used for SPI. The pinout diagrams will soon be updated to reflect these changes.

Ah, thank you for clarification, that helps :)

@livius said:

It is good practice that if you have default configuration which can by changed by params,
to specify default params also.

Yep, I agree :) I was under the impression that this mapping is something that is done in the ESP32 firmware, not in the "MicroPython userspace", which would have been a bit more complicated in my case.

[tcottle]

@daniel Updater tool does not work on Win7(!) No indication of Win10 requirement in the docs and the installer does not catch this error.

[daniel]

@tcottle it should work on Win7 as well. What errors do you get?