Installing Micropython on a blank STM

[Gordon_Hardman]

That did it! Got a 10K and 470 ohm (closest I could get at Radio Shack), and put them in. Voila! All looks the same as the Pyboard. Thanks for the help with what were just failures to follow the Pyboard closely enough, and RTFM. Perhaps others who are laying out with this chip can avoid the wasted time.

[Gordon_Hardman]

That did the trick- all working fine now. Thanks to all who helped!

[plakkies]

Hi

Ive been having fun with the original board, so I bought some blanks and made a quick board. Ive attached the eagle files for the board. I assembled what Im thinking is the bare minimum for the board to program. That is the USB connector, the STM32F405, The resistors to the usb and the ones needed to stabilize the pins suggested and Ive added a jumper to BOOT0 to make it 3v3. There is also a mistake I found where the USB 5v shorts to ground by one of the switches, which I manually fixed. I also put a few of the caps in for a stable 3v3. I can see the 8Mhz oscilator working as well as the correct values of 3v3 on BOOT0 and 0v on BOOT1.
I have assembled two boards in case I made a solder splash somewhere as well.

Both boards do the same in that they are not detected by the pc as a DFU device when the original board does.

Can anyone see what Ive done wrong? It looks like it should be so simple.

You are welcome to use my eagle files if you wish.

Thanks to anyone who can help.

[Damien]

Can anyone see what Ive done wrong? It looks like it should be so simple.

Yes, it is pretty simple and I've rarely had an issue getting DFU mode working on prototypes.

Did you connect caps to VCAP1 and VCAP2? Did you ground all GND pins? Did you connect VDDA to 3V3?

If the 8MHz is oscillating then it's very likely it is in USB DFU mode (since the bootloader must configure the crystal to get the USB working). To test this you can reset the MCU with BOOT0 held low, and then the 8MHz should not start (because there's no code to start it). Then reset with BOOT0 held high and it should start.

Then I would check your USB connections. Make sure GND is connected through and the DP/DM are connected all the way to the MCU.

[plakkies]

The smallest things can really mess with you. I found the problem I had Dp and Dm swapped. swapping them back around I can now see it as a DFU device.

Next problem. It gives me an error when trying to flash it. Ive tried google and this forum and cannot find anyone with the same problem. Can anyone help? I'm going to build another board just in case I damaged the chip.

Could I have the command wrong to flash it?

This is the printout.

sudo dfu-util --v1.4.3-74-g286ced4.dfu -29-v
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Opening DFU USB device... ID 0483:df11
Run-time device DFU version 011a
Found DFU: [0483:df11] devnum=0, cfg=1, intf=0, alt=0, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
error get_status

Hopefully other can learn from my mistakes.

[dhylands]

You're using a really old dfu-util.

The command used to flash the firmwawre is:

Code: Select all

dfu-util -a 0 -d 0483:df11 -D firmware.dfu

Replace firmware.dfu with the name of your firmware file. Make sure that the filename does NOT start with a dash character.

If you have 0.7 or newer then you can add -s :leave and it will automatically reboot after flashing (i.e. run the firmware you just flashed).

[plakkies]

Thank you for the quick response. was not sure how to install the latest version but was able to get an executable and run it as you sugested. Still the same error though.

:~/Downloads$ sudo ./dfu-util08 -a 0 -d 0483:df11 -D pybv10-2015-05-29-v1.4.3-74-g286ced4.dfu
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: dfu-util08: error get_status

Thank you again for all the help. I hope I can contribute as much as you do eventually.

[plakkies]

btw just as reference I did this with a stock board and that works fine. I have not finished another board yet, Im slow with the soldering.

:~/Downloads$ sudo ./dfu-util08 -a 0 -d 0483:df11 -D pybv10-2015-05-29-v1.4.3-74-g286ced4.dfu
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash "
file contains 1 DFU images
parsing DFU image 1
image for alternate setting 0, (2 elements, total size = 270088)
parsing element 1, address = 0x08000000, size = 13580
Download [=========================] 100% 13580 bytes
Download done.
parsing element 2, address = 0x08020000, size = 256492
Download [=========================] 100% 256492 bytes
Download done.
done parsing DfuSe file

[plakkies]

As a follow-up my second board programs fine. Im busy going through both boards to find out what the difference is.

[dhylands]

One difference might be the load caps on the crystal.

I believe Damien had some issues getting the initial pyboards to come up reliably, and IIRC he changed the values of the load caps. I'm not sure if those changes were reflected in the pyboard schematics or not.