Installing Micropython on a blank STM

[Gordon_Hardman]

I have a board (own design) with a blank STM32F405RG (same chip as Pyboard). I connect the USB and run the ST "DfuSe Demo", but the device does not show up under "Available DFU Devices". Is there anywhere a "check list" of what to do with a blank chip to get Micropython on it?

Here is what I have:
1. Pin 5 of the micro-usb (ID pin) is not connected.
2. VBus is not brought into PA9 (I did not think this was necessary, but maybe I am wrong!).
3. Boot0 (pin 60) is pulled up to 3.3V. Chip has nice 3.3V on all Vdd pins.
4. Crystal is there, but no sign of oscillation using scope.
5. Both USB data lines are low all the time- no activity on scope.
6. When I plug in the USB, Windows 7 device manager does not show any change... So it is not detecting it, like when the Pyboard is plugged in.


I searched this forum and on the web, but did not find anything that gave the sequence of what needs to be done. I guess I should have figured this out before building the board... I thought the DFU would work with a virgin chip, but maybe there is something that needs to be done first? I saw several references to where folks had successfully installed on other boards like the Discovery, and did not see any special mention of what they did, but those chips probably had already been programmed at least once.

[dhylands]

You didn't mention BOOT1. I believe it has to be low and BOOT0 has to be high (at RESET time) to enter DFU mode.

There are a bunch of other pins which need to have pullups/pulldowns on them. See this document:
http://www.st.com/web/en/resource/techn ... 167594.pdf

Page 71 talks about '405. All of the other inputs that the bootloader can use need to be "quiet" which means having a pullup/pulldown so that they aren't floating, and not have anything connected which might cause the pins to change while booting.

You can boot the chip up using the UART bootloder even if the external crystal isn't working. See:
http://blog.davehylands.com/2014/02/ser ... m32f4.html

In order to use DFU, the external crystal need to be present, and have appropriately sized load capacitors. Otherwise the crystal may not start up. I believe Damien had to change the original ones he used on the pyboard in order to get reliable startup.

My brother also had some issues getting his board to come up:
http://blog.huv.com/2014/02/micropython ... ouble.html

[Gordon_Hardman]

Thanks- that helps a lot. Looks like I missed several things, especially the tricky little circuit on the bottom of P19. It appears you have to pull USB-DP up to 3.3V, although I don't see where that happens on the Pyboard....

Still don't have it working, but I have a bunch of things to try. Those documents are essential reading for anyone doing this!

[Gordon_Hardman]

Got it! Found a solder splash that was pulling NRST low... Never assume....

I did not implement the partial pull-up circuit that ST shows on P19, and it did not seem to matter.

It loaded the latest code from the site. Now I will test to make sure.

Thanks again- just needed a confidence boost!

[dhylands]

Thanks- that helps a lot. Looks like I missed several things, especially the tricky little circuit on the bottom of P19. It appears you have to pull USB-DP up to 3.3V, although I don't see where that happens on the Pyboard....

Still don't have it working, but I have a bunch of things to try. Those documents are essential reading for anyone doing this!

The pullup on USB-DP is probably only needed if you're trying to use one of the other bootloader modes. And the funny circuit is because USB uses pullups/pulldowns to mean different things depending on whether you're a host or a device. So The transistor is to turn the pullup off.

[Damien]

Glad you got it working!

In my experience getting DFU mode on blank STMs has been relatively hassle free. All you need is power, a connection to USB DP/DM, a crystal with correct load caps, and BOOT0/1 correctly biased. The docs say you need to keep some other pins stable, and the pyboard does have this feature, but in my experience it's not needed on prototype boards.

[Gordon_Hardman]

I may have spoken too soon! Everything loads okay, but I do not see a virtual COM port, or the USB drive that I would expect, when I let BOOT0 go low and do a reset. The DFU device in Device Manager goes away. Oscillator is running great at 8MHz all the time. I have done up Upgrade from the DFU Demo program a few times, it works 100%, so I am pretty sure the USB connection and oscillator etc. are solid. Any ideas?

[Gordon_Hardman]

I downloaded the latest DFU program from ST (3.04). It fixes the bug in 3.03 which caused the program to bomb when verifying. The "Verify" now passes successfully, so I know the code is in there! But still no COM or memory.

[dhylands]

The next thing is to make sure that the firmware was configured with the crystal frequency you're actually using.

The pyboard uses an 8Mhz crystal. I did a port to the Cerb40 II, which is basically just a 405 on a DIP carrier. If you look at stmhal/boards/CERB40 you can see the files which were created for that board.

The HSE_VALUE is set near the end of the stm32f4xx_hal_conf.h file.

The CERB40 is about as basic a port as can be done for the STM32F405 (and still have USB).

[blmorris]

In your initial post you mentioned this:

2. VBus is not brought into PA9 (I did not think this was necessary, but maybe I am wrong!).

I believe that PA9 is used by the firmware to detect whether it is connected as a USB device (rather than freestanding). Something to check, anyway.
-Bryan