Pyboard D: Can't switch to 216 MHz

[ThomasChr]

Evertime I try to change the frequency

Code: Select all

machine.freq(216000000)

the PyboardD locks up and I need to reset via the RST-Button.

Am I doing something wrong?
Firmware:

Code: Select all

MicroPython v1.10-418-g8ef236ec5-dirty on 2019-03-26; PYBD_SF2W with STM32F722IEK

[pythoncoder]

Are you sure it's locked up? There is a known issue where the REPL prompt does not appear after changing the frequency. If you hit Enter it should appear.

[ThomasChr]

I just tried again. No, there is no prompt reappearing.
I can reconnect via Serial, but also there I won't get any prompt.

Any more suggestions?

(If that matters, I'm connected from Windows via Putty (deactivated Hardware Flow Control) with BAUD 115200)

Also a simple reset is not enough, I need a few presses of the reset button until I can reestablish a serial connection...

[ThomasChr]

Can somebody check with his own SF2W if it‘s got the same problem?

[Roberthh]

I had similar problems to switch the frequency with machine.freq(216000000) or machine.freq(168000000)
The first few times it worked, but then it stopped. Sometimes an enter or Ctrl-C revived the device.
Changing the frequency a few times locks it reliably.
Anyhow: it is a very good device.

[chuckbook]

Changing CPU clock while a USB connection is active will have an impact on the data links operating via the USB interface (like the REPL).
I had to toggle between 120 and 216 MHz for quite some time to force missing characters. I'm using minicom on a linux machine. Minicom is known to tolerate USB outages and automatically reconnect. Other programs won't tolerate that and sometimes mess up the USB stack on the host. Due to the fact that MPY on PYBD supports 2MHz granularity of the SYSCLK, the PLL for the 48 MHz USB clock has to be changed. Therefor it's more likely to temporarily corrupt USB operation.

[Roberthh]

There may by a related issue. machine,lightsleep() does not seem to work. When calling it for e.g. a 10000 ms sleep, the power consumption drops for about 1-2 seconds and then goes up again, sometimes not initializing the USB interface again.
WiFi was disabled during that test.
Besides that: at the same frequency the '722 seems slightly faster than Pyboard 1.1, but benefits form larger RAM and faster flash access. And WiFi is working well. My little FTP server works without change. So I can use that for file transfer, avoiding cache problems when using the mass storage mode. I'm waiting for the repository to a my favorite scripts to frozen byte code.
But .. for my fingers it'a a little bit too tiny. A slightly larger form factor with 1/10" pin connections (DIL32 size) would be easier to deal with. You can get that with the adapter board(s), but that adds connectors which a subject to cause trouble, And I do not see what the soldering notches are good for, if the bottom side is not flat. Obviously you can make versions w/o the W connectors and the SD card interface to be soldered to another PCB.

[pythoncoder]

I don't think sleep modes were ever compatible with USB. In my low power applications I detect USB and disable low power modes. To debug low power modes I use a separate PSU and a UART with an FTDI adaptor; I don't connect USB.

[Roberthh]

On Pyboard 1.1 lightsleep() seems to work. When I start it, the current draw decreases to ~2mA for the called time, and then returns to 22mA. USB is disconnected during lightsleep.

[Damien]

Switching frequency with machine.freq(...) works OK for me, at least on an SF2W board after a fresh start. Do you have something running (eg SPI, UART, Timer) during the switch?

machine.lightsleep(ms) should also work, but the USB will not during a lightsleep, you need to do pyb.usb_mode(None) to disable it.

Eg with a SF2W at the REPL: pyb.usb_mode(None); machine.lightsleep(5000) will take current down from 23mA to about 0.5mA, then back up to about 14mA after 5 seconds.