The good news is that the Arduino_STM core and example repository I downloaded on this posting date works. I was able to successfully verify and download the blink sketch to my STM32F103 Nucleo.
The LED2 indicator does not blink, but the download completes with
...
5/5 pages written2015-05-22T18:47:49 INFO src/stlink-common.c: Flash written and verified! jolly good!
But we originally started as a thread on the Arduino.cc forum
http://forum.arduino.cc/index.php?topic=265904.0
However the thread ended up being too big to handle, so I setup this forum.
Normally Matthias would have probably get back to you, but I know he is busy with family things at the moment.
However if you PM @madias he may be able to find time to help
This is a big holiday weekend here in the states. So a lot of people are off enjoying life.
I have been fiddling with the setup, Still have no luck getting the LED to blink. I re-read some of the STM stuff, but I quickly get lost in areas that I do not have time for.
Turned on the verbose as per the blog posting on your web site under the F103 generic blink example. According to documentation on the Nucleo The LED is connected to D13 which is PA5 which may be on pin 21 or 34 according. I tried putting all these numbers into a copy of the blink sketch, I do not get errors on the compile/verify and it seems to upload. Seems what ever text I put in this field does not generate an error.
The upload completes and the stlink io led lashes red green and stays green.
I did download the fimware from the STM site. I was going to see if I could reload the demo. can not seem to get MBED to upload to this board. (Forgot the board was MBED compatible) Attempts to connect just give me build system down errors.
The firmare from the ST site is *.hex and the Arduino/hardware/Arduino_STM32/tools/macosx/stlink_upload seems to call with a bin file. Was looking for parameters to stlink_upload which lead me back here.
I have no Idea why I have so much trouble with ARM. I have been using AVR for over 15 years and never had any trouble getting things to work.
At this point I would just like to see if I can get stlink to flash a generic hex file such as the demo app.
-julie
-rick
This computer is still running 10.7 due to my need to access MIDI through quicklook. My other ones are running Yosemite.
As far as I can tell the Arduino_STM slink is flashing the 103. I was wanting to reload the demo code which I would either have to compile or figure out how to use stmlink to flash the .hex file. I forgot and had the 104 Nucleo connected and the arduino IDE erased the flash on it also, So I am pretty confident the Arduino_STM is installed an running. I just do not have a sketch that lets the 103 do anything useful like blink a LED or send back through the USB serial port.
Just for fun I attempted to drag the .hex file onto the Nucleo drive. This created a fail.txt file. Draging the bin from Arduino makes the stlink light blink then go red. The mac also complains I did not eject the disc correctly (given that MD util is probably attempting to write spotlight index files on it.)
If I get really frustrated I can drag out an XP laptop which has all the ST stuff loaded on it, but I think the payware demo compilers are outdated.
Does it look like the STLink is uploading from the IDE
BTW. Enable verbose in your prefs.
the other test you can do is go into /tools/maxosx/stlink and run st-flash from a terminal
I think it will tell you if stlink can connect to the board.
Edit
try ./st-util from the terminal.
I just tested it and one of my STLink devices was recognized but the other (a Nucleo F3) was not recognized.
I plugged my F3 nucleo into a PC (Win 7) and it did connect using STM’s own STLink tool and showed version
V2.J20.M4 STM32 Debug+Mass storage
and have the option to update to
V2.J23.M7
which I thought may fix the problem, but didn’t seem to 
as far as I can tell, STM don’t support STLink on OSX, i.e I can’t see any downloads on their site for OSX STLink
All the articles I can find that describe how to use STlink on OSX are using Texane-stlink, which is what we use.
I just tried recompiling the latest Texane – STLink and it didn’t help
there is also a folder under the st-link src folder for an OSX driver, but I don’t think my default you’d have those files (I it depends if you downloaded the zip of the repo or did git clone) called stlinkv1_macosx_driver
See https://github.com/texane/stlink/tree/m … osx_driver
But I just tried following the instructions but it won’t compile on my Mac as it looks like it only works on 10.6 and 10.7 and I’m running a newer version of OSX
I did think that Matthias (@madias) was using a mac, but perhaps he’s running a virtual PC eg using parallels.
Just to recap. The STlink does work on OSX for some boards, however it looks like the firmware in the Nucleo which I have (and probably the firmware you have) is not compatible with OSX
You could try posting to the Texane stlink issues on Github (Actually I’ll do that)
Now things start to get a bit more interesting / tricky.
I’m not sure how techie you are, but I suspect the best option is to reflash the Stlink co processor on the Nucleo.
However I can’t see an easy way for you do do that, unless you want to connect another one of your STM boards eg possibly one of your F4 boards to the F3 to act as a STLink
But its probably not worth going into detail about precisely how do do that unless you want to give it a shot. 
Sketch uses 5,772 bytes (5%) of program storage space. Maximum is 108,000 bytes.
Global variables use 2,104 bytes of dynamic memory.
/Users/Arethusa/Documents/Arduino/hardware/Arduino_STM32/tools/macosx/stlink_upload cu.usbmodemfd123 1 1EAF:0003 /var/folders/19/rz7506jh8xn7x1006s6s574h0000gn/T/build220135859000651271.tmp/Blinkstmxx.cpp.bin
2015-05-23T20:04:56 INFO src/stlink-common.c: Loading device parameters....
2015-05-23T20:04:56 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2015-05-23T20:04:56 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
2015-05-23T20:04:56 INFO src/stlink-common.c: Attempting to write 5772 (0x168c) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08000000 erased
Flash page at addr: 0x08000400 erased
Flash page at addr: 0x08000800 erased
Flash page at addr: 0x08000c00 erased2015-05-23T20:04:56 INFO src/stlink-common.c: Finished erasing 6 pages of 1024 (0x400) bytes
2015-05-23T20:04:56 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id
2015-05-23T20:04:56 INFO src/stlink-common.c: Successfully loaded flash loader in sram
Flash page at addr: 0x08001000 erased
Flash page at addr: 0x08001400 erased
0/5 pages written
1/5 pages written
2/5 pages written
3/5 pages written2015-05-23T20:04:56 INFO src/stlink-common.c: Starting verification of write complete
4/5 pages written
5/5 pages written2015-05-23T20:04:56 INFO src/stlink-common.c: Flash written and verified! jolly good!
In the code the pin numbers are converted to the real port and pin numbers using this enum
enum {
PA3, PA2, PA10, PB3, PB5, PB4, PB10, PA8,
PA9, PC7, PB6, PA7, PA6, PA5, PB9,PB8,
PA0, PA1, PA4, PB0, PC1, PC0,
PC10,PC12,PB7,PC13,PC14,PC15,PC2,PC3,PC11,PD2,PC9,PC8,PC6,PC5,PA12,PA11,PB12,PB11,
PB2,PB1,PB15,PB14,PB13
};
The nucleo port is almost finished by my side. I don’t know if the files in repo are up to date, I’ve done a lot of changes the last weeks.
There was an issue with usb-serial (I did a private conversation with Roger) so that the serial debug is always “Serial2”, the only solution is a to change core code so there is no possibility only changes this in the “variants” folder.
I remapped some serial pins for several reasons it’s everything in my written manual. I had to do some minor soldering things to get the nucleo board running with STM32-arduino. A major thing is, that as default the quartz was not connected so no code would run (see again my manual)
Board LED is PA5 / D13 as in my pinout sheet: viewtopic.php?f=29&t=93
BTW. I tried my Nucleo F3 board this afternoon, to see if it would explain any of @sheepdoll’s issues and it looks like it has the same problem
Re: Changes to core
I will try to look at them tomorrow evening i.e 1 day from now, as I’m in meetings all day tomorrow (monday)
You can ever, without installing anything (driver, IDE…), uploading the code (*.BIN) via drag&drop.
Roger: I can remember some month ago we both were “playing” with the texane compiling and have found out, that the pre- compiled version on OSX 10.7 works on higher versions (I’m on OSX.10.9), but maybe the pre-compiled doesn’t work on OSX 10.6?
I had only previously tested with my stlink clone, and that still seems to work ok on OSX
And the F407 board is also recognised by texane stlink, but one other users has another F4 board they could not upload to.
So I will change the widows stlink upload.bat to use STMs exe as it seems to work for all.
I will need to double check what version of OSX is on my mac, I thought it was 10.9, and I can compile texane stlink , but it only works for my stlink clone
The “driver” code doesn’t compile because the make file appears to check for OS version, so unless someone has forked and fixed this, I don’t think we can do much.
I think I’d be tempted just to replace the stlink firmware with BMP instead. However there is no way back to the version of the firmware that is on the Nucleo boards, as the binary on the Russian site is a different one that doesn’t have mass storage etc ( well I don’t think it has mass storage).. Actually I don’t even know if texane stlink works with that firmware
The problem seems or be that basically STM don’t support stlink on OSX, because if they did, we could use their uploader like we do on the PC
On windows the STM original driver should be used.
On OSX there is no known problem with texane? I can remember, that you tried it on OSX 10.7 because my compiled version (OSX 10.9) didn’t worked for you, but the 10.7 compiled version worked on OSX 10.9.
I can’t believe that on OSX 10.7-9 there should be a problem with nucleo boards and upload (even for sheepdoll the upload was successful), because the ST-Link2.1 hardware is exactly the same on each board or texane didn’t recognize the some F4 boards?
Flashing the nucleo board with BMP is really a bad idea, because there is no way back (as you said) and the board won’t be able to use easily with other IDE’s (like MBED)
The oscillator hardware strap was the issue. Now the LED is blinking using PA5 as the pin name.
I also moved the straps on the serial port. Is there a sketch already written to test this?
Again many thanks, to those who have put countless hours into making the system work. It really does make a difference.
Does STlink not allow reading the contents of the STM32 flash to a binary or HEX file?
Ex: On Windows, the following creates files of the AVR contents (non-protected)
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U flash:r:%temp%\backup_flash.hex:i
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U eeprom:w:\Users\owner\AppData\Local\Temp\backup_eeprom.hex
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U hfuse:w:\Users\owner\AppData\Local\Temp\backup_hfuse.hex
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U lfuse:w:\Users\owner\AppData\Local\Temp\backup_lfuse.hex
avrdude -c arduino -P com9 -p ATMEGA328P -b 19200 -U efuse:w:\Users\owner\AppData\Local\Temp\backup_efuse.hex
ST lock the binary, so its not possible to back it up.
There is a blog entry somewhere, where someone reverse engineered the update process for the STLink and managed to capture an unencrypted binary from PC memory, but he was only able to do this because of a design mistake from STM where it unencrypted the download int memory before re-encrypting it for upload to the board.
But that’s the only way of getting hold of the binary that comes with the hardware , which is not a good state of affairs
But you’d need to do the hacking while you have a working board, during its update process, i.e you cant decided later to get old of the binary in that way, without doing even more hacking of the updater into thinking it was connected to a version of STLink that needed to be updated.
Any work on detailing the use of serial on the Nucleo? I cut the traces on the STM link with the strap. Unclear as to which Serial port to use and if wires needed to be added between the pins on the Morpho header and the STM link module.
In the mega thread on Arduino.cc there is a lot of discussion on serial vs USBSerial, then what to do with Serial1, Serial2 and Serial3?
We are waiting that Roger will implement a solution to choose the (USB) serial port as variant defined “Serial”, this is sadly a big deal, because it needs to change every “variant” folder (these are contaminated sites from the leaflabs side, as they use USBserial to a defined pin and you cannot change the order without changing the “core” code).
Meanwhile if you followed my little soldering manual you can use D22/PC10=TX and D30/PC11=RX as USB-Serial debugger. But you have to choose “Serial2” for them.
In my pinsheet viewtopic.php?f=29&t=93 there are the “should be” definitions for the serial port numbers, how I will implement them, when Roger is ready!
I wrote a little test code to check out all serial ports (the LED is blinking, so you know that the code is working)
#define ledpin 13
boolean flip=0;
void setup() {
Serial.begin(9600);
Serial1.begin(9600);
Serial2.begin(9600);
pinMode(ledpin,OUTPUT);
}
void loop() {
flip=!flip;
digitalWrite(ledpin,flip);
Serial.println("Port: Serial0");
delay(100);
Serial1.println("Port: Serial1");
delay(100);
Serial2.println("Port: Serial2");
delay(100); // delay in between reads for stability
}
-rick
I got fed up with coding for work yesterday so didn’t look at the restructure needed for the Nucleo
As you both use Git I will make a new branch so you can test, as I don’t want to break the whole repo with this change.
Rick: This has one reason: Months ago my plan was to get a “real Arduino pin header compatibility” for the nucleo boards. On standard setup it was hard wired to the D0/D1 pins (PA2/PA3) [I can’t remember or it was – even worse – the D2/D8 pins] so this pins are blocked for shields, “normal” serial connections, whatever. So I remapped (In boards.cpp) the USART to PC10/PC11 (only morpho headers) and you need only to solder a short connection to the virtual com port of the ST-Link2.1 and D0/D1 became the “serial1”. So I got a nearly perfect “arduino header” compatibility {‘nearly perfect’ – some PWM pins are not remapable – shame on STM and their publicity department – you’ll never get this fixed! }
With or without the solder hack: You weren’t able to use “Serial” for USB-debugging without modifying the core code.
@Roger: Github – Ok, this would be a good solution. I can test the nucleo and the maple mini board for compatibility!
The issue appears to be that the Nucleo connects HW Serial 2 to the STlink chip.
So what Matthias wants me to do, is to change the repo so that we can remap Arduino “Serial” e.g. Serial.print(“….”); to HW Serial 2
This isn’t possible with the current structure.
Both Matthias and I have looked into this, and I think the best / most reliable approach (without possibly writing some incomprehensible macros) is just to move the Serial constructors into the board variants.
Its not a complicated change, and it means for Maple devices, there is less code, as it removes a whole block that is always #ifdef’ed out
But I does mean I need to modify every variant, hence it was not top of my to do list as its time consuming, as I have to do test builds on all variants in various configs to be sure nothing hasnt been overlooked.
I’m not sure if I discussed the change with Mathias in a PM or in a thread (possibly a PM), anyway, its no big deal
Free pins D0(PA3) and D1(PA2) and route Serial2 Debug (optional!)
And as I wrote now in viewtopic.php?f=29&t=248 you need to put out your soldering iron anyway (unless you want to use the internal OSC and get in real troubles with accuracy -> this was the attempt of the first conversation by leaflabs with a rusty 36MHZ “for stability” as master clock)
The issue appears to be that the Nucleo connects HW Serial 2 to the STlink chip.
Both Matthias and I have looked into this, and I think the best / most reliable approach (without possibly writing some incomprehensible macros) is just to move the Serial constructors into the board variants.
It may be possible to do that, i.e something Matthias and I overlooked, but the hardware serial stuff already has some macro’s that make this complicated.
Its easier just to move the code into the variants
About PLL: I use my nucleo for some audio related real time stuff, so 1% would drift my tuned frequencies away and I need the whole 72MHZ (the more MHZ, the more voices for my STM32 synth project) and you are right with the temperature: I don’t need a build in temperature-to-pitch onboard effect
So soldering 2 bridges is no effort for getting the better result without “downgrading” the MCU for about 1/3 of speed.I know you are at work etc, but when you get chance e.g at the weekend… Can you grab
https://github.com/rogerclarkmelbourne/ … o_variants
i.e its the move_serial_config_to_variants branch of the repo (so if you are using Git you will need to “git pull” and then “git checkout move_serial_config_to_variants”
And see if this resolves the issue with HW Serial 2 being the one attached to the STLink.
Basically the only change to the variant is to board.cpp as I added the define macros to there, and I had to add 2 includes to the top of that file (for HardwareSerial and usart)
I also moved the macro “DEFINE_HARDWARE_SERIAL” to HardwareSerial.h as its still common to all boards
To be honest, I don’t see much point in the macro, they could all be written out like
HardwareSerial Serial(USART1,BOARD_USART1_TX_PIN,BOARD_USART1_RX_PIN);
Note the only complication is that he last 2 HW Serial ports on the High Density devices are UARTS not USARTS, but this wont effect the F103RB
PS. I’ll PM @sheepdoll so she can test this branch as well.
I had a little time to try out the new serial variant.
At first: Congrats, you nearly did it!
Please change in the nucleo boards.cpp the new lines to:
#ifdef SERIAL_USB
DEFINE_HWSERIAL(Serial1, 1);
DEFINE_HWSERIAL(Serial2, 2);
DEFINE_HWSERIAL(Serial3, 3);
#else
DEFINE_HWSERIAL(Serial, 3);// Use HW Serial 2 as "Serial"
DEFINE_HWSERIAL(Serial1, 2);
DEFINE_HWSERIAL(Serial2, 1);
#endif
I tested on my F103c8 board, so I expected the maple mini would work;-)
I will use the definitions you have posted, and upload to the repo later.
Can i remove the serial USB section ? Is it possible to use serial USB on the Nucleo, I don’t even know if it has a USB directly connected to the main processor ?
You are right, there is no physically USB connection on any nucleo board.
Keep in mind, that for every “new” nucleo board (F4xxx) this modification is useful and must be set!
regards
Matthias
OK about new Nucleo boards.
The structure of the F4 code is a lot different from the F1 code, so I’m not sure the same thing could be applied. I’d need to look.
I think fairly soon, I will need to devote a few days to update / merge the F4 and the F1 code, but its not an easy job ;-(
Connecting wires from PA2/PA3 to the STLink TX/RX and running Madias’s seral tests sketch from above I got “Port: Serial0” in the monitor window.
Attempting to upload a change in the sketch called the Maple booloader rather than the STM link. Disconnecting the line from PA2/PA2 and the modified sketch uploaded. Bit confusing as in software the ports names are zero based, but in STM cube they are unity based from 1. I also got a bit confused as USB is on USART1. It looks like when PA2/PA3 is connected to the STLink the VCP sees the target device as a raw chip
Switching to PC10/PC11 gives “Port: Serial2” as expected. Uploads work when connected to PC10/PC11 connecting just the line to D8 (PA9) gives “Port: Serial1”
Anyway good work, and reward yourself for time well spent. This F103 board is actually useful now.
@madias sent me an updated file for the mapping, so I will use his, as he is the expert
I’ve not had chance to do the update yet as I’ve had some other urgent things to do this morning
I’ll probably update it later
#else
DEFINE_HWSERIAL(Serial, 3);// Use HW Serial 2 as "Serial"
DEFINE_HWSERIAL(Serial1, 2);
DEFINE_HWSERIAL(Serial2, 1);
#endifI will try to update this later, or definitely by the weekend.
But I’ve not had time to do it today,
![[SOLVED] Discovery STM32F100RB — Trouble with timers and library structure](https://sparklogic.ru/wp-content/uploads/2019/11/st-stm32vl-discovery-90x90.jpg)