https://github.com/rogerclarkmelbourne/ … from-Linux
They don’t have the header and I Cant; see anything on the silkscreen that matches, even better, is there a guide like above but for the BMM?
My MM does the normal flash (fast – slow) routine but no longer shows as DFU nor Serial on my Mac, not sure what I did, I might have pulled the plug mid flash or something, so need to get it back.
https://developer.mbed.org/media/upload … nout01.png
*sigh*
Error: Debug adapter does not support any transports? Check config file order.
Error: unable to select a session transport. Can't continue.
Unfortunately, whilst I have the flashes on reset, holding but=32 doesn’t lock in to dry mode, however, using st-utils from texane which connects to the board, but, arm-none-eabi-gdb requires an elf rather than bin so unable to upload the boot loader that way.
It’s annoying that I have to fire st-link at least when the blue flashes happen on a reset else it won’t connect so might need hands all over the place and obviously if a fail the burn and lose the flashes it’s pretty much dead.


I have done various things that should have fried the STM32, but they all survived so far.
I ran one board from 5V instead of 3.3, for several days, and it didn’t seem to do it any long term harm.

1) ST-* for osx is included in the git archive so no need for home-brew.
2) Don’t get side tracked using dfu-util manually when it’ll just work like magic from Arduino IDE anyway once the bootloader is sorted.
I managed to get it working using the following (should anyone bother with OpenOCD/st-util/gdb or variants and have no luck)
st-flash erase
st-flash –reset <your_bootloader_of_choice> 0x08000000
I assume the address for the boot loader is correct as I can get a simple flash sketch running, now to find why my sketch crashes.. goto 10
Cheers guys.
*EDIT: found my bug and what was the probable cause of it all, having a big enough array that the stack will get trashed from the off.
Things are easy when you know how to do them