Stable Firmware Release v1.18.2.r2

[iwahdan]

Hello everyone,

New Stable release v1.18.2.r2 is released today, changes include:

Improvements:

• Added API do_handshake for performing handshake operation for ssl/tls non- blocking socket connections
• Added Timeout option for ssl/tls handshake operation
• Amended ESP-IDF Error Codes to Micropython QSTR
• Updated sqnsupgrade script to v1.2.3

Bug Fix

• Fixed crash caused by UART I/O APIs called after UART.deinit

you can download the sources from https://github.com/pycom/pycom-micropython-sigfox/tree/v1.18.2.r2
or you can flash the firmware directly via Firmware Updater tool with latest stable firmware

[panda]

Did something change with regard to 'P18' on GPy? I can't use this pin as an input under the 1.18.2 firmwares. It appears to be pulled low and can not be changed.

Any of the 1.18.1.r version and earlier work fine.

[iwahdan]

@panda No the functionality regarding GPIOs should be the same, just checked it and cannot reproduce that issue on my GPy with latest stable 1.18.2.r2.

please describe more your setup, are you using an Exp.Board , Pytrack, external circuit, ..etc ? also can you share the piece of code you use to reproduce that Issue ?

Thanks

[panda]

Hi,

What precipitated this is not being able to use SPI with an audio chipset (VLS1053B) on the newest firmware. Here is my config for that:

spi = SPI(0, mode=SPI.MASTER, baudrate=2000000, firstbit=SPI.MSB, polarity=0, phase=0, pins=('P10','P21','P18'))

When I scoped each line the only one that is not behaving the same as the older firmware is P18 which is MISO. The line is not toggling when doing a SPI read. When I detached MISO from the GPy the line from the slave does toggle as expected. So I suspected the pin was not floating.

Setting SPI aside, When I configured P18 as a simple input with no pull it sure seemed like it had an internal pull down despite "pull=None" with the latest fw. So, I speculated something changed here.

This is a custom board.

[panda]

More info...

It is something to do with SPI. Now that I figured out how to decode with my scope, spi.write is sending garbage. No matter what data I send, the waveform is the same for each byte. From my perspective SPI is broken. Or the pin combination I am using is no longer valid.

For example, as illustrated, below no matter what byte I write over SPI, the data is written as 0xAA.

SPI setup:
spi = SPI(0, mode=SPI.MASTER, baudrate=2000000, firstbit=SPI.MSB, polarity=0, phase=0, pins=('P10','P21','P18'))

SPI Command
spi.write(0xff)

Results

1.18.1.r7-

1.18.2+

[iwahdan]

@panda Ok thanks for the screenshots , I will try to replicate on my side.

[iwahdan]

@panda said in Stable Firmware Release v1.18.2.r2:

spi = SPI(0, mode=SPI.MASTER, baudrate=2000000, firstbit=SPI.MSB, polarity=0, phase=0, pins=('P10','P21','P18'))

I confirm the bug in SPI that is visible in your screenshots , this was an old issue fixed on the release-candidate branch but was not merged to stable, I just released a new Firmware v1.18.2.r3 to include that Fix, however I can't reproduce the problem always pulled-down you say you have with P18 .
Please let me know if the latest release does fix your issues.

Thanks

[panda]

Thank you! I'll try to check this over the weekend.

[panda]

That resolved all issues. Thanks.