Problem using a timer on WeAct Blackpill (STM32F411)

[davefes]

I can run this program successfully on a WeAct Blackpill (STM32F411) using the build at
#15646:

import pyb


timer = pyb.Timer(2, freq=36000)
ch2 = timer.channel(2, pyb.Timer.PWM, pin=pyb.Pin('A1'), pulse_width_percent=10)

while True:
    print("Running")
    pyb.delay(2000)

However, trying to modify a stepper control example running on a PICO to
run on a WeAct BlackPill seems to kill something. I can't even do an ls to look at the files and further bootups fail.

from machine import Pin
import time
import pyb
 
 
dir_pin = Pin('A4', Pin.OUT)
step_pin = Pin('A5', Pin.OUT)
steps_per_revolution = 200
 
tim = pyb.Timer(2)

print('hit CTRL-C to exit')
time.sleep(5)

Before I clobber another board is there something wrong with:

tim = pyb.Timer(2)

According to:
https://docs.micropython.org/en/latest/pyboard/tutorial/timer.html
it is legal.

But there must be something required before you exit the program or else disaster ensues.

[shariltumin]

I haven't worked with the WeAct Blackpill (STM32F411) for a long time, so I can't test this myself. But have you tried tim.deinit()?

[bidrohini]

Your timer and pin initialization looks okay, but it's important to ensure the timer and pins are fully configured before running any logic. Also, you should specify the freq parameter for the timer to ensure it operates at the desired frequency. For example,
tim = pyb.Timer(2, freq=1000) # Set frequency to 1kHz

[davefes]

@shariltumin and @bidrohini Thank you for your comments. The script I was trying to modify is here:
https://how2electronics.com/control-stepper-motor-with-a4988-raspberry-pi-pico/#google_vignette
and the code snippet I was trying to use:

from machine import Pin, Timer
import utime
 
dir_pin = Pin(16, Pin.OUT)
step_pin = Pin(17, Pin.OUT)
steps_per_revolution = 200
 
# Initialize timer
tim = Timer()
 
def step(t):
    global step_pin
    step_pin.value(not step_pin.value())
 
def rotate_motor(delay):
    # Set up timer for stepping
    tim.init(freq=1000000//delay, mode=Timer.PERIODIC, callback=step)
 
def loop():
    while True:
        # Set motor direction clockwise
        dir_pin.value(1)
 
        # Spin motor slowly
        rotate_motor(2000)
        utime.sleep_ms(steps_per_revolution)
        tim.deinit()  # stop the timer
        utime.sleep(1)
 
        # Set motor direction counterclockwise
        dir_pin.value(0)
 
        # Spin motor quickly
        rotate_motor(1000)
        utime.sleep_ms(steps_per_revolution)
        tim.deinit()  # stop the timer
        utime.sleep(1)
 
if __name__ == '__main__':
    loop()

I did import pyb because I had successfully used pyb.Timer() previously.

In my "problem snippet" a CTRL-C (using rshell) happens before any logic, timer.init or timer.deinit. However, it seems to really clobber something. Even if I reload the firmware and the script, I can navigate to flash, but when I try to do ls , run the script or try to edit then rshell falls-over.

Maybe, I should try machine.Timer instead, but I have 4 bricked boards and this seems to be a poor way to try and work out what is wrong.

I can run the script on a ESP32, but I like to use the WeAct boards for projects that don't need WiFi.

[davefes]

Some progress. If I put the version at #15646 for the base model, ie internal memory I have a functioning BlackPill. WeAct suggested running SPIFlash_Erase_Firmware.hex but that didn't fix my problem when trying the 8MB flash variant again.

[andrewleech]

The clobbered boards, have you tried re-formatting the filesystem because it sounds like maybe that's getting corrupted somehow? The stm32 snippet here work to try: https://docs.micropython.org/en/latest/reference/filesystem.html#littlefs
Are your weact boards ones with external spiflash?

[andrewleech]

Ah, that code you had in the opening message

dir_pin = Pin('A4', Pin.OUT)
step_pin = Pin('A5', Pin.OUT)

Pins A4 and A5 are used by the spiflash chip:

micropython/ports/stm32/boards/WEACT_F411_BLACKPILL/pins.csv

Line 40 in aecdfc1

-FLASH_CS,PA4

So yeah if you've got spiflash and you run that code, I expect the flash filesystem would definitely be corrupted by that.

[davefes]

O dear, even the previous distro I was using says SPI1 is for the SPI flash. I will put a red X on A4, A5, A6 and A7.

Thanks heaps!

[davefes]

Yes, the 8MB external flash.

[davefes]

Went back to the base model to try to run make_LFS2,py ... that runs because it is a small program. However, trying to cp what_fs.py to /flash falls-over. Had this problem before trying to copy files of more than 1K or so.

Is it possible to damage the STM32F411 by making that SPI1 error?

[robert-hh]

Is it possible to damage the STM32F411 by making that SPI1 error?

I do not expect that it's possible to damage the STM32F411 or the SPI chip. A4 and A5 are inputs to the flash chip, therefore it does not happen that two output pins drive against each other. I could imagine that by some bad luck the SPIflash chip is locked.

b.t.w.: Trying to copy a file from my PC to a blackpill or other STM32 board using mpremote cp file :/flash results in OSError: [Errno 21] EISDIR. mpremote cp file : or mpremote cp filename :/flash/filename work and the file is copied to the file system at the /flash mount point. But it may be that newer versions of mpremote support a directory as target.

[robert-hh]

I just checked it again: The 8MB external flash of the Blackpill board is formatted using LFS2 And there are no issues with large files. The same applies for the internal flash. If I format it with LFS, it works fine. Not issues in copying files larger than 1k to it. And it provides 17k more space than FAT (64k instead of 47k). For formatting the internal flash I used the code snippet from the documentation:

import os, vfs, pyb
vfs.umount('/flash')
vfs.VfsLfs2.mkfs(pyb.Flash(start=0))
vfs.mount(pyb.Flash(start=0), '/flash')
os.chdir('/flash')

[davefes]

The 8MB external flash of the Blackpill board is formatted using LFS2

So, that happens automatically when using the #15646 firmware, correct?

My future buying strategy is ... buy the 8MB boards and if I am lucky enough to flash them correctly ... great. If problems remove the flash, revert to VFAT and use them for smaller jobs :)

[robert-hh]

If problems remove the flash, revert to VFAT and use them for smaller jobs :)

I do not know what went wrong with your board, but I never had problems creating a LFS file system at an external flash. And even if it is not used - one does not have to remove it. If you think the flash chip is broken, you can as well replace it. Winbond W25Q64 or similar chips are available and cheap.

[davefes]

I do have one 8MB board with a working LFS2 filesystem on it, so I know it can be done. Creating a LFS2 on these 4 "damaged" boards, even on one removing the 8MB flash does not give me a working LFS2 filesystem. I accept that I did something silly.

Replacing chips I can handle.

[robert-hh]

The boards are not shipped with a file system. MicroPython at the STM32 port checks when booting whether a files system exists. If not and FAT support is present it creates a FAT file system.

[davefes]

Thank you.