STM32 F4 Discovery ...

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: STM32 F4 Discovery ...

Post by SpotlightKid » Mon May 09, 2016 9:14 pm

- Does the board show up as a USB device at all (e.g. with lsusb)?
- Did you try the procedure to re-create the flash drive (hold user and reset button, let go of reset button, then release user button when two leds are lit together)?
- Did you try flashing with openocd (make target deploy-openocd)?

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: STM32 F4 Discovery ...

Post by dhylands » Mon May 09, 2016 9:17 pm

How did you flash the image to the board?
If you use the deploy-stlink command then you need to ensure that also pass BOARD=STM32F4DISC

Code: Select all

make BOARD=STM32F4DISC deploy-stlink
or it will flash a pyboard .hex instead of the discovery .hex.

I would try one of the known working download images from here:
http://micropython.org/download/
(scroll to the very bottom of the page).

Those downloads are for DFU mode. If needed I can build you a .hex file for flashing via stlink.

There are details on the wiki:
https://github.com/micropython/micropyt ... ux-via-dfu
about programming using DFU mode.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: STM32 F4 Discovery ...

Post by dhylands » Mon May 09, 2016 9:46 pm

I put a matching set of files here:
https://www.dropbox.com/sh/vop75bq6sd95 ... CCRha?dl=0

Also make sure that you don't have the BOOT0 signal connected to VDD or that will cause it to come up in DFU mode instead of regular runnign mode.

Rando
Posts: 20
Joined: Thu Apr 28, 2016 1:00 pm

Re: STM32 F4 Discovery ...

Post by Rando » Mon May 09, 2016 10:20 pm

Quite a few questions to answer, here goes.

1. I programmed/am programming via st-link

2. I tried a hex file I built myself, and also took a dfu image from the dailies, and stripped it back to a hex file. Both images had same behaviour.

3. I'm having a little difficulty with the lsusb command running correctly. I am on Ubuntu 15.04, with all my Windows contrivances running as an Oracle Virtual-Box Windows 7 virtual machine. My experience has been good with this set-up.
Trying to be careful that the VM doesn't grab all my attached devices.

Code: Select all

rasyoung@vic2016:~$ lsusb -t
[size=85]
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
    |__ Port 1: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 1: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M
    |__ Port 3: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/3p, 12M
    |__ Port 3: Dev 33, If 0, Class=Vendor Specific Class, Driver=usbfs, 12M
    |__ Port 3: Dev 33, If 1, Class=Mass Storage, Driver=usbfs, 12M
    |__ Port 3: Dev 33, If 2, Class=Communications, Driver=usbfs, 12M
    |__ Port 3: Dev 33, If 3, Class=CDC Data, Driver=usbfs, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        |__ Port 4: Dev 21, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 1: Dev 24, If 0, Class=Vendor Specific Class, Driver=rt73usb, 480M[/size]
4. Thanks for posting the files, I will try these as well!

5. Need to try the key press magic once I have your file flashed correctly.

Thanks!
Last edited by Rando on Tue May 10, 2016 12:14 am, edited 3 times in total.

Rando
Posts: 20
Joined: Thu Apr 28, 2016 1:00 pm

Re: STM32 F4 Discovery ...

Post by Rando » Mon May 09, 2016 10:33 pm

I quickly flashed the 'F407 with the firmware.hex file you graciously posted for me. Did the RESET/USER dance, and was rewarded with quite a light show from the board LED's. When I do it correctly I think I get a momentary red flash.

However I am still not enumerating as a serial port yet. I will try this set-up on another machine tomorrow and post progress...

Also I need to order a Pyboard from England this week, so I have a control to use to get more familiar with normal operation.

R.

SpotlightKid
Posts: 463
Joined: Wed Apr 08, 2015 5:19 am

Re: STM32 F4 Discovery ...

Post by SpotlightKid » Mon May 09, 2016 10:59 pm

Seems to me your board is working fine and the issue is with your USB connection. Maybe try a Linux Live distro on a USB drive instead of running in a VM.

Or, if you have a serial-USB adapter, enable the console on UART6 in mpconfigboard.h, recompile, flash firmware and then connect the serial-usb adapter to the UART6 pins and connect your terminal program to the appropriate device. I have successfully done this with a STM32F4DISCOVERY board. But then again, a serial-USB adapter might not work correctly on your setup either.

Rando
Posts: 20
Joined: Thu Apr 28, 2016 1:00 pm

Re: STM32 F4 Discovery ...

Post by Rando » Mon May 09, 2016 11:14 pm

I'm only running the VM to get access to the STM32 Win32 toolchain, I have the VM instance shut down now. What should lsusb return, and I'm wondering what the normal serial device is assigned as ... /dev/ttyUSBx or /dev/ttyACMx or something different? And of course, I need to do something about a udev rule perhaps? I do have all the expected 99-stlink.rules installed
Last edited by Rando on Mon May 09, 2016 11:20 pm, edited 1 time in total.

User avatar
dhylands
Posts: 3821
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: STM32 F4 Discovery ...

Post by dhylands » Mon May 09, 2016 11:18 pm

I wasn't familiar with the lsub -t output. On my system, if I use lsudb with no arguments I see:

Code: Select all

Bus 002 Device 003: ID 046d:0821 Logitech, Inc. HD Webcam C910
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 002: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 004: ID 0644:0200 TEAC Corp. All-In-One Multi-Card Reader CA200/B/S
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 013: ID 0483:3748 STMicroelectronics ST-LINK/V2
Bus 005 Device 016: ID f055:9800  
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
Bus 003 Device 002: ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 5, Device 16 (with the VID:PID of f055:9800) is the pyboard. lsusb -t output for that device looks like:

Code: Select all

/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 16, If 0, Class=Mass Storage, Driver=usb-storage, 12M
    |__ Port 1: Dev 16, If 1, Class=Communications, Driver=cdc_acm, 12M
    |__ Port 1: Dev 16, If 2, Class=CDC Data, Driver=cdc_acm, 12M
which appears to be insufficient to identify it as a pyboard.
When in DFU mode, I see:

Code: Select all

Bus 005 Device 017: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
for regular lsusb output and

Code: Select all

/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 17, If 0, Class=Application Specific Interface, Driver=, 12M
for the -t output.

The RED LED indicates that storage was written (which can happen when the filesystem is initialized for the first time) and if the USB Mass Storage gets written by the host.

The GREEN LED should flash briefly to inidcate that its entering and leaving bootup.

I wouldn't expect the blue or orange LED to light up at all. The defauilt program burned onto the '407 discovery does flash all 4 of the LEDS (between the RESET and USR buttons).

when I flash using deploy-stlink I see the following (perhaps useful for comparison):

Code: Select all

545 >make BOARD=STM32F4DISC deploy-stlink
Executing GNUmakefile
BOARD = STM32F4DISC
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build-STM32F4DISC/firmware0.bin to the board via ST-LINK
2016-05-09T15:57:53 INFO src/stlink-usb.c: -- exit_dfu_mode
2016-05-09T15:57:53 INFO src/stlink-common.c: Loading device parameters....
2016-05-09T15:57:53 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2016-05-09T15:57:53 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2016-05-09T15:57:53 INFO src/stlink-common.c: Attempting to write 10380 (0x288c) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000
Flash page at addr: 0x08000000 erased
2016-05-09T15:57:53 INFO src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2016-05-09T15:57:53 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-09T15:57:53 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 10380
2016-05-09T15:57:53 INFO src/stlink-common.c: Starting verification of write complete
2016-05-09T15:57:54 INFO src/stlink-common.c: Flash written and verified! jolly good!
Writing build-STM32F4DISC/firmware1.bin to the board via ST-LINK
2016-05-09T15:57:54 INFO src/stlink-common.c: Loading device parameters....
2016-05-09T15:57:54 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10016413
2016-05-09T15:57:54 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2016-05-09T15:57:54 INFO src/stlink-common.c: Attempting to write 273388 (0x42bec) bytes to stm32 address: 134348800 (0x8020000)
EraseFlash - Sector:0x5 Size:0x20000
Flash page at addr: 0x08020000 erasedEraseFlash - Sector:0x6 Size:0x20000
Flash page at addr: 0x08040000 erasedEraseFlash - Sector:0x7 Size:0x20000
Flash page at addr: 0x08060000 erased
2016-05-09T15:58:00 INFO src/stlink-common.c: Finished erasing 3 pages of 131072 (0x20000) bytes
2016-05-09T15:58:00 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-09T15:58:00 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 11244
2016-05-09T15:58:07 INFO src/stlink-common.c: Starting verification of write complete
2016-05-09T15:58:12 INFO src/stlink-common.c: Flash written and verified! jolly good!
I noticed that deploy-stlink actually does 2 calls to st-flash (one to flash firmware0.bin and one to flash firmware1.bin)

Were you by chance trying to do:

Code: Select all

st-flash write firmware.hex 0x08000000
If so, then that won't work. You need to convert the .hex to .bin first:

Code: Select all

arm-none-eabi-objcopy -I ihex -O binary firmware.hex firmware.bin
and then use st-flash to flash the firmware.bin file. Otherwise st-flash will consider firmware.hex to be a bin file, when in fact it's an ASCII representation of a bin file, and it will fill your flash with ASCII, which doesn't execute well.

Rando
Posts: 20
Joined: Thu Apr 28, 2016 1:00 pm

Re: STM32 F4 Discovery ...

Post by Rando » Mon May 09, 2016 11:27 pm

Gee, I'm sorry.

Thanks so much for the detailed posting. In point of fact I was using ST-link on Windows 7, via STM32 GUI windows facility. It runs great on the VirtualBox VM, as do all the normal windows programs I run. I can understand that you assumed I was using the command line st-link tool from a Ubuntu terminal session, from my ambivalent posting. I have that VM shut down now.

I am assuming that stmhal source code for the stm32-f407 Discovery uses the expected pyboard vid/pid pair? Or perhaps something different?

Also I plead guilty to just flashing the firmware.hex file with the Windows St-link program, as I naively assumed it could handle the hex file. I'm surprised that the led's responded correctly to the board RESET/USER flash disk set-up. If I had just written gibberish would that be so? For example, as I am using a Discovery board, and have the smarts of the debug processor between me and the application host CPU, I thought it would be OK just to flash the hex.

Rando
Posts: 20
Joined: Thu Apr 28, 2016 1:00 pm

Re: STM32 F4 Discovery ...

Post by Rando » Mon May 09, 2016 11:57 pm

I did take a moment, and dropped into my MicroPython stmhal directory, to just play ball with the normal way of doing things... they don't call me "wrong-way Randy" for nothing!

(I did have confidence in my Linux ARM tool-chain, and st-link set-up as I had used it successfully before on another project.)

"make BOARD=STM32F4DISC deploy-stlink" Notice the evil spaces in my directory path. Hope that isn't an issue.

Code: Select all

rasyoung@vic2016:~/Desktop/MicroPython ESP8266/Official micropython master GITHUB 28 APR 2106/micropython-master/stmhal$ make BOARD=STM32F4DISC deploy-stlink
Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build-STM32F4DISC/firmware0.bin to the board via ST-LINK
2016-05-09T19:55:12 INFO src/stlink-common.c: Loading device parameters....
2016-05-09T19:55:12 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10076413
2016-05-09T19:55:12 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2016-05-09T19:55:12 INFO src/stlink-common.c: Attempting to write 10380 (0x288c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2016-05-09T19:55:12 INFO src/stlink-common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2016-05-09T19:55:12 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-09T19:55:12 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 10380
2016-05-09T19:55:12 INFO src/stlink-common.c: Starting verification of write complete
2016-05-09T19:55:12 INFO src/stlink-common.c: Flash written and verified! jolly good!
Writing build-STM32F4DISC/firmware1.bin to the board via ST-LINK
2016-05-09T19:55:12 INFO src/stlink-common.c: Loading device parameters....
2016-05-09T19:55:12 INFO src/stlink-common.c: Device connected is: F4 device, id 0x10076413
2016-05-09T19:55:12 INFO src/stlink-common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2016-05-09T19:55:13 INFO src/stlink-common.c: Attempting to write 273416 (0x42c08) bytes to stm32 address: 134348800 (0x8020000)
Flash page at addr: 0x08060000 erasedEraseFlash - Sector:0x7 Size:0x20000 
2016-05-09T19:55:18 INFO src/stlink-common.c: Finished erasing 3 pages of 131072 (0x20000) bytes
2016-05-09T19:55:18 INFO src/stlink-common.c: Starting Flash write for F2/F4/L4
2016-05-09T19:55:18 INFO src/stlink-common.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 32768
size: 11272
2016-05-09T19:55:22 INFO src/stlink-common.c: Starting verification of write complete
2016-05-09T19:55:23 INFO src/stlink-common.c: Flash written and verified! jolly good!
Which I assumed is all good, based on the console output.

However my lsusb is

Code: Select all

rasyoung@vic2016:~$ lsusb
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 021: ID 13fd:1040 Initio Corporation 
Bus 002 Device 003: ID 0bda:0181 Realtek Semiconductor Corp. 
Bus 002 Device 002: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 024: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 0461:4d0f Primax Electronics, Ltd HP Optical Mouse
Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 033: ID 0483:374b STMicroelectronics 
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
I grepped out "pid" and it returned ...

Code: Select all

grep -r "pid" *.c

usb.c:    pyb.usb_mode('VCP+HID', vid=0xf055, pid=0x9800) # specify VID and PID
I don't think I see the STM32F407-Discovery with the Pyboard VID/PID pair on this listing... now it feels like I'm doing something silly. Attack this fresh at the 'morrow.

R.

Post Reply