search

nspsck / STM32F411CEU6_BlackPill_Micropython

MIT License
5 stars 1 forks source link

Problem flashing application code on latest firmware versions. #10

Closed davefes closed 3 weeks ago

davefes commented 3 weeks ago

Was getting the following error when trying to flash code : timed out or error in transfer to remote: b'' Went back to the previous version Nov 2023 and no problems.

Were the Nov 2023 versions setup to automatically go to LFS2?

Appreciate any suggestions.

Thanks

davefes commented 3 weeks ago

I think I solved it ... I had PA0 connected to a LoRa chip while flashing the firmware. If I remove it the latest base-version flashes and runs OK.

Seems it was possible to load code with PA0 connected using the older firmware.

davefes commented 3 weeks ago

Nope ... what seems to happen is that on WeACT boards with the 8MB flash the only firmware that will work is Nov 2023 base-version.

I suspected flash problems before so I removed the 8MB flash and the latest base-version works. I don't want to remove any more flash chips. I don't need the extra flash so I will stick with the Nov 2023 base version.

I have 5 boards (25MHz with 8MB) coming and I will try the latest 8MB firmware on those.

nspsck commented 3 weeks ago

Were the Nov 2023 versions setup to automatically go to LFS2?

No, LFS2 was never turned on by default. Tho, since October 2023, the LFS2 was provided by default in the firmware. If you were to use LFS2, you had to do that manually according to this guide.

If you were using the newest firmware and by some chances uses SPI4 or SPI5, then this is absolutely my bad. I enabled SPI4 or SPI5 recently and their MISO pins can only be set to the default USB pins. (A11 and A12). Hence you won't be able to upload files reliably. I have removed the MISO pins now.

davefes commented 3 weeks ago

My first reaction was ... but I don't use anything in () ... but some how I ended up using B1 and B0. So with an older base version was I able to "get-away with it"? I picked-up these STM32F411, as I needed to replace some old ATMega88 projects, and obviously have to re-learn some stuff.

I will change the pins and try the latest firmware. Thanks.

nspsck commented 3 weeks ago

but I don't use anything in ()

ugh... am bit confused...

but some how I ended up using B1 and B0

B1 and B0 are fine to use as standalone pins. But if you were using SPI5, then there is a problem, because enabling SPI5 will re-initialize the A12 from USB_DP (or USB_DM (Data +, Data -)) to SPI_MISO. Hence problems with USB. Hence failed file transfer.

So with an older base version was I able to "get-away with it"?

Ye, when I first published these, the SPI4 and SPI5 as well as USART6 was disabled by default. Meaning you can not enable them at all. So they will not cause problems. Then I was like: "ok, maybe I should just make all resources available". Then I made all these peripherals available. So we will have problems.

I will change the pins and try the latest firmware. Thanks.

In the latest firmware, I disabled MISO (meaning, they can only control devices those does not return any signals, i.e. a tft display) for SPI4 and SPI5 so you do not have to worry about SPIs anymore. But I still suggest you to have a look at the pins definitions to avoid conflicts.

davefes commented 3 weeks ago

I now understand that if you do not use SPI5 then you could use B1, B0, A12 and A10, at least in the older firmwares. I possibly knew that 6 months ago! I will be more careful with newer firmware.

At the moment I have nothing connected except A9 and A10 for rshell. I did a full erase in STM32 Cube Programmer, downloaded your latest 25MHz_8MB firmware and then try to copy a file called what_fs.py and I get the error: timed out or error in transfer to remote: b''

nspsck commented 3 weeks ago

I found this thread reagarding similar issue. But it also could just be caused by a FS-corruption. Have you tried to format the FS after you flashed the new firmware?

nspsck commented 3 weeks ago

Also, I'd recommend mpremote, cause it's better maintained and is from the official team. You can find the documentations here.

davefes commented 3 weeks ago

I had read that one. I can not format the FS because I can not up load any files to the board. I played around with mpremote months ago, I'll try using that.

nspsck commented 3 weeks ago

I do not think you have to up load files to the board to format the FS. All you need to do is to run the following code succesfully:

# format to fat32 first
import os, pyb
os.umount('/flash')
os.VfsFat.mkfs(pyb.Flash(start=0))
os.mount(pyb.Flash(start=0), '/flash')
os.chdir('/flash')

# after reset, format it to Lfs2
import os, pyb
os.umount('/flash')
os.VfsLfs2.mkfs(pyb.Flash(start=0))
os.mount(pyb.Flash(start=0), '/flash')
os.chdir('/flash')

And, i.e. if you were unable to unmount /flash, then you know that there is a problem. Which may help you further. In case it all succeded, your FS is formated.

davefes commented 3 weeks ago

OK, you would run that using mpremote. Well the software was running on the 8MB board with the old base version, I put your new 8MB firmware on and using mpremote connect auto the program was running! So, it looks like I will spend time getting up to speed using mpremote. Thank you and good night.

nspsck commented 3 weeks ago

You are welcome! You too a good night!

davefes commented 3 weeks ago

Just some feedback re mpremote and firmware issues. I have been able to use mpremote on ESP32 boards.

Using mpremote on a WeACT board with an old base-version allows me to do most mpremote functions, except when I edit a file and try to copy it back to the board ... it is a 13K file and mpremote stops at 10-13% . rshell will copy that file to a board running the old base-version.

I have seen this behaviour on a STM32WLE5CCU6. I was told that you could only load 1-2K files due to conflict between flash writes and USB/UART, on that board ... maybe something similar on the BlackPill?