nspsck / STM32F411CEU6_BlackPill_Micropython

MIT License
5 stars 1 forks source link

Problem getting files on to 8MB BlackPill #5

Closed davefes closed 9 months ago

davefes commented 9 months ago

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 commented 9 months ago

I have ordered 27 in total, 20 of these are 8MB the other 7 are without.

davefes commented 9 months ago

OK. I am currently working with the E77-400M22S boards (STM32WL5x ) and I have problems copying files. mpremote does work ... most of the time.

You have only tested the "without spi-flash" boards? How do the 8MB boards perform?

davefes commented 9 months ago

I see you did comment about the 8MB boards.

nspsck commented 9 months ago

You have only tested the "without spi-flash" boards? How do the 8MB boards perform?

I have tested both, the only issue was the dfu-mode using USB port. Everything else works just fine.

davefes commented 9 months ago

I have dropped DFU, now use STM32CubeProgrammer. I would rely on "factory-reset" instead of that mass-erase script.

davefes commented 9 months ago

Are the batch numbers on the STM32F411 all the same? Maybe post the markings.

nspsck commented 9 months ago

they are from the batch 339, if the number goes upwards, then these are newer chips.

davefes commented 9 months ago

Mine are 334. Do they look like real STM32 parts?

nspsck commented 9 months ago

These are purchased at the official store, just shipped from the aliexpress choice storage. Optically there are 0 difference but the above mentioned labels on the 25MHz crystal.

davefes commented 9 months ago

Ah, the 25MHz xtals on mine are YZC as well.

nspsck commented 9 months ago

Ugh, none of mine is YZC. Ok, this might just have something to do with the batch. Not indicating the manufacture.

davefes commented 9 months ago

I meant YXC I would see that as the manufacturer as there is a smaller label at the bottom.

davefes commented 9 months ago

BTW, the batch number on my 3 year old "regular" boards is 827 and the 25MHz crystal does not have a manufacturer name on them. Was probably a miracle that I finally got them to work!

nspsck commented 9 months ago

I meant YXC I would see that as the manufacturer as there is a smaller label at the bottom.

Oh, ok!

Was probably a miracle that I finally got them to work!

:D nice for you!

davefes commented 9 months ago

By "them" I mean both the cloned and the WeAct boards. I had a go at STM32F411 boards about 3 years ago. The "miracle" was someone producing this current firmware!

nspsck commented 9 months ago

:D thanx!

nspsck commented 9 months ago

Hi, so I asked WeAct about this. This unstability has something to do with the facotry settings of the HSI (high speed internal crystal) from ST. You can use a hot air gun or a hair dryer to keep the board warm and try to give it another shot.

nspsck commented 9 months ago

And they said they were going to make a newer version with 8MHz crystal to solve this problem permanetly, which is a hell yeah for me :D and maybe for you as well!

davefes commented 9 months ago

I had already tried that with the faulty 8MB unit as I had read some comment about getting the board up to 25C to get things working.

Did they suggest what we do with the faulty boards?? Did warming-up the boards help you? It sounds like you must have 20-30 boards, seems a big hobby project!

nspsck commented 9 months ago

Did warming-up the boards help you?

For me, if fixed the dfu-mode issue, now I can flash the firmware using dfu-mode through the USB port.

Did they suggest what we do with the faulty boards??

Not really, but I fixed my faulty board by pluging a good board into it and then plugged it into my pc. Here is a picture: IMG_20231206_191258

On the top is a functional balckpill and the at the bottom is the one with USB issues. Then I plugged the USB cable into the bottom (faulty one) and the usb problem is fixed for good. After that I no longer have to put both togather for the faulty one to work. Tho, this is not a suggestion by WeAct and it is actually fixed by accident, so I do not know what was actually going on.

It sounds like you must have 20-30 boards, seems a big hobby project!

:D I just ordered a bunch to do crazy experiments... more or less torturing these... to see what the limits are. Turns out these are way more robust than I have ever imagined.

davefes commented 9 months ago

Wow, how did you think of doing that? Back to the crystal unit ... it is just a crystal so the loading on it is determined by the STM32F411 or on-board capacitance. Ask WeACT if we can make a board modification.

davefes commented 9 months ago

I will ask Kan at the Aliexpress WeACT factory store.

davefes commented 9 months ago

I only program now, using the STM32Cube programmer.

davefes commented 9 months ago

https://community.st.com/t5/stm32-mcus-embedded-software/about-the-dfu-mode-on-a-weact-quot-blackpill-v2-0-quot-stm32f411/td-p/113464

OK, I see there are lots of hits on Google ... now that I know what I am looking for.

nspsck commented 9 months ago

Wow, how did you thinking of doing that?

Pure luck and curiosity.

it is just a crystal so the loading on it is determined by the STM32F411 or on-board capacitance. Ask WeACT if we can make a board modification.

It is just the crystal, I think you can just replace it with a 8MHz crystal of the same size. There is really not a lot things to be extra careful when swapping crystals. But some common sense like the formfactor, supported range (8 MHz is supported according to ST).

I only program now, using the STM32Cube programmer.

That's a solid piece of software, I must say!

OK, I see there are lots of hits on Google ... now that I know what I am looking for.

Yes! This has been a problem for a long while, and the store owner told me today, that they are going to change it to a 8MHz to solve this problem permanetly. While 25MHz might be useful for PHY interface, to be honest, not a lot ppl use these boards for that purpose anyway.

davefes commented 9 months ago

While I was outside splitting logs for next winter it occurred to me that you were using the "DFU signals" from one board to use on the other. A9/A10? Still, was it would be pure luck that the faulty board could recognise the proper signals from the good board.

I gave up working on 0201 components about a year ago. I do not have the proper equipment to change crystals. Did they offer to send you some 8MHz crystals?

nspsck commented 9 months ago

Did they offer to send you some 8MHz crystals?

Yes, but I also do not have equipments to change those.. So I said no thanks.

it occurred to me that you were using the "DFU signals" from one board to use on the other. A9/A10?

That's not the case and it was also not the intention. The USB uses D- and D+, which are essentially PA11 and PA12. My problem with that faulty board is, that the USB port aka. PA11 and PA12 was not functioning as these are supposed to. My PC could not recongnize it at all while mpy running on it perfectly. I then suspect, that something went wrong either with the crystal or the power supply. By lining up this board with a good board pin to pin, I was hoping that this will get the faulty board into the right state for each pin. (Likely to wire PA10 to GND so every thing is settled rather than floating) Then the magic just happened: it's fixed... To be 100% honest with you, I have no idea why that would work. In fact I still wonder what the issue actually was... So far, I couldn't bring the faulty board back to it's faulty state, so I also can not investigate further. Unless I own a good multimeter someday somehow.

davefes commented 9 months ago

Don't you just hate it when you seem to fix a problem and you don't know why.

the internal oscillator precision is altered above the tolerance band (1% around the theoretical value), the bootloader might calculate a wrong HSE frequency value. In this case, the bootloader DFU/CAN interfaces might malfunction or not work at all.

1%, is that internal oscillator an RC oscillator? 1% tolerance for any crystal oscillator should be 100-1000 times worst than typical.

nspsck commented 9 months ago

Don't you just hate it when you seem to fix a problem and you don't know why.

I can not describe how much I hated it using words invented by the human race.

1%, is that internal oscillator an RC oscillator? 1% tolerance for any crystal oscillator should be 100-1000 times worst than typical.

That internal oscillator probably has to be an RC oscillator, it is really hard to put a crystal oscillator into a chip. But that 1% tolerance is also partially caused by the 25MHz HSE. If the HSE were 8MHz, the tolerance will be roughly 6.5%. Which is a lot better!

davefes commented 9 months ago

Well, the BlackPill and the RFM96W still appear to be the best LoRa solution.

I could not use rshell/mpremote to work on the E77-400M22S, https://github.com/orgs/micropython/discussions/13160

WeAct Studio contact tells me that:

The supply will start in small quantities in the middle of the month.

... with 8MHz crystals.

nspsck commented 9 months ago

Wow, thanks for the informations! Pretty excited for this!