Getting started – Partial success – what next?

sheepdoll
Sat May 23, 2015 2:26 am
This is sort of a continuation from my introduction post.

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!


RogerClark
Sat May 23, 2015 11:45 pm
This probably wont be much help.

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


sheepdoll
Sun May 24, 2015 1:02 am
That is the thread that lead me here 175 or so pages!

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 Kimball
Sun May 24, 2015 1:29 am
What OS/X are you running. I have no hope of ever running this stuff on my 2009 iMac with 10.6.8 .. as it doesn’t support the required drivers (cdc acm tty drivers). However I can use an FTDI USB-Serial device (alluding to why you might have been able to use avr stuff successfully) because there is an FTDI driver for my version of OS/X. I guess I could upgrade the OS/X on my iMac but I just run linux (granted not a normal usage).
-rick

Rick Kimball
Sun May 24, 2015 1:48 am
With the NUCLEO board, it should show up as a Disk Drive on the mac. You can use the Arduino IDE to compile .. then find the sketchname.bin file in the temp directory and just drag and drop it on the “Nucleo Drive” (I have no idea what name it shows up as on a mac).. When you drag and drop a binary on the Nucelo drive it will flash that code on your f103 chip.

sheepdoll
Sun May 24, 2015 3:11 am
Hi 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.


RogerClark
Sun May 24, 2015 4:12 am
@sheepdoll

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. ;-)


sheepdoll
Sun May 24, 2015 6:01 am
Here is what I get from the verbose download. I think everything is working The stlink flickers and stays green after the download.

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!


RogerClark
Sun May 24, 2015 6:42 am
I’m not entirely sure about the LED etc on that board

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
};


madias
Sun May 24, 2015 10:10 am
Just for short:
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

RogerClark
Sun May 24, 2015 11:16 am
Matthias

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)


madias
Sun May 24, 2015 12:37 pm
I suspect, sheepdoll didn’t solder the jumper for the oscillator. There was initially a piece of code in the original leafmaple nucleo variant to use the internal OSC/PLL settings, but this never works to me, so I researched and found out that on some models there is no quartz connection to the main STM32F103RB but the option to use the quartz from the ST-link adapter. This is done with 2 soldering bridges.
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?

RogerClark
Sun May 24, 2015 9:43 pm
Matthias

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


madias
Sun May 24, 2015 10:24 pm
Ok, let me try to summarize it (ST-Link):
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)

sheepdoll
Sun May 24, 2015 10:43 pm
@madias

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.


mrburnette
Mon May 25, 2015 2:23 am
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)

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


RogerClark
Mon May 25, 2015 4:35 am
Ray

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.


sheepdoll
Wed May 27, 2015 5:30 pm
Roger, Madias;

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?


madias
Wed May 27, 2015 8:05 pm
sheepdoll:
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 Kimball
Wed May 27, 2015 8:55 pm
All the Nucleo boards I have (a couple of STM32F0 boards) you can just use the Nucleo Virtual port and it is wired to one of the USART TX/RX pairs. I just looked at the NUCLEO-F103RB documents, it seems that is also done that way. Why are you soldering / desoldering anything? Just use USART code to talk out the NUCLEO Virtual COM port.

-rick


RogerClark
Wed May 27, 2015 8:59 pm
Sorry guys

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.


madias
Wed May 27, 2015 9:40 pm
Why are you soldering / desoldering anything? Just use USART code to talk out the NUCLEO Virtual COM port.
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!

Rick Kimball
Wed May 27, 2015 9:47 pm
madias wrote:Why are you soldering / desoldering anything? Just use USART code to talk out the NUCLEO Virtual COM port. ….so this pins are blocked for shields,

RogerClark
Wed May 27, 2015 9:59 pm
Rick

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


madias
Wed May 27, 2015 10:02 pm
Ok, there was a second thought behind that: You can get rid of any “software serial” solution and use D0/D1 “Serial1” as “real” COM ports and using “Serial” as debugging port even for shield using D0/D1 for something else than USART (many TFT shields as example). As I wrote in the doc’s:
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)

Rick Kimball
Wed May 27, 2015 11:20 pm
madias wrote:(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)

Rick Kimball
Wed May 27, 2015 11:24 pm
RogerClark wrote:Rick

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.


RogerClark
Wed May 27, 2015 11:26 pm
Rick,

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


madias
Thu May 28, 2015 6:11 am
@Rick: I already have done a #ifdef solution in HardwareSerial.cpp (and I use it for myself, until a common solution is ready), but the drawback is, this is only for the nucleo board, so board specific. Think, there is a “new board” in the next future than a second one and the whole HardwareSerial.cpp is full of board specific #ifdef’s. So the bitter pill, putting out the whole macros from the core into the /variants is the sustainable solution.
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.

RogerClark
Thu May 28, 2015 7:50 am
Matthias

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.


madias
Thu May 28, 2015 6:50 pm
Dear Roger!
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


RogerClark
Thu May 28, 2015 9:51 pm
Hi Matthias

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 ?


madias
Thu May 28, 2015 10:17 pm
Yes, it should be safe (I have done only compiling deleting it, not “real” tested, but this wouldn’t be necessary )
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


RogerClark
Thu May 28, 2015 10:57 pm
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 ;-(


sheepdoll
Fri May 29, 2015 12:44 am
As far as I can tell I installed the serial test branch

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.


RogerClark
Fri May 29, 2015 3:21 am
@sheepdoll

@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


madias
Fri May 29, 2015 6:54 am
@sheepdoll: This was the little change I provided to Roger, meanwhile you can edit in the /variant/nucleo_103rb/board.cpp the very last lines to
#else
DEFINE_HWSERIAL(Serial, 3);// Use HW Serial 2 as "Serial"
DEFINE_HWSERIAL(Serial1, 2);
DEFINE_HWSERIAL(Serial2, 1);
#endif

RogerClark
Fri May 29, 2015 7:27 am
Matthias

I will try to update this later, or definitely by the weekend.

But I’ve not had time to do it today,


Leave a Reply

Your email address will not be published. Required fields are marked *