STM32F768DISC enter DFU mode

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.
Post Reply
klingler
Posts: 8
Joined: Tue Oct 08, 2019 2:41 pm
Location: Switzerland

STM32F768DISC enter DFU mode

Post by klingler » Mon Oct 14, 2019 7:25 pm

Good evening (o;

Got my two STM32F769 DISCO boards today and tried to flash it with st-link with BOOTM and QSPI disabled as it otherwise returned an error....though I don't see any output in the console on /dev/ttyACM0....

The default method is to flash it via DFU mode....and this needs to tie BOOT0 pin to VDD....
but the board has no option for it...nor the user manual states anything about it....

So how can I put the board into DFU mode?


thanks in advance
richard

User avatar
jimmo
Posts: 1769
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32F768DISC enter DFU mode

Post by jimmo » Mon Oct 14, 2019 9:33 pm

See my reply on your other thread. Use stlink to get mboot onto the board, then you can activate mboot dfu at reset with the USR button.

klingler
Posts: 8
Joined: Tue Oct 08, 2019 2:41 pm
Location: Switzerland

Re: STM32F768DISC enter DFU mode

Post by klingler » Tue Oct 15, 2019 8:22 am

Sorry...thought I start a new thread as it is more specific on a problem I have (o;

Flashing mboot went well:

Code: Select all

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build-STM32F769DISC/firmware.dfu to the board via ST-LINK
st-flash 1.5.1-45-g393e942
2019-10-15T10:08:12 INFO common.c: Loading device parameters....
2019-10-15T10:08:12 INFO common.c: Device connected is: F76xxx device, id 0x10016451
2019-10-15T10:08:12 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2019-10-15T10:08:12 INFO common.c: Attempting to write 12304 (0x3010) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
2019-10-15T10:08:13 INFO common.c: Finished erasing 1 pages of 32768 (0x8000) bytes
2019-10-15T10:08:13 INFO common.c: Starting Flash write for F2/F4/L4
2019-10-15T10:08:13 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 12304
2019-10-15T10:08:13 INFO common.c: Starting verification of write complete
2019-10-15T10:08:13 INFO common.c: Flash written and verified! jolly good!
But can't flash afterwards in DFU mode the micropython image, not with pydfu nor with dfu-util:

Code: Select all

Use make V=1 or set BUILD_VERBOSE in your environment to increase build verbosity.
Writing build-STM32F769DISC/firmware.dfu to the board
Traceback (most recent call last):
  File "../../tools/pydfu.py", line 586, in <module>
    main()
  File "../../tools/pydfu.py", line 566, in main
    init()
  File "../../tools/pydfu.py", line 97, in init
    raise ValueError('No DFU device found')
ValueError: No DFU device found
make: *** [Makefile:505: deploy] Error 1
I've pressed USR button until all 3 LEDs are lit and then let it go...leaving LED1 blinking red...
And "lsusb" still shows the old manufacture/device id...

User avatar
jimmo
Posts: 1769
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32F768DISC enter DFU mode

Post by jimmo » Tue Oct 15, 2019 8:46 am

Are you connected to the other (non-stlink) USB port?

klingler
Posts: 8
Joined: Tue Oct 08, 2019 2:41 pm
Location: Switzerland

Re: STM32F768DISC enter DFU mode

Post by klingler » Tue Oct 15, 2019 8:48 am

Stupid me (o;

I have to use the other USB port for flashing via mboot (o;

Though wondering why I see this in the console when I reset the board:

Code: Select all

>>> MicroPython v1.11-445-g8f7f67123 on 2019-10-15; F769DISC with STM32F769
Type "help()" for more information.
>>> AT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'AT' isn't defined
>>> AT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'AT' isn't defined
>>> AT
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'AT' isn't defined
>>> ~x~~x~
Traceback (most recent call last):
  File "<stdin>", line 1
SyntaxError: invalid syntax

User avatar
Roberthh
Posts: 2058
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: STM32F768DISC enter DFU mode

Post by Roberthh » Tue Oct 15, 2019 10:50 am

That could be caused by the modemmanager of your PC. You should uninstall it.

klingler
Posts: 8
Joined: Tue Oct 08, 2019 2:41 pm
Location: Switzerland

Re: STM32F768DISC enter DFU mode

Post by klingler » Tue Oct 15, 2019 11:48 am

This is really odd...as soon I press the reset button, this happens....
Haven't had this with other boards, also running micropython....


Anyway...is there a wiki describing which STM32F769 peripherals are working in micropython?

Like ethernet, CAN, DSI LCD and so on?


thanks in advance
richard

User avatar
jimmo
Posts: 1769
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia
Contact:

Re: STM32F768DISC enter DFU mode

Post by jimmo » Tue Oct 15, 2019 12:12 pm

klingler wrote:
Tue Oct 15, 2019 11:48 am
This is really odd...as soon I press the reset button, this happens....
Haven't had this with other boards, also running micropython....
Yup, this is almost certainly modemmanager. The AT is the giveaway.

Were the other boards using FTDI (i.e. ttyUSB, e.g. esp8266 or esp32) or CDC ACM (i.e. ttyACM, stm32 e.g. pyboard). I'd imagine this might only happen on ACM?
klingler wrote:
Tue Oct 15, 2019 11:48 am
Like ethernet, CAN, DSI LCD and so on?
I'm fairly sure ethernet is supported, CAN definitely (and recently fdcan). LCD no. SDRAM is supported but possibly not enabled by default from memory. There's a recent thread discussing using the LCD on a similar disco board, but it needs work.

Edit: here's the LCD on F7 disco thread: viewtopic.php?f=12&t=6312

klingler
Posts: 8
Joined: Tue Oct 08, 2019 2:41 pm
Location: Switzerland

Re: STM32F768DISC enter DFU mode

Post by klingler » Tue Oct 15, 2019 12:53 pm

Yepp..on ACM devices only...

This helped (on Debian 10.1):

Code: Select all

sudo systemctl disable ModemManager.service
sudo systemctl stop ModemManager.service

cheers
richard

Post Reply