How about the st-link utility from texane?
http://grafixmafia.net/updated-using-the-stm32f4-discovery-board-with-mac-osx-10-9-mavericks/
rogerClark:
Can we make some batch files or WSH files etc to have the command line options in them.?A lot of people will just run things and not bother reading the documentation (looks like this includes me a lot of the time )
One of my Maple Mini clones arrived today. I connected it to my Windows 8.1 x64 machine. No drivers were loaded. I disconnected the device and executed the attached batch file. It installed both drivers (libusb-win32 for the dfu device and usbser for the serial device). I then reconnected the device. Device Manager showed a "Maple Serial" device on COM5. Good. I used the two small buttons to put the device in DFU mode. Device Manager showed a "Maple DFU" device. Good. I tried to use dfu-util to backup whatever is flashed on the device but I couldn't get it to work.
C:\Users\Tim\Documents\Arduino\hardware\tools\win>dfu-util.exe -U backup.bin -a 1
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY
Opening USB Device 0x0000:0x0000...
Found Runtime: [0x1eaf:0x0003] devnum=1, cfg=0, intf=0, alt=1, name="DFU Program FLASH 0x08005000"
Setting Configuration 1...
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuUPLOAD-IDLE, status = 0
aborting previous incomplete transfer
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0400
bytes_per_hash=1024
Starting upload: [dfu_upload error -5
I receive the exact same error when using the original "dfu" Maple driver on Windows XP. Is it supposed to work? Maybe the Maple Mini clone bootloader is bad?
install_maple_drivers.cmd.txt (293 Bytes)
Ok, first "beta" of the nucleo-f103rb variant is here (see attachement)!
Not working: PB3 (D3) and PB5(D5) for different reasons (PB3 = connected to SWO, a jumper can be desoldered and PB5 is completely unclear for me)
D0 and D1 are also hardwired to the st-link serial (can also be removed)
the must be a little change in the boards.txt:
nucleo_STM32F103RB.build.variant=nucleo_f013rb
nucleo_f013rb.zip (33.1 KB)
Tim
Thanks for the batch file I will give it a try.
Re: DFU download
I've never tried using DFU to backup what's inside the device. Its possible that only a subset of the possible DFU functions are in the bootloader
If you really want to know the answer, you could look in the bootloader source, which is in leaflabs repo on GitHub.
Or you could post an issue to either that repo or the maple IDE repo, as Marti sometimes replies.
Your maple mini almost certainly has the same bootloader as everyone else is using.
If you have a USB to Serial adaptor you can download it via serial. I use STMs windows GUI serial bootloader tool, but the stm32flash.exe in the repo should be able to do it.
It sounds like the Nucleo requires more than just a modification to boards.txt. We may need to make a new Variant for this board, e.g. Like Ian Hawkin did for the Microduino
The main differences in the boards can controlled in the board.cpp file and board.h in the variants
I still don't fully understand what the problems are with the Nucleo, but it sounds a bit like a mapping issue of PIN numbers e.g To the position in the physical pin headers,
I will take a look at the spec for the board and see of that's the case
Dear Roger, good news!
stlink from GitHub - stlink-org/stlink: Open source STM32 MCU programming toolset works!
It's a little mess to compile everything (maybe give the compiled stuff online?), but after that, with a simple:
./st-flash write Blink.bin 0x8000000 I got my nucleo blinking.
@roger: please see my attachment! I've already build a new variant for the nucleo
stlink is available for Arch Linux pre compiled as a package. It is probably available for other distributions.
(I'm installing it now...)
STlink for OSX 10.9.5 pre compiled here you go!
line for the platform.txt: (osx/linux(?) only!)
tools.stlink_upload.upload.pattern="{path}/{cmd}" write "{build.path}/{build.project_name}.bin" "0x8000000"
success level stlink upload on osx: 100%
stlink.zip (116 KB)
Sorry. I was reading your initial post on my iPad and its not so easy to see whats in a zip 
I will add that variant to the repo, and I'll need to update the boards.txt file to use it (I'm not sure if you already did a modified boards.txt
Re: STLink for OSX.
Thank's I'll include the binary. (can you tell me where the source is, as we need either need to have a copy of the source in the repo or include a link to the source)
@Chillitronics
Re: Packages for stlink
OK. I have Mint Cinnamon x64 installed on a machine now, I'll see if I can find a repo for that distro e.g. apt-get install st-link or something
Edit
I think you have the nucleo folder the wrong name, you used nucleo_f013rb
But I'm pretty sure you mean
nucleo_f103rb
See
I will change the name
Edit 2
I've tried using the st-flash binaries you compiled but I get a segmentation fault on OSX 10.7
After a lot of messing around I managed to get st-link to compile and it is not crashing on my machine any more.
I've now included the files that work for me instead of the ones that crashed.
Can you see if they work on OSX 10.9 ?
Also, I've added texane / stlink as a sub folder under /tools/macosx/stlink so that osx users can compile if necessary
Edit again
Very interesting... On OSX (and I suspect Linux)
Using texane stlink, on my external STLink (clone) board, I"m able to upload via STLink without Boot0 needing to be HIGH or for the reset button to be pressed !!!
Of course this doesn't resolve the issue of not having a serial port for debugging and sending text to the board, at least using an external STlink adaptor.
However on the Nucleo boards, from what I understand there is a virtual serial port
Matthias, did you need to install additional software on your Mac to get the virtual com port to appear, or did the Mac just recognize the USB device and start working.
Also. It looks like Serial will not work "out of the box" for Nucleo, as these boards appear to use Hardware Serial 2 as the serial connection to the PC (via the STLink chip (STM32F103CBT6)
But the "Serial" isnt defined in any of the files that are now in the Variant.
A while back, BobC tidied up the files so that we didnt have complete copies of loads of the core files into each of the variants, but I think in this case its needed.
However I'm not entirely sure about the way in include paths now work.
I'll take a look on the PC as I have better dev tools on that platform
Matthias
Looking at how to get Serial working on Nucleo
I think we'll need to move HardwareSerial.cpp (and possibly HardwareSerial.h) into the variants folders.
i.e all existing boards can have the same copy thats in /cores/maple but for Nucleo HardwareSerial.cpp will need to be modified so that Serial uses HardwareSerial 2 - as this seems to be the USART that is connected physically to the stlink co-processor on the Nucleo boards
I'm not sure however where to map Serial1 and Serial 2 etc
Looking at the schematic for the Nucleo 103Rb, it looks like USART1 is still available via pins D8 ad D2, USART 3 is not available as the pins are not connected to the connectors (pin headers)
So I'd recommend that we map Serial to Hardware Serial2 so that Serial.print goes to the virtual com port and map Serial1 to Hardware Serial1
PS. I'm not sure why this wasnt initially working, but my STLink board, now, seems to be able to upload to my generic STM32F103C8 board with Boot0 LOW and without needing to manually reset.
Perhaps a recent update of the STLink firmware I did has allowed this, as I didnt seem to work last time i tried it !
One other thing.
It would be interesting if we could load the firmware that is in the Nucleo Stlink co-processor onto a separate STMF103 board, however I don't know how it would be possible to extract the firmware from your co-processor.
When I updated my STlink (clone) board, the updater seemed to imply that it was doing it by DFU as it mentioned switching the board into DFU mode, but my STLink clone board doesnt have any links or switches on it.
However I found if I unplugged and reconnected it, that it seemed to get updated, so perhaps it did briefly enter DFU mode.
If you co-processor can be put into DFU mode, it sounds like from what Tim was saying that it should be possible to read back the firmware, assuming that read has been implemented in the DFU firmware
PS. I did try to look at how the firmware was updated by the exe, but it looks like it contacts a site via https and downloads the binary which it then uploads, so it didnt seem to be possible to just open a local cached copy of the new firmware binary 
I'm at work again, so I cannot put out my electronic toys
your ST-Link Firmware: I read about, there was a faulty firmware before the actual one. Maybe you use that faulty one and now you've the updated one.
Reverse engineering firmware: Have a look at this: Taylor Killian: Retrieving ST-Link/V2 Firmware from Update Utility (If you have the time for this 
) - but beware putting the sniffed firmware online (copyrights...)
Serial/Nucleo:
I've to try out all Serial ports and analyse it with my saeleae logic analyzer and write down the pins. Same to SPI: Testing pins and clock speeds.
I'm not up to date: Is there a functionally hardware solution for I2C - or are there some issues?
BTW: I'm a little bit lost with all the libmaple folder and wirish files in the Arduino_STM32 project. Are they all neccessary or are some redundant?
PS: Why you don't grab a cheap nucleo board for ~10USD? If you break it into pieces you get one ST-LinkV2.1 and blank STM32F103RB board, so 5USD for each board
Matthias
I2C is working, but uses a software "bit banged" method, so max speed is 250 kHz
I will see if I can get a cheap Nucleo board, but often shipping cost more than the cost of the board
rogerClark:
I've never tried using DFU to backup what's inside the device. Its possible that only a subset of the possible DFU functions are in the bootloaderIf you really want to know the answer, you could look in the bootloader source, which is in leaflabs repo on GitHub.
I dumped the bootloader of my Maple Mini clone and it was 100% identical to maple_mini_boot.bin from LeafLabs. I grabbed a copy of the bootloader source, made some changes for Maple Mini and compiled it. I flashed the new bootloader and now DFU read from device to file works
Quick question... Does using stlink require additional hardware?
@chillitronics
Yes. STLink is via a special USB device, originally developed by STM, but there are now very cheap clones available
e.g.
The one i have is
This is an even cheaper one,
but I've no idea of the cheaper one works
However these STlink boards only give upload an in circuit debugging, e.g. single stepping etc (and only via GDB at the moment)
It looks like the firmware that is loaded into the STLink section of the Nucleo boards has additional functions, like USB Serial, but these standalone modules don't have.
Looking at my F4Discovery board, it had STLink, but is only enumerating as STLink, ie so it looks like they don't include the USB serial on anything other than the Nucleo boards, - which is a shame
If I'd realised this, I would have probably bought a F4 Nucleo rather than Discovery board as they are similar prices
I looked at prices of the F103 Nucleo boards, but the cheapest I can buy them, including postage is over $30 - which isn't good value.
I have plenty of other STM32 boards, so I don't think its worth buying a Nucleo.
At the moment the Maple Mini at $5 are the best value.
Re: Loading STLink firmware from Nucleo onto another device.
Thanks for the link. I recall reading that article some time ago, but didn't really understand it at the time.
Basically its not practical for both technical or legal reasons to get a copy of the STLink firmware (though it looks like the clone STLink makers must have got a copy in order for their boards to work)
Tim,
Thanks for the updated bootloader
I will try it later.
One thing I have noticed, which appears to be a bootloader issue, is that my Maple board works OK, but my Maple Mini does not appear as USB Serial any more
I think perhaps the booloader that the manufacturer installs in the Maple mini may be an old version - but I'm not sure.
I have dumped the firmware from my Maple and I need to compare it with a dump from my Maple mini to see if its different, and if so how its different.
But is its more than just changes to time delays for USB enumeration, its not going to be practical to compare two sets of code dis-assemblies
rogerClark:
One thing I have noticed, which appears to be a bootloader issue, is that my Maple board works OK, but my Maple Mini does not appear as USB Serial any moreI think perhaps the booloader that the manufacturer installs in the Maple mini may be an old version - but I'm not sure.
Bootloader? USB serial? I think you are confused.
Maple Rev 3 takes a completely different tack, more along the lines of Arduino. In Rev 3, the device resets into bootloader mode, which stays alive for a few moments to receive commands, and then jumps to user code. The bootloader is implemented as a DFU device – just a DFU device, no serial port. This requires one driver for Windows (drivers/mapleDrv/dfu in the Windows IDE directory).
As part of the libmaple library, user code is automatically supplied with serial support via some behind the scenes work (setupUSB() is called from init()). This user mode code only implements a CDC ACM class USB device, giving you functions like SerialUSB.read(). Separating these two modes fixed the driver issues and works well across platforms, requiring only two drivers (serial and DFU) on Windows.
If you haven't flashed a (working) program or flashed one compiled for the wrong hardware (Maple and Maple Mini use a different GPIO for USB) then you won't see the USB serial device appear.
Many thanks @Roger. I may look into stocking those.
Roger: There are two versions of the maple mini clone from china: The one from Baite and the one from Beestore (both can you find on aliexpress).
I own the one from Beestore and I successfully (re)flashed it with the original maple-mini bootloader from the leaflabs homepage. http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.bin
Matthias
I have re-flashed one of my Maple Minis (I have 2), with the bootloader from Leaflabs site (I think), but it still has that issue.
I will try downloading and from the link you sent and see if it is an improvement
@Chillitronix
Its definitely worth taking a look at. In the longer term full debugging may be possibly
But probably using Eclipse as the IDE.
I know there is already an Arduino plugin for Eclipse (or some other way of using Eclipse), and it looks like perhaps Teensy has been ported to this.
However its another big chunk of work that I don't have time to investigate