F405 & F411 versions of the BluePill

What are you developing?
Post Reply
kalmiya
Posts: 23
Joined: Mon May 20, 2019 6:57 pm
OS: MacOS, Windows, Linux
Board: bluepill, arduino

Re: F405 & F411 versions of the BluePill

Post by kalmiya » Fri Aug 02, 2019 6:07 pm

I'm too clumsy with a sharp knife, would damage the entire board before I got the processor off.

Instead I just gently pushed up a corner with a pincer, while blowing hot air at the MCU pins and it popped off easily, way before other components could start to float away. Put on a new MCU and it connects via SWD... repeated the procedure with another board and that one also connects via SWD now.

That gives a total of 5 boards that connect (+ 2 which I won't bother fix due to an awful soldering job) - a bit more than expected but oh well. Next seeing what happens if they are programmed.

User avatar
Squonk42
Posts: 59
Joined: Wed Feb 27, 2019 5:17 pm
Location: Boredaux, France
OS: Linux
IDE: Arduino, Sloeber, Emacs
Core: Roger's, STM official, bare metal
Board: All
Contact:

Re: F405 & F411 versions of the BluePill

Post by Squonk42 » Fri Aug 02, 2019 8:18 pm

Good to know they arose from the dead :P

The 90° RGB LEDs probably killed them, but the STM32 are generally quite resistant to all kinds of damages.

kalmiya
Posts: 23
Joined: Mon May 20, 2019 6:57 pm
OS: MacOS, Windows, Linux
Board: bluepill, arduino

Re: F405 & F411 versions of the BluePill

Post by kalmiya » Sat Aug 03, 2019 2:51 pm

Yeah, I'm really glad too about that, sad for the loss of the cpu's, I hope the next person trying this can learn from my mistakes :)
The 90°RGB LED would only explain 2 of the boards breaking, so it can't be just limited to that.

One question, do you need to do something special "timer-wise" for the F4 variation when programming it via the Arduino-IDE?
When doing a simple blink test, a delay of 100ms seems to exactly be 1000 ms ( 10x as long ).
However when programming via HAL the delay works exactly as expected :?

As a bigger test, tried the stm32-o-scope on an f103 variation of the board:
Are there any other tests you ran the devices through, to verify their functionality?

Note: stm32duino.com seems to be down now, that's quite sad as it had a wealth of information (quite a lot of backlinks don't work anymore). Any idea if there's a mirror anywhere? I only have a backup of the 90+ page f405 design thread (if anyone needs that let me know).
Last edited by kalmiya on Sun Aug 04, 2019 10:17 pm, edited 1 time in total.

User avatar
Vassilis
Posts: 127
Joined: Wed Feb 27, 2019 5:09 pm
Answers: 2
Location: Thessaloniki, Greece
OS: Linux, Win10, MacOS
IDE: Arduino 1.8.9
Core: Roger, STM official
Board: Bluepill, Maple mini, STM32F4xx
Contact:

Re: F405 & F411 versions of the BluePill

Post by Vassilis » Sat Aug 03, 2019 3:38 pm

kalmiya wrote:
Sat Aug 03, 2019 2:51 pm
... Note: stm32duino.com seems to be down now, that's quite sad as it had a wealth of information (quite a lot of backlinks don't work anymore). Any idea if there's a mirror anywhere?
Yes. Look at web.archive.org
-Vassilis Serasidis

kalmiya
Posts: 23
Joined: Mon May 20, 2019 6:57 pm
OS: MacOS, Windows, Linux
Board: bluepill, arduino

Re: F405 & F411 versions of the BluePill

Post by kalmiya » Fri Aug 16, 2019 7:20 pm

Took me a bit to realize the default 25Mhz hse, as generated by CubeIDE was wrong, as the hardware has an 8Mhz crystal, but after that got usb running. So now that the boards are working, gave Eagle a go...

First attempt, fix the "0 Ohm hack". So as I understand it, R6 needed to be removed. This also disrupts the 3V going to 4th pin of the rgb-led, so that needs to be recreated. The "ratsnets" then takes care of connecting pin3 of S2 to ground (which was previously hacked by connecting ground of R6 to ground of the capacitor next to it)...

http://www.boerdijk.org/images/2019/pcb/F4-B.zip

And trying to make an F7 board out of it.. several pins move 1 to the left in the schema (to the right in the board because upside-down), so (without modifying the mcu footprint itself - didn't know how to):
previous PC5 (doesn't exist on the F7), is replaced by BP0 (i.e. PB0 moves 1 left)
previous PB0 is replaced by PB1
previous BP1 is replaced by PB2
previous PB2 is replaced by PB10
previous PB10 is replaced by PB11
previous PB11 becomes VCAP_1
and previous VCAP_1 becomes a GND (which doesn't exist on the F4)

Applying that on the board and I got to this point:

http://www.boerdijk.org/images/2019/pcb/F7-B.zip

Does that look about right?

User avatar
Squonk42
Posts: 59
Joined: Wed Feb 27, 2019 5:17 pm
Location: Boredaux, France
OS: Linux
IDE: Arduino, Sloeber, Emacs
Core: Roger's, STM official, bare metal
Board: All
Contact:

Re: F405 & F411 versions of the BluePill

Post by Squonk42 » Fri Aug 16, 2019 8:42 pm

kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
Took me a bit to realize the default 25Mhz hse, as generated by CubeIDE was wrong, as the hardware has an 8Mhz crystal, but after that got usb running. So now that the boards are working, gave Eagle a go...
:roll: Not easy to find this one!
kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
First attempt, fix the "0 Ohm hack". So as I understand it, R6 needed to be removed. This also disrupts the 3V going to 4th pin of the rgb-led, so that needs to be recreated. The "ratsnets" then takes care of connecting pin3 of S2 to ground (which was previously hacked by connecting ground of R6 to ground of the capacitor next to it)...
[
Yes, I suggest to have the +3V3 trace going down SE right to the RGB LED pin 4, I hate 90° angles ;) No, seriously, believe me: 45° angles provides a much better trace fill ratio on a PCB.
kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
And trying to make an F7 board out of it.. several pins move 1 to the left in the schema (to the right in the board because upside-down), so (without modifying the mcu footprint itself - didn't know how to):
previous PC5 (doesn't exist on the F7), is replaced by BP0 (i.e. PB0 moves 1 left)
previous PB0 is replaced by PB1
previous BP1 is replaced by PB2
previous PB2 is replaced by PB10
previous PB10 is replaced by PB11
previous PB11 becomes VCAP_1
and previous VCAP_1 becomes a GND (which doesn't exist on the F4)

Applying that on the board and I got to this point:

Does that look about right?
Yes, AFAICT! But the VCAP capacitor must be a 4u7 with a 0.1R to 0.2 ESR.

kalmiya
Posts: 23
Joined: Mon May 20, 2019 6:57 pm
OS: MacOS, Windows, Linux
Board: bluepill, arduino

Re: F405 & F411 versions of the BluePill

Post by kalmiya » Sat Aug 17, 2019 9:30 am

Squonk42 wrote:
Fri Aug 16, 2019 8:42 pm
kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
Took me a bit to realize the default 25Mhz hse, as generated by CubeIDE was wrong, as the hardware has an 8Mhz crystal, but after that got usb running. So now that the boards are working, gave Eagle a go...
:roll: Not easy to find this one!
Yeah, took me a few evenings. I caught on to it when trying SWO debugging, and you need to enter the clockfrequency (168Mhz), where it wouldn't communicate. Trying another board (nucleo) it worked instantly.. Then tried a few random frequencies, some of them gave (very consistent) garbage - just like serial comms on a wrong baudrate. So I started at 1Mhz and went up in 1Mhz increments and at 51Mhz it started to work correctly (52, 53 also work)... So 168/51 = 3.29 ( which is a rough estimate, since 51 is just a "good guess"). So while looking at the HSE of 25Mhz and / 3.29 = 7.5... suspiciously close the 8Mhz and that made it click for me - in hindsight, it's actually super-obvious :)

Which also mades me wonder about taking the other route and instead of an 8Mhz crystal, take a 25Mhz one ( like this: https://nl.mouser.com/ProductDetail/581 ... GA25DPTVCC)... that would be a drop-in replacement, right?
Not that it's necessary, since you can tweak a load of stuff in that clock configuration panel, and you get to the 168Mhz by tweaking it, and as I understand 25Mhz is (for some reason) only relevant if you want to do ethernet communication...
Squonk42 wrote:
Fri Aug 16, 2019 8:42 pm
kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
First attempt, fix the "0 Ohm hack". So as I understand it, R6 needed to be removed. This also disrupts the 3V going to 4th pin of the rgb-led, so that needs to be recreated. The "ratsnets" then takes care of connecting pin3 of S2 to ground (which was previously hacked by connecting ground of R6 to ground of the capacitor next to it)...
[
Yes, I suggest to have the +3V3 trace going down SE right to the RGB LED pin 4, I hate 90° angles ;) No, seriously, believe me: 45° angles provides a much better trace fill ratio on a PCB.
Heh, so this gives an ocean space to add new stuff, and I should just pull a 45 degrees trace diagonally through it? What a waste :lol: ;)
Just kidding, I'll gladly take your experience and change it :) Pulling those traces, especially on the F7 board was suprisingly difficult... they jump everywhere you don't want, overlap etc... That puts the effort of the original design even more in context.
Squonk42 wrote:
Fri Aug 16, 2019 8:42 pm
kalmiya wrote:
Fri Aug 16, 2019 7:20 pm
And trying to make an F7 board out of it.. several pins move 1 to the left in the schema (to the right in the board because upside-down), so (without modifying the mcu footprint itself - didn't know how to):
previous PC5 (doesn't exist on the F7), is replaced by BP0 (i.e. PB0 moves 1 left)
previous PB0 is replaced by PB1
previous BP1 is replaced by PB2
previous PB2 is replaced by PB10
previous PB10 is replaced by PB11
previous PB11 becomes VCAP_1
and previous VCAP_1 becomes a GND (which doesn't exist on the F4)

Applying that on the board and I got to this point:

Does that look about right?
Yes, AFAICT! But the VCAP capacitor must be a 4u7 with a 0.1R to 0.2 ESR.
... thanks for the tip ( now to figure out what those "special" capacitors are ;) )

Seems like those are difficult to find ( or I might be looking for the wrong thing)...
- Yageo CC0603KRX5R5BB475, according to the datasheet somewhere between 0.10 and 0.20 Mhz it dives below 0.2R ad stays below to 100Mhz- not sure of those are good ?
- The Murata LLR series with E01 (=100mΩ±30%+ which seems perfect, but those only exist in 1.0 uF)
- Johanson R14S-series, but those only go to 100pF (https://www.johansontechnology.com/r14s)

:? .. anyone have a product-code for a matching one?

kalmiya
Posts: 23
Joined: Mon May 20, 2019 6:57 pm
OS: MacOS, Windows, Linux
Board: bluepill, arduino

Re: F405 & F411 versions of the BluePill

Post by kalmiya » Sun Aug 18, 2019 12:19 pm

Okay, so vcap1 capacitor - as you mentioned, the F7 datasheet says :


Trying to understand what that sentence means, it very explicitely says < 2 Ohm for the vcap1/2 case,
whereas for the vcap1 range it mentions a range of 0.1 - 0.2 R... so below 0.1R is not ok?

And the graphs always show a frequency on the other axis...
What frequency are we looking at? 8Mhz exactly (for the NX3225GD oscillator) ?
Because having seen quite a few of those graphs, I don't think there's going to be one where it is between 0.1-0.2R over the entire range ( saw several which drop sharply down from ~10Ohm at the start ).

Picking a Murata 0603 cap with 4.7uF and a relatively high max-voltage gives the following "R" graph:


... which shows 0.02 Ohm @ 8 Mhz (green line)... so not good (because not in the range)?

Similar this one: 6R3R14X475KV4T tanceram from Johanson (0603, 4.7uF)

Also starts above 0.2 and then dives below the 0.1R...

Post Reply