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.