F405 & F411 versions of the BluePill

What are you developing?
User avatar
Squonk42
Posts: 245
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: F405 & F411 versions of the BluePill

Post by Squonk42 » Fri Dec 08, 2017 10:33 pm

I also changed the power for the AP2112 analog supply LDO from +3.3V to +5V and made VBAT trace thinner.

And I am pretty confident that if I replace the 32kHz crystal by a smaller FC-12M package as suggested by @racemaniac, I will be able to fit the ferrite bead between GND and AGND, which should cover most of the problems we found so far.

Then, we have all the options as footprints only (battery charger, IMU, RGB LED...)!

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F405 & F411 versions of the BluePill

Post by RogerClark » Sat Dec 09, 2017 4:48 am

Guys

Just in case I'm missing something with KiCad.

Can you guys confirm that the footprint dragging doesnt work in OpenGL mode, but the interactive Push / Shove (of tracks) feature only works in OpenGL mode.

So if i want drag a track I need to switch to OpenGL to take advantage of the Push/Shove but if I want to drag a component and keep the track segments attached by simple rubber banding, this only works in "Canvas" view mode ??

PS. I'm using the latest stable version (4.0.7) not the "nightly" builds (I've heard that the nightly's are much more advanced than the stable, but normally the Stable is good enough for me)

victor_pv
Posts: 1791
Joined: Mon Apr 27, 2015 12:12 pm

Re: F405 & F411 versions of the BluePill

Post by victor_pv » Sat Dec 09, 2017 5:55 am

Roger, it's the same for me with dragging, tracks only in openGL.
I haven't tried dragging a component in canvas mode, need to try that, but in OpenGL dragging a component doesn't drag the tracks attached to for me.
So openGL mode is the same for me as you describe.

racemaniac
Posts: 658
Joined: Sat Nov 07, 2015 9:09 am

Re: F405 & F411 versions of the BluePill

Post by racemaniac » Sat Dec 09, 2017 7:14 am

that's indeed one of the annoyances in KiCad... none of the canvas modes are complete yet. I hope for KiCad5 they'll resolve that.

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F405 & F411 versions of the BluePill

Post by RogerClark » Sat Dec 09, 2017 8:00 am

OK..

Thanks.

Hopefully in the next version they will unify things, as its not ideal having to switch in and out of OpenGL mode

User avatar
Squonk42
Posts: 245
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: F405 & F411 versions of the BluePill

Post by Squonk42 » Sun Dec 10, 2017 10:24 am

Looking at the AN2606, p. 97, section 25.1.2, the STM32F40xxx/41xxx devices bootloader checks USARTx (USART1 and USART3, both on port B & C) and CANx (CAN2) for a specific character of frame before checking the USB cable to execute the DFU bootloader.

This means that for reliable operation, the bootloader should have stable levels on USART1_RX (PA10), USART3_RX (PB11 and PC11), CAN2_RX (PB5) pins during boot, in addition to BOOT0 being high and BOOT1 (PB2 pin) being low, which is the case when the BOOT0/USER button is pressed.

This is confirmed by a remark in the MicroPython board schematic:

Code: Select all

USB DFU requires stable levels on PA10, PB5, PB11 & PC11. PB2 must be low during boot.
Based on your experience, is it something required, or is it an unlikely situation that may be fixed with retries if we accept to press the RESET + BOOT0 buttons several times until it succeeds?

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F405 & F411 versions of the BluePill

Post by RogerClark » Sun Dec 10, 2017 9:08 pm

Seems unlikely that a specific character would arrive on those pins unless one was specificly sent to the MCU.

Even if the pins were randomly toggling with noise it would only be a 1 in 256 times that the data would match the pattern.

And in reality I don’t think the input pins randomly toggle, unless you attach a long length of wire to them to pickup noise, and in most cases that would pick up mains hum of 50 or 60 Hz

e.g.
With the RobotDyn Black Pill boards that I received the other day, they did not send jump links, so I did not solder the boot0 or boot1 pins. I just flashed the bootloader via STLink and they worked fine even with boot0 technically floating.

The Maple mini does not pull boot1 low but unless you stick your finger on that pin, it’s possible to reflash just by pulling boot0 high.

I need to test this hypothesis, but I suspect the pins have a tendency to float low.

victor_pv
Posts: 1791
Joined: Mon Apr 27, 2015 12:12 pm

Re: F405 & F411 versions of the BluePill

Post by victor_pv » Sun Dec 10, 2017 11:42 pm

I have not used the hardware dfu in the F4, normally just use the STLink.
That said, I see we have two options:
  1. add extra components to pull those pins low, which may affect their usage for other functions (if the pull down is too weak, it may not have an an effect other than if the pins are floating, if the pull down is strong, then it may affect other uses.
  2. leave then like they are, in the particular conditions they may affect usb dfu bootloader
My vote goes for the second option, since I believe the conditions in which may cause the bootloader to not get to the USB port, would be only if there is something in serial sending that character, and in that case the pull downs would not help, since I would expect whatever serial device is in the other end to be stronger than the pull downs, otherwise your serial functionality is compromised. I don't think something else other than serial will cause it to randomly get the special character.
If it happens, then the stlink pins are available, and if not, we can load our own bootloader that goes straight to USB and that's it. There is code from STM that Roger and me tested a couple of months back. If we need to, we can work on that to make it funtions the way we want. We could even add sdio support to upload boards with a bin in the sdcard.

User avatar
Squonk42
Posts: 245
Joined: Thu Dec 29, 2016 9:25 am
Location: Bordeaux, France

Re: F405 & F411 versions of the BluePill

Post by Squonk42 » Mon Dec 11, 2017 6:08 am

Ok, thank you for your feedback!

I will then implement solution #2 (not care about it) since 1) I think this situation is unlikely and can be fixed by a simple retry and 2) it is easier, since there is nothing to do!

Uploading a board from a bin file on the sdcard would be great!

I fixed all problems in the TODO list, it just needs more cleanup (more trace shufflîng, 3D models for new 32kHz crystal and Schottky diode, etc.).

User avatar
RogerClark
Posts: 7541
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: F405 & F411 versions of the BluePill

Post by RogerClark » Mon Dec 11, 2017 6:32 am

I've tested DFU upload on one F4 board, and it seemed to work every time.

I checked the board and it does not have a pulldown on PA9 or PA10

I also checked the STM32 Stamp schematic (there is a copy in my repo in the STM32F4Stamp folder) and that board does not have a pulldown on PA9 or PA10 (it can however use PA10 to connect to the serial port, I presume to signal OTG) if a jump link is installed


I think the micropython team are being over-cautious.

BTW. I find using the built in DFU hard to use, as its unclear whether code can reboot/reset the MCU into its internal DFU mode, so you would have to keep boot0 high, and press the reset button each time

(It may be possible to jump to the bootloader but I don't think anyone has proved they can do that)

I know Victor has written a DFU bootloader, based on STM's example code, and they would initially be the best thing to use (apart from STLink)
However because both the internal DFU bootloader and the one from ST'M's code, use DFUSe, it is not compatible with the F103 DFU drivers or DFU-Util, so if I get time I want to investigate porting the existing F1 bootloader to F4
I know its possible, but the code to do it seems to have been lost.

Post Reply