Problem getting files on to 8MB BlackPill

[davefes]

On two brand-new WeACT Blackpills I have placed the latest 8MB firmware. As I wanted a LFS2 filesystem the next thing I did was run the script to make the filesystem LFS2. That seems to run but when I do:

/flash> cp /home/dave/2_STM32F411/what_filesystem.py /flash/
Copying '/home/dave/2_STM32F411/what_filesystem.py' to '/flash/what_filesystem.py' ...
timed out or error in transfer to remote: b''

to check that the filesystem changed. Am I correct in changing the filesystem before putting any files on the flash?

Also, when booting rshell pauses at: Retrieving sysname ... pyboard for 5-10 seconds

Edit: I appear to be able to change the filesystem back to FAT but get the same error.

[nspsck]

Hi, I am going to need a little bit more information, as I could not replicate the described issue through either thonny nor mpremote. I tried to copy a big (1MB) .jpg file to the device then back to the pc, no obvious data lost or similar thing could be observed. In deed, the file copied back is exactly the same when you compare them.

So, questions:

• Have you tried to take it out then plug it back in after formating to lfs2?

• What program are you using?

• If you were using the native linux cd command, are you sure that you linux distro supports lfs2 by default?

• I appear to be able to change the filesystem back to FAT but get the same error.

• How did you get it back to FAT? Something similar like this?

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

• After getting it back to FAT, have you tried to replug it?

Am asking the last 2 questions because FAT should always have worked.

[davefes]

On a new board and I did not do a mass_erase, just uploaded firmware.dfu: 1) did not have to ("faulty" board yes) 2) make_LFS2 is your example and what_filesystem.py see below 3) Yes 4) Yes 5) Yes

"""
Dump info about a filesystem.
"""

import sys, struct

def pr(addr, label, data):
    if type(data) == bytes or type(data) == bytearray:
        data = ':'.join('%02x' % b for b in data)
    print('%04x  %-32s %s' % (addr, label, data))

def decode_bootsec_fat(b):
    print('FAT filesystem')
    pr(0, 'jump', b[0:3])
    pr(3, 'OEM name', str(b[3:11], 'ascii'))
    pr(11, 'sector size (bytes)', struct.unpack_from('<H', b, 11)[0])
    pr(13, 'cluster size (sectors)', struct.unpack_from('<B', b, 13)[0])
    pr(14, 'reserved area (sectors)', struct.unpack_from('<H', b, 14)[0])
    pr(16, 'number of FATs', struct.unpack_from('<B', b, 16)[0])
    pr(17, 'size of root dir area', struct.unpack_from('<H', b, 17)[0])
    pr(19, 'volume size (sectors)', struct.unpack_from('<H', b, 19)[0])
    pr(21, 'media descsriptor', hex(struct.unpack_from('<B', b, 21)[0]))
    pr(22, 'FAT size (sectors)', struct.unpack_from('<H', b, 22)[0])
    pr(24, 'track size (sectors)', struct.unpack_from('<H', b, 24)[0])
    pr(26, 'number of heads', struct.unpack_from('<H', b, 26)[0])
    pr(28, 'volume offset (sectors)', struct.unpack_from('<L', b, 28)[0])
    pr(32, 'volume size (32-bit) (sectors)', struct.unpack_from('<I', b, 32)[0])
    pr(36, 'physical drive number', struct.unpack_from('<B', b, 36)[0])
    pr(37, 'error flag', hex(struct.unpack_from('<B', b, 37)[0]))
    pr(38, 'extended boot signature', hex(struct.unpack_from('<B', b, 38)[0]))
    pr(39, 'volume serial number', hex(struct.unpack_from('<L', b, 39)[0]))
    pr(43, 'volume label', str(b[43:51], 'ascii'))
    pr(54, 'filesystem type', str(b[54:62], 'ascii'))
    pr(510, 'signature', hex(struct.unpack_from('<H', b, 510)[0]))

def decode_bootsec_lfs1(b):
    print("Littlefs v1 filesystem")
    pr(24, "type", struct.unpack_from("<I", b, 24)[0])
    pr(25, "elen", struct.unpack_from("<I", b, 25)[0])
    pr(26, "alen", struct.unpack_from("<I", b, 26)[0])
    pr(27, "nlen", struct.unpack_from("<I", b, 27)[0])
    pr(28, "block_size", struct.unpack_from("<I", b, 28)[0])
    pr(32, "block_count", struct.unpack_from("<I", b, 32)[0])
    pr(36, "version", hex(struct.unpack_from("<I", b, 36)[0]))
    pr(40, "magic", str(b[40:40 + 8], 'ascii'))

def decode_bootsec_lfs2(b):
    print("Littlefs v2 filesystem")
    pr(8, "magic", str(b[8:8 + 8], "ascii"))
    pr(20, "version", hex(struct.unpack_from("<I", b, 20)[0]))
    pr(24, "block_size", struct.unpack_from("<I", b, 24)[0])
    pr(28, "block_count", struct.unpack_from("<I", b, 28)[0])
    pr(32, "name_max", struct.unpack_from("<I", b, 32)[0])
    pr(36, "file_max", struct.unpack_from("<I", b, 36)[0])
    pr(40, "attr_max", struct.unpack_from("<I", b, 40)[0])

def decode_bootsec(b):
    if b[40:48] == b"littlefs":
        decode_bootsec_lfs1(b)
    elif b[8:16] == b"littlefs":
        decode_bootsec_lfs2(b)
    else:
        decode_bootsec_fat(b)

def main():
    if sys.platform == 'pyboard':
        import pyb
        #sd = pyb.SDCard()
        sd = pyb.Flash(start=0)
        bootsec = bytearray(512)
        sd.readblocks(0, bootsec)
    elif sys.platform in ('esp8266', 'esp32'):
        import esp
        bootsec = bytearray(512)
        esp.flash_read(esp.flash_user_start(), bootsec)
    else:
        with open(sys.argv[1], 'rb') as f:
            bootsec = f.read(512)
    decode_bootsec(bootsec)

main()

... found somewhere on the Micropython forum.

One "mistake" I made on the first two 8MB boards was that I still had A7 connected to my LoRa chip poweron-reset pin. Removed that connection still wouldn't see /flash contents and then removed all connections off the BlackPill and still no joy.

I will do a mass-erase on those first two boards, re-load firmware and report back.

Previously to the timed out or error in transfer to remote: b'' error sometimes on either the standard board or my first tests on the 8MB board sometimes the flash contents would disappear, but plugging back in again and/or hitting the NRST button I could then see flash contents again. I was starting to think there was something wrong with the USB on the host but have tried another computer and it still misbehaves.

[nspsck]

I will do a mass-erase on those first two boards, re-load firmware and report back.

That's probably going to change the game. Since these boards comes with a program that uses USB already.

make_LFS2 is your example and what_filesystem.py see below

By which programm you are using I was refering to "through what were you trying to upload the .py file to your blackpill?". I wanted to know if you were just using it as a flash drive while it is formated as lfs2.

[davefes]

O, dear! Can you suggest how to get that pre-built program back again?

I use rshell for file uploading. I prefer using rshell rather than as a flash drive. I did mass-erase on the standard boards and didn't seem to have this problem.

Did a mass-erase and re-flash firmware.dfu and still can't see /flash contents using rshell.

[davefes]

As noted previously, I found mass-erase left still left /flash contents on the device. Is there something wrong with that script?

[nspsck]

O, dear! Can you suggest how to get that pre-built program back again?

No, but that firmware is also nothing special, just a led blinker and a usb msc example.

As noted previously, I found mass-erase left still left /flash contents on the device. Is there something wrong with that script?

This is normal, the content on the spi flash can only be erased by reformating it.

[davefes]

but that firmware is also nothing special

Something special has disappeared. I will have a look around WeACT's website. For now I would put a "red flag' on mass-erase. I have STM32CubeProgrammer installed, perhaps that is a safer method of cleaning things out.

[davefes]

On a 3rd board ... no mass-erase changed to LFS2 and checked the filesystem ... all looks OK. Did mpremote mip install lora-sync and mpremote mip install lora-sx127x and now the 3rd 8MB board behaves like the first two 8MB boards.

[nspsck]

Ugh... I just can not replicate that issue...

I am on a Windows PC and just did the samething using mpremote. Everything works just fine. I have also tried to mass-erase as described in the README.md but nothing odd has come up to me...

And, mase-erase is always encouraged to do since you can never predict what is left over on the board. There is nothing to be afraid of ,unless you know you have important data on the internal flash and you do not want those to be destroyed.

[davefes]

Unfortunately there are too many variables! I can tell Micropython is on the board. It takes longer for rshell to access the board than for new boards and when it does then I can't copy files across or see what files there are on the board after flashing the firmware.

[davefes]

Tried loading the hex file using ST-Link and STM32CubeProgrammer. Still the same behaviour.

[davefes]

After many emails back and forth the correct file for these boards is: WeAct_HID_Bootloader_F4x1.hex however I don't know if I am putting it in the right place.

Download verified successfully 13:16:01 : Memory [0x08000000 : 0x08080000] - Checksum : 0x04E4A6D7 Should it not be placed some where else?

[nspsck]

To my limited knowledge that HID-Bootloader is only relevant for Arduino IDE.

Usually, 0x0800 0000 is where the beginning of the internal flash sits, and app starts from there. So I think there is a very high chance that it's placed on right place.

[davefes]

I would guess that if I can load a firmware.dfu or firmware.hex onto the device that the bootloader must still be working.

[nspsck]

Just to clarify:

DFU-Mode (direct firmware update mode) is not equivalent with the bootloader, and its implementation does not sit in the internal flash (At least not the part the user can access) and since it's a "mode" provided by ST, you cannot reprogram it either.

From a bootloader (as an app on the internal flash) you can boot into DFU-Mode under certain conditions. A bootloader is stored on the internal flash and it's usually flashed either through a debug interface, a USART port or the DFU mode.

So, if you were able to upload firmware onto the blackpill, it only means that the DFU mode is working (or the USART, or the st-link, depends on which method worked for you).

[davefes]

Thank you for the clarification.

I appear to be able to upload firmware it is only a problem with loading files to flash using either rshell or mpremote

I am rather reluctant to try the 4th board. If I do there will be no mass-erase, the filesystem will stay as VFAT and I will not do a mpremote mip install anything.

[davefes]

The 4th board is OK as far as mentioned above. This board I connected A9 to A10 as per original instructions. On first 8M board it didn't go into DFU-mode (easily?) so I have since been connecting A10 to ground. Maybe, that messes-up WeAct boards.

Those 3 boards appeared normal until I did the mpremote mip installs. I will load software on the 4th board using rshell and test.

3rd board will only go into DFU-mode if A10 goes to ground. It will not go into DFU-mode connecting A9 to A10. Maybe it is damaged from previous attempts to get into DFU-mode?? "Clutching at straws".

[davefes]

There is something wrong happening here. I unplugged the 4th board and on plugging it back in the file system has disappeared and now I can not load files to this one.

[davefes]

Just for interest I uploaded the firmware.dfu for the standard part to the 8MB board and it works like a standard board.

Has it got something to do with the SPI FLASH?

I recall some discussion about wait_states here: https://forum.micropython.org/viewtopic.php?f=12&t=7154&hilit=WeAct+STM32F411CEU6+black+pill&start=10

[nspsck]

Just for interest I uploaded the firmware.dfu for the standard part to the 8MB board and it works like a standard board.

This is a correct behavior. Some modifications to the firmware has to be made for it to support spi flash access by default.

Has it got something to do with the SPI FLASH?

Highly doubt it. The chance that all 4 spi flashes are faulty is really low.

I recall some discussion about wait_states here: https://forum.micropython.org/viewtopic.php?f=12&t=7154&hilit=WeAct+STM32F411CEU6+black+pill&start=10

The default wait_states (which I am susing) is FLASH_LATENCY_5. And also, that only affects internal flash. It has nothing to do with spi-flash.

[davefes]

At least I can use these as LoRa remotes. I have built the firmware from your instructions, so will give that a try.

I was concerned whether or not it was done properly as both of my files are about 2-3% larger than yours.

[davefes]

My .dfu file behaves the same.

This 5-10 second pause at Retrieving sysname ... pyboard Is it saying that it is having trouble finding something?

[nspsck]

I was concerned whether or not it was done properly as both of my files are about 2-3% larger than yours.

Depends on the micropython version, the size of the firmware may change, this should not be a big concern.

This 5-10 second pause at Retrieving sysname ... pyboard Is it saying that it is having trouble finding something?

Maybe you should switch to mpremote or thonny. I just checked rshell and it seems not to be updated for over a year. And micropython has been moving forward daily. Also I am not familliar with python, but that message is produced here: https://github.com/dhylands/rshell/blob/b87878c01aa02d6cd871ff4666983dee5584af16/rshell/main.py#L1503. Maybe you can figure it out what it actually measn.

But if that was the first boot, it's supposed to be, since mpy has to take care through all these filesystem and other initializations.

[davefes]

Good question. Maybe if you change QUIET to true you don't get all these messages.

Line 1504 self.sysname = self.remote_eval(sysname) seems to be where is might be stalling.

After flashing the firmware for 8MB I do not see anything in /flash using rshell, BUT ...

dave@davef:~$ mpremote connect auto
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell
Traceback (most recent call last):
  File "main.py", line 215, in <module>
  File "main.py", line 53, in main
  File "main.py", line 46, in get_modem
  File "lora/sx127x.py", line 267, in __init__
RuntimeError: Unexpected silicon version 0
MicroPython v1.22.0-preview.164.gfce8d9fd5.dirty on 2023-11-22; WeAct Studio Blackpill v3.1 8MB with STM32F411CE
Type "help()" for more information.

I can run the program from mpremote. Looks like I need to transition to using mpremote!

rshell works fine on the regular version.

[davefes]

Thanks again for your support through this "minefield".

[davefes]

On closer inspection I can not get any further, even using mpremote. When I said the program was running it was running because at some stage I managed to get files on to the 8MB board. Where they reside I do not know.

Using mpremote I can not cp files to the 8MB version or ls the filesystem.

I can mpremote run what_filesystem.py and get VFAT, but I can not mpremote run make_LFS2.py

Maybe, another clue ... flashing another 8MB distribution:

dave@davef:~/2_STM32F411$ mpremote a0
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell
MPY: can't mount flash
MicroPython v1.20.0-93-g05e143dbd on 2023-05-20; WeAct Studio Core with STM32F411CE
Type "help()" for more information.

back to your 8MB firmware:

dave@davef:~/2_STM32F411$ mpremote cp /home/dave/1_micropython-lora/Reliable_Delivery/TX/* :
cp /home/dave/1_micropython-lora/Reliable_Delivery/TX/boot.py :
cp /home/dave/1_micropython-lora/Reliable_Delivery/TX/lora_rd_settings.py :
cp /home/dave/1_micropython-lora/Reliable_Delivery/TX/main.py :
 ... copying  49% [#########-----------]Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 5] EIO

[davefes]

Just tried v1.14 on the WeACT Github page and it seems to work. gc.mem_free() ~94K and df says 8.3MB of flash

[nspsck]

Hi, I have installed ubuntu on an old laptop of mine and tried to replicated the issue.

paul@paul-ThinkPad-X1-Yoga-2nd:~$ neofetch 
            .-/+oossssoo+/-.               paul@paul-ThinkPad-X1-Yoga-2nd 
        `:+ssssssssssssssssss+:`           ------------------------------ 
      -+ssssssssssssssssssyyssss+-         OS: Ubuntu 22.04.3 LTS x86_64 
    .ossssssssssssssssssdMMMNysssso.       Host: 20JES00L00 ThinkPad X1 Yoga 2n 
   /ssssssssssshdmmNNmmyNMMMMhssssss/      Kernel: 6.2.0-37-generic 
  +ssssssssshmydMMMMMMMNddddyssssssss+     Uptime: 1 min 
 /sssssssshNMMMyhhyyyyhmNMMMNhssssssss/    Packages: 2051 (dpkg), 16 (snap) 
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Shell: bash 5.1.16 
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   Resolution: 2560x1440 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   DE: GNOME 42.9 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   WM: Mutter 
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   WM Theme: Adwaita 
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Theme: Yaru [GTK2/3] 
 /sssssssshNMMMyhhyyyyhdNMMMNhssssssss/    Icons: Yaru [GTK2/3] 
  +sssssssssdmydMMMMMMMMddddyssssssss+     Terminal: gnome-terminal 
   /ssssssssssshdmNNNNmyNMMMMhssssss/      CPU: Intel i7-7600U (4) @ 3.900GHz 
    .ossssssssssssssssssdMMMNysssso.       GPU: Intel HD Graphics 620 
      -+sssssssssssssssssyyyssss+-         Memory: 2180MiB / 15732MiB 
        `:+ssssssssssssssssss+:`
            .-/+oossssoo+/-.                                       

paul@paul-ThinkPad-X1-Yoga-2nd:~$ 

First I tried to run the mpremote run make_LFS2.py command, with the content in the file being:

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

with the result being:

paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ mpremote run make_LFS2.py
paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$

And the filesystem has been formatted correctly.

Then I ran the following command to connect the device, as well as the result:

paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ mpremote 
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell
MicroPython v1.22.0-preview.162.g6117aa686.dirty on 2023-11-19; WeAct Studio Blackpill v3.1 8MB with STM32F411CE
Type "help()" for more information.
>>> 

There's no line that hints any issue with the flash. So I pressed Ctrl+X to exit it and moved on with file copying. I ran according to the official mpremote documentations:

# Note that theres a extra keyword fs before cd and the : means the root directory of the target device
paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ mpremote fs cp -r ./* :
cp ./button_text.py :./
cp ./connecttoweatherstation.py :./
cp ./fill_bubble_rect.py :./            
cp ./findMax.py :./                     
cp ./fsram_check.py :./
cp ./main.py :./
cp ./make_LFS2.py :./                   
cp ./overclocktester.py :./
cp ./overclocktestMultiThread.py :./
cp ./png_decoder_test.png :./
cp ./RP2040_Micropython_voltage_control/LICENSE :./RP2040_Micropython_voltage_control/
cp ./RP2040_Micropython_voltage_control/README.md :./RP2040_Micropython_voltage_control/
cp ./RP2040_Micropython_voltage_control/.git/HEAD :./RP2040_Micropython_voltage_control/.git/
cp ./RP2040_Micropython_voltage_control/.git/logs/HEAD :./RP2040_Micropython_voltage_control/.git/logs/
cp ./RP2040_Micropython_voltage_control/.git/logs/refs/heads/main :./RP2040_Micropython_voltage_control/.git/logs/refs/heads/
cp ./RP2040_Micropython_voltage_control/.git/logs/refs/remotes/origin/HEAD :./RP2040_Micropython_voltage_control/.git/logs/refs/remotes/origin/
cp ./RP2040_Micropython_voltage_control/.git/index :./RP2040_Micropython_voltage_control/.git/
cp ./RP2040_Micropython_voltage_control/.git/info/exclude :./RP2040_Micropython_voltage_control/.git/info/
cp ./RP2040_Micropython_voltage_control/.git/packed-refs :./RP2040_Micropython_voltage_control/.git/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-receive.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/post-update.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-applypatch.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/applypatch-msg.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/fsmonitor-watchman.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/prepare-commit-msg.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-push.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/update.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-merge-commit.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/commit-msg.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-rebase.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/push-to-checkout.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/hooks/pre-commit.sample :./RP2040_Micropython_voltage_control/.git/hooks/
cp ./RP2040_Micropython_voltage_control/.git/config :./RP2040_Micropython_voltage_control/.git/
cp ./RP2040_Micropython_voltage_control/.git/description :./RP2040_Micropython_voltage_control/.git/
cp ./RP2040_Micropython_voltage_control/.git/refs/heads/main :./RP2040_Micropython_voltage_control/.git/refs/heads/
cp ./RP2040_Micropython_voltage_control/.git/refs/remotes/origin/HEAD :./RP2040_Micropython_voltage_control/.git/refs/remotes/origin/
cp ./RP2040_Micropython_voltage_control/.git/objects/pack/pack-f99b60cb8d7de253e8345c449dfec98dabc71233.idx :./RP2040_Micropython_voltage_control/.git/objects/pack/
cp ./RP2040_Micropython_voltage_control/.git/objects/pack/pack-f99b60cb8d7de253e8345c449dfec98dabc71233.pack :./RP2040_Micropython_voltage_control/.git/objects/pack/
cp ./RP2040_Micropython_voltage_control/firmware.uf2 :./RP2040_Micropython_voltage_control/
cp ./RP2040_Micropython_voltage_control/POV.py :./RP2040_Micropython_voltage_control/
cp ./RP2040_Micropython_voltage_control/OCTestMultiThread.py :./RP2040_Micropython_voltage_control/
cp ./st7789py.py :./                    
cp ./testingpng.py :./                  
cp ./test.py :./
cp ./weatherstation.py :./
paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ 

It seems to work fine, so I moved on with ls to verify the result:

paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ mpremote fs ls
ls :
           0 RP2040_Micropython_voltage_control/
        1034 button_text.py
        2543 connecttoweatherstation.py
        2763 fill_bubble_rect.py
         815 findMax.py
         327 fsram_check.py
        2503 main.py
         129 make_LFS2.py
        1240 overclocktestMultiThread.py
         736 overclocktester.py
       20869 png_decoder_test.png
       36743 st7789py.py
         394 test.py
        1472 testingpng.py
         926 weatherstation.py
paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ 

As well as df:

paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ mpremote df
mount   size    used    avail   use%
    8388608 1372160 7016448 16
flash   8388608 1372160 7016448 16
paul@paul-ThinkPad-X1-Yoga-2nd:~/Thonny$ 

Note, that 8388608/1024/1024=8MB. And gc.mem_free() returns with: 96560/1024=94.296875KB. And also please note that micropython v1.14 uses less RAM due to some missing functionalities. So it's not a valid comparison anyway. So far, again, I could not replicate any of the issues you have described.

File "<stdin>", line 1, in <module>
OSError: [Errno 5] EIO

Tho, this is a little sus, could this be caused by some characters in the file that is not in uft-8 format?

[davefes]

@nspsck : Thank you for your added effort. WeACT Studio also has been very helpful. He wanted to know what distro I was using, but no feedback on whether he tried it or not.

My next step was to do a diff on WeACT's board files to see if there is a clue in there.

I still feel uncertain about the DFU-process, ie why I have to use A10 to ground. Have you ever come across a definitive STM process for getting into DFU-mode? I wonder if that has done something bad to my boards.

I am happy using STM32CubeProgramming, so if I buy more boards I will drop the use of firmware.dfu.

[nspsck]

I still feel uncertain about the DFU-process, ie why I have to use A10 to ground. Have you ever come across a definitive STM process for getting into DFU-mode? I wonder if that has done something bad to my boards.

My personal experience with the newest blackpill (v3.1) is a little different. I have never had to do extra steps such as grounding A10. I just press boot and reset then release reset first, that is all I had to do to get into dfu mode.

[davefes]

I got "locked-into" the A9/A10 recommendation. I will try buttons without doing anything with A9 or A10. I will get back into this tonight.

[davefes]

I see you have put a lot of work into mpconfigboard.h, so I will not be looking for clues in these files.

One thing I noticed with WeACT Studio v1.14 was that there were two elements loaded in firmware.dfu, yours is only one element.

[davefes]

Well, using Thonny actually seems to work:

dave@davef:~/.config/Thonny$ mpremote run /home/dave/2_STM32F411/make_LFS2.py
got this far
dave@davef:~/.config/Thonny$ mpremote run /home/dave/2_STM32F411/what_filesystem.py 
Littlefs v2 filesystem
0008  magic                            littlefs
0014  version                          0x20001
0018  block_size                       4096
001c  block_count                      2048
0020  name_max                         255
0024  file_max                         2147483647
0028  attr_max                         1022
dave@davef:~/.config/Thonny$ mpremote
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell

BUT no other lines, ie:
MicroPython v1.22.0-preview.162.g6117aa686.dirty on 2023-11-19; WeAct Studio Blackpill v3.1 8MB with STM32F411CE
Type "help()" for more information.
>>>

>>> dave@davef:~/.config/Thonny$ mpremote ls :
ls :
dave@davef:~/.config/Thonny$ mpremote cp /home/dave/2_STM32F411/what_filesystem.py :
cp /home/dave/2_STM32F411/what_filesystem.py :
dave@davef:~/.config/Thonny$ mpremote ls :
ls :
        3350 what_filesystem.py

dave@davef:~/.config/Thonny$ mpremote df
mount   size    used    avail   use%
    8388608 12288   8376320 0
flash   8388608 12288   8376320 0

I could get into dfu-mode but found that you have to insert the USB cable and within 1-2 seconds press BOOT and then quick press NRST ... just a bit tricky.

Will need to see what is special about the way Thonny talks to the board, compared to mpremote by itself or rshell.

[davefes]

Thought I would just try rshell and was pleasantly surprised that I can now see the files on the WeACT. The only thing that I have done differently was the way I got into DFU-mode before a mass-erase and firmware.dfu upload.

Another board I just can not get into DFU-mode the way you described.
https://github.com/WeActStudio/WeActStudio.MiniSTM32F4x1/tree/master and how to get into ISP mode have another 5 different ways.

Getting into DFU-mode is "hit and miss" and trying to talk to the filesystem via USB is much the same.

[nspsck]

One thing I noticed with WeACT Studio v1.14 was that there were two elements loaded in firmware.dfu, yours is only one element.

That is not necessary. Specifying TEXT1_SECTIONS and TEXT0_SECTIONS only split the firmware in half, as long as nothing has been changed in the .ld file, these has no other effects than that. And if any of these are wrongly specified, it will prevent the firmware from booting. Since I often changed the .ld in the past, I left it out.

BUT no other lines, ie: MicroPython v1.22.0-preview.162.g6117aa686.dirty on 2023-11-19; WeAct Studio Blackpill v3.1 8MB with STM32F411CE Type "help()" for more information.

You have to close Thonny or even reboot the device after so thonnyand mpremotewon't fight over the same serial port.

Will need to see what is special about the way Thonny talks to the board, compared to mpremote by itself or rshell.

That is probably also irelevant to the problem you are facing. But would be a really interesting topic.

I could get into dfu-mode but found that you have to insert the USB cable and within 1-2 seconds press BOOT and then quick press NRST ... just a bit tricky.

You can simpely plug it in, press boot then press nrst, then release nrst. That's already the whole process to get you into dfu-mode already. There should not be any specific timing or orther complications. Wether you release the boot button at the end is also not relevant.

Thought I would just try rshell and was pleasantly surprised that I can now see the files on the WeACT. The only thing that I have done differently was the way I got into DFU-mode before a mass-erase and firmware.dfu upload.

So the problem is solved?

Another board I just can not get into DFU-mode the way you described.

Am assuming that is not a WeAct product, at least not the v3.1 version. I do have those pirated boards and yes, they can not get into dfu-mode as easy and they were more expensive. However st-link works flawlessly on those and after the firmware has been flashed, their usb port seems just to function fine. There is really no real easy "fix" for those boards for them to be functioning as an official one, sadly.

Getting into DFU-mode is "hit and miss" and trying to talk to the filesystem via USB is much the same.

Well, that should not be.

[davefes]

OK about Thonny.

I am only working on 4 brand-new WeACT boards all with the same batch number of STM32F411s. (Hopefully, that cuts down the number of variables.)

Perhaps there is something wrong with my host computer as each board requires a lot of "hit and miss" getting into DFU-mode, ie different pin connections.

One board works with your firmware and I can only get one to work with my firmware built from your instructions.

I will do more testing today and when I get all 4 boards behaving the same I will let you know.

[davefes]

I do not think I will get all 4 boards behaving the same. I have 2 boards with your 8MB firmware, change to LFS2 and cp files to. Another board with my build of 8MB firmware, change to LFS2 and cp files to.

The 4th board I removed all connections to the LoRa module and using STM32Cube did a SPI flash erase then put on your 8MB firmware doing an erase before programming. It stalls at Retrieving sysname ... pyboard, which is an indicator that nothing else is going to work. If I put your "Regular" firmware on everything works with VFAT. Did not try LFS2.

I was using pins B0, B1, B2, B10, B13, B14 and B15 for LoRa module connections, which should all be "safe" pins to use.

I can only conclude that one board is damaged and/or something prevents rshell or mpremote talking to it when it has 8MB firmware on it.

[nspsck]

Have you done a factory reset on the 4th board with my 8MB version? If that board has a corrupted filesystem on the spi flash, it will not work.

A factory reset can be done by holding down the user key button during the boot process. One way of doing this is to hold down the key-button then press the reset button then wait for the led to stop blinking or a USB pops up.

[davefes]

I have never done a factory reset. I have always done a SPIFlash_Erase_Firmware.hex from the WeACT Studio website before uploading firmware.hex

I will try a factory reset.

Did not make any difference. The led stopped blinking then I did SPIFlash_Erase_Firmware.hex and then your 8M firmware.hex.

[davefes]

dave@davef:~$ mpremote run /home/dave/2_STM32F411/what_fs.py 
FAT filesystem
0000  jump                             eb:fe:90
0003  OEM name                         MSDOS5.0
000b  sector size (bytes)              512
000d  cluster size (sectors)           8
000e  reserved area (sectors)          1
0010  number of FATs                   1
0011  size of root dir area            512
0013  volume size (sectors)            16384
0015  media descsriptor                0xf8
0016  FAT size (sectors)               7
0018  track size (sectors)             63
001a  number of heads                  255
001c  volume offset (sectors)          256
0020  volume size (32-bit) (sectors)   0
0024  physical drive number            128
0025  error flag                       0x0
0026  extended boot signature          0x29
0027  volume serial number             0x46210003
002b  volume label                     NO NAME 
0036  filesystem type                  FAT     
01fe  signature                        0xaa55
dave@davef:~$ mpremote cp /home/dave/2_STM32F411/make_LFS2.py :
cp /home/dave/2_STM32F411/make_LFS2.py :
dave@davef:~$ mpremote ls
ls :

and copying the file takes a long time ... but where did it go?

[davefes]

As your "regular" version firmware runs on the 4th board and the other three boards can work with your 8MB firmware ... let's just say that the SPI Flash is faulty on 1 out of 4 boards. I can still use it for remote sensor applications.

Thank you for all the hints ... I had never come across any previous suggestions to do a factory reset,

[nspsck]

Did not make any difference. The led stopped blinking then I did SPIFlash_Erase_Firmware.hex and then your 8M firmware.hex.

So after you did the factory reset and before you did the spi flash erase hex file, have you tested it? The factory reset is provided by Micropython and it tries to format the spi flash to fat. You don't need the spi flash erase hex and it is hard to predict what that hex firmware does without knowing what its assumptions are and what it actually does (i.e. does it make all sections 0 or all sections 1 or something else).

and copying the file takes a long time ... but where did it go?

Yes it does take a long time (for a file of size 1MB, it took me several minutes) to copy the file, and it's way slower than using it as a USB device with a fat filesystem. This is completely normal.

Can you please try adding fs before the cp and ls command?

As your "regular" version firmware runs on the 4th board and the other three boards can work with your 8MB firmware ... let's just say that the SPI Flash is faulty on 1 out of 4 boards. I can still use it for remote sensor applications.

If you have done the above described factory reset and it fails you, you can assume the spi flash is faulty.

[davefes]

Now that I know about factory reset I have removed that SPIFlash_erase from my work-flow.

I am always using STM32Cube to upload the firmware, for the official WeACT boards, thereby circumventing the DFU process.

copying the file takes a long time

refers to copying make_LFS2.py about 130 bytes. I guess some sort of time-out is occurring as the file is probably not transferred.

OK on fs ... the df example in the docs doesn't have it, because they say:

Note: For convenience, all of the filesystem sub-commands are also aliased as regular commands, i.e. you can write mpremote cp ... instead of mpremote fs cp ....

but I'll try, just in case something else is acting-up :)

I think everything is OK with the WeACT boards, ie one faulty SPI chip. Moving on to getting micropython/lora working on these new boards.

[davefes]

Maybe factory reset works on a PYboard but when I do it on the 8MB variant everything is still there.

[nspsck]

You are partially right, the factory reset will first check wether the filesystem is corrupted by trying to mount it as /flash, if that fails, a factory reset, aka an erase and formatting on the spi-flash will be performed otherwise it skips this part. This is meant to save the corrupted filesystem but not an unconditional filesystem reset.

[davefes]

Clever application ... I should read all the way to the bottom of the doc!

[nspsck]

Hi, sorry to bring this back up, with the newly arrived blackpills, I have noticed some really weird issues, first of all, the pin headers came in the same package. (It's supposed to be separated). The 25MHz crystal is now labeled as YXC and no longer SJK. 1 out of 7 boards, with out spi-flash had a faulty USB. All 7 boards could not be flashed using just the usb port. These new ones are produced in Germany rather than Ireland (printed on the package).

So I wonder, does these also hold true for your boards? It seems like a factory issue that WeAct must be informed.

[davefes]

O dear ... my boards were separate from the pin headers and the packets say they are made in Ireland.

1 out of 7 boards, with out spi-flash had a faulty USB.

Are they not 8MB boards? Referring to the "with out spi-flash"

Yes, WeAct need to be informed, I have found them to be VERY helpful.

Good luck!

[nspsck]

Are they not 8MB boards? Referring to the "with out spi-flash"

No, they are not, also, all (20 out of 20) of these 8MB boards have the same firmware flashing issue. Tho, files copying works just fine.

O dear ... my boards were separate from the pin headers and the packets say they are made in Ireland.

Great, this actually confims my theory about the germany factory. Let's see if they are going to do something about it.

[davefes]

Sorry, I should not have said ... are they not 8MB.

Are they all 8MB boards?