How to Flash a brand new, freshly soldered STM32F103 chip

1

Hello

I have a question about programming brand new STM32F1xx chips, as it relates to the Sparkcore as a development platform and subsequent, custom board production.

Setting the Scene

So, let’s say I have made my own PCB, which contains a brand new, never-before-programmed STM32F103 chip, like the one on the Sparkcore. For what it’s worth, let’s assume that the TI WiFi module and other peripherals are present and wired up just the same, as well.

Continuing this hallucination, I have just received my shiny new ST-LINK/V2 programmer. (I have not actually, so I do not know what software comes with it) and I have wired up an adapter along the lines of the Spark Programming Shield, to get the 20-pin JTAG connector on the ST-LINK/V2 connected to the right pins of the STM32F’ chip on my custom board.

My board is running on its own power supply, just like the Sparkcore.

I am using an iMac, with OS X 10.9.2 (Mavericks). I have VMWare and Ubuntu 12.04 Desktop (64-bit) at my disposal, as well as Windows 8.1 Pro, also as a VM. But I would prefer not to use either of those, if it can be avoided.

Finally, My Question

Can someone please give an concise example of what I would need to do next to get, say, the Sparkcore DFU bootloader flashed into my new chip? Indeed, if any of the steps outlined above are errant, please let me know.

I am not asking for all the nitty gritty details, like screenshot or whatever. Just a brief outline of exactly what is needed, whether it runs on OS X and the general steps that others have already successfully followed, to make this happen – and of course, anything to avoid.

Many thanks! :smiley:

There’s some history behind this. Long story short, I have in the past purchased an Olimex ARM-USB-OCD JTAG device and attempted to use that, along with its requisite OpenOCD software. This was a disastrous waste of money and effort of the kind I would very much like to avoid running into again. :non-potable_water: This is why I’m posting this question, to try and start off down a path of effort and spending that will lead to the tower of success, first time. \o/

ANSWER: In the end, the answer came down to …

  • Preferred: ST-Link/V2 debugger with downgraded V2.14.3 firmware and st-util / arm-none-eabi-gdb combo, on my Mac runnig OS X 10.9.2 (Mavericks). Especially handy as it supports the GDB load command, to flash your .elf file from one handy interface. (You can also use st-flash on the .bin file, separately.)

  • Also works well: Olimex USB-ARM-OCD debugger with OpenOCD / Telnet / GDB combo. (Costs more than the ST-Link/V2 solution. About as easy, once you conquer the steeper learning curve.)

IMPORTANT: You must use the circuitry of the official Spark Programming Shield – if not the shield itself, of course. Pay special attention to the pull-up resistor on the TDO line.

1 Like
2

Basically, you need a ST-link V2 programmer to program the brand new chip.

Once you have some bootloader of that sort, you will be able to use DFU to do the job. With that said, the bootloader can only be changed using the programmer.

3

Hey @kennethlimcp. Thanks for the reply, but I guess I wasn't clear about what I was asking.

What software is required? Does the ST-Link/V2 programmer come with it? Does it run on OS X? Is it GUI or command line or both? What steps work best? Have you actually done this yourself on a Mac? What version of OS X? Can you give a specific example of the work flow -- especially if it's a command line thing?

You see, I want to be certain that what I buy next will work on my system, because I've already shelled out money for hardware and adapter PCBs that were recommended by other people, but which turned out to be purely useless.

Thanks.

4

I don’t own one and dont have a mac too. haha!

Looks like it might be a command line thingy on Mac and you have to build it or something.

@zachary and @satishgn will know best :wink:

Why wouldn’t you consider the cores since the bootloader, manufacturing etc are all done for you? :smiley:

5

ST-Link comes with a utility program that only runs under Windows (works fine with 8.1) and you can use that to write a .bin file to the chip. I’ve used to re-ffash the boot loader on the Spark Core. You can also use ST-Link with CO Ide (a free development environment from CoCox that has great support (including debugger) for the STM family of ARM chips. Co Ide also only works with Window.

6

Because it's too expensive and bulky for bulk-produced custom devices based on the Sparkcore.

If you read the spark.io home page, near the bottom you'll read the following (se the part I marked in bold) :wink:

Built to scale

The Spark Core is a development tool, designed to get your project off the ground quickly. But what happens when your production volume scales to thousands? The Core is ready.

We use industry-standard components — chosen to be powerful, inexpensive, and widely available — that can be designed directly onto your own circuit board, bringing your Bill of Materials down for volume production."

I have already made a one finished project, where I just soldered the entire Sparkcore onto my custom PCB. It was the best choice for this one. But I have other ideas in mind for smaller projects, where I'll need to compact things down. If anything I ever do becomes a product that others want to buy (unlikely, knowing me!) then doing this will help the costs considerably, so long as I'm producing enough of them in each batch.

So I want to learn how it's done, by practicing it in real life.

2 Likes
7

@pra – thanks for that.

What about chip configuration? With Atmel AVR and Microchip PIC chips that I am more familiar with, there are configuration registers that need setting, to set what type of oscillator, what speed and for locking Flash memory for bootloader sections and all that sort of thing.

My Olimex ARM-USB-OCD JTAG programmer/debugger has to be controlled via a program named OpenOCD. It has zillions of commands to learn and I have so far been unable to find any information about such chip configuration. Like for example, I can use it to flash a boot loader, but then the bootloader doesn’t seem to actually run on the chip. I suspect there are other things that need doing. The ST documentation is not clear to me. I have read so much and continue to go back to the data sheets. But I’m missing something.

8

Yep the ST-Link Utility coupled with the Spark JTAG programmer shield is what you need.

Just load that bootloader bin and program it to the default address of 0x8000000 and the proverbial Bob is your uncle. You can also use the utility to program the core-firmware to address 0x8005000 easily. DFU over USB works super fast too once you have the bootloader installed.

I’m sure there are other open source solutions out there that could be made to work on a Mac, but I don’t know what they are.

Full guide here:

1 Like
9

Well chip configuration is required for all ARM microprocessors, regardless of vendor. ARM mandates all vendors provide CMSIS for their product that standardizes a lot of this. Most vendors, including ST Micro, provide a library of low level routines that will perform configuration and provide drivers for most stuff. CooCox provide all these with the CO Ide. You probably need to read ST PM0056 STM32F10xxx/20xxx/21xxx/L1xxxx Cortex-M3 programming manual and the RM0008 Reference manual for STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced ARM-based 32-bit MCUs if you haven’t already…
.
and of course, the Spark open source software does this for you.

I have any number of JTAG adapters for FPGA’s and various brands of micro controllers (they all seem to be different). I’ve found ST-Link coupled with Co Ide by far the simplest to use.

10

Thanks. Sounds though like you are talking about configuration done in executing code, during boot-up. This is not what I was referring to (guessing about) earlier. The other chips I have been used to (much less powerful, 8-bit devices) have configuration "fuses", which need to be "burned" by the programmer itself. These configuration fuses have nothing at all to do with code that is executed by the CPU. Indeed, often times, the MCU will not execute a darn thing until the fuses are set right.

In any case, I've gone through all the data sheets etc again and I can find nothing of the sort for ARM based chips. So that pretty much solves that, for me. It seems that with these STM32 chips, you simply flash your code (which includes configuration instructions as the first thing is does) and you're good to go.

That's good to know Thanks.

Meanwhile, in the time between my last message and this, I was also able to get a proof-of-concept flashing done, on a Leaflabs Maple (which has the same STM32F103 chip) using the Olimex programmer I was grumbling about earlier. Specifically, after much to do with compiling various versions of open source code and having to resort to a Linux machine, I was finally able to flash a brand new STM32F103 chip with some LED blink code -- and it freakin worked! Amazing.

Either way, it still seems to me like I need to get my hands on an ST-Link/V2, if I want my life to be easier!

Thanks again.

11

@BDub … thanks. Somehow, I completely missed your post, earlier.

I’m about to go read the guide you posted.

In the meantime, I have obtained an ST-Link/V2 and got it running with OpenOCD.

I tried ST-Util first, which I found by Googling something or other. It worked well for flashing but was a dead loss with GDB. All kinds of, “Can’t access memory blah”.
EDIT: See next post, where this was somehow, magically resolved.

OpenOCD seems to work with GDB at first glance (and for flashing.) But in fact, there’re a bunch of problems there, too – like break points not always working and when they do, step and next doing weird things, until eventually, communication is just plain lost in a sea of time-out errors or similar.

Incidentally, I eventually also managed to get my Olimex ARM-USB-OCD to work. It seems about as reliable as the ST-Link/V2, though with a few twists and turns along the way, which I could have done without. The ST-Link was an out of the box, instant success (for flashing).

The learning curve continues.

1 Like
12

I revisited the ST-Link using st-util and GDB, last night. Not sure what changed, but it’s now working well now with, plus or minus the usual oddities with breakpoint not always firing. Had another go this morning and again, all is well.

Of particular interest with this set-up, compared to the Olimex ARM-USB-OCD, is how one can execute a load command and st-util will take care of flashing the ARM chip – even though GDB only has the .elf file to go by. Nice. This is the way I would have expected the Olimex and OpenOCD to work, too. But it doesn’t.

Oh – one thing I did note is that a, monitor reset halt (in GDB) does not seem to fully reset things. Seems the halt happens, but the reset itself, not really. (Some changes to PC but, well yeah. Weird.) But if I execute that command first and then press the hardware reset button, things proceed much better. Oh and, after the hard reset, the ARM chip does remain halted. I should note though that my current set-up does not have the hardware /RESET line connected, as that is causing permanent lock-up for some reason – it’s being held low by the JTAG hardware. Still working on that one.

Recall that this is all on a Mac, running OS X 10.9.2 (Mavericks) not Linux or Windows, which I understand work much more reliably. EDIT: Or do they? See next post, as the plot thickens …

13

And the plot thickens … (aka A comedy of errors) …

I downloaded the Windows ST-Link software and latest firmware upgrade for my shiny new ST-Link/V2, just so I could see how people in Windowland see things. But it doesn’t work!

I got the drivers installed in Windows 8.1 and then the firmware upgraded in the ST-Link/V2 to the latest version (V2.J20.S4) without issue. However, the ST Link program itself cannot connect to my target (Sparkcore), no matter what I try.

Then I noticed that the firmware upgrade came with a second file, STLinkUSBDriver.dll, presumably to match the firmware upgrade. Alas, there are no instructions anywhere about how to install that, let alone what version of Windows it may or may not work with. (There is a PDF file detailing what the firmware upgrade addresses, but no mention of the .DLL file.)

To try my luck, I searched my entire Windows 8.1 system for a file named STLinkUSBDriver.dll, but came up empty. This seemed like a good time to throw my arms in the air and give up on Windows for this thing. HOW BIZARRE. :non-potable_water:

The error reported in ST-Link V2 software is simply, “Cannot connect to target. [Useless advice.] Internal command error.”

But that’s not all! LOL

Turns out that, with the latest ST-Link/V2 firmware (V2.J20.S4) installed, my OS X st-util no longer works! Good grief. :blush:

Luckily, the ST-Link V2 software in Windows itself also includes a firmware, “upgrade”, which is a version between what my ST-Link/V2 came with (now lost forever) and the latest available firmware (V2.J20.S4). Downgrading to that version (V2.J19.S4) got things working on the Mac again. Whew!

Incidentally, my JTAG interface follows the schematic of the Spark Programming Shield which, as I said, works just fine under OS X, using st-util.

What a mess. Obviously, I prefer working on my Mac, from the command line. So I’ll leave things as they are.

All in all, it seems to me that ST have a lot of work to do to sort out their proverbial brown mucky stuff, regards programmers and debuggers and supporting software, compared to other vendors like Atmel and Microchip. (Microchip don’t have any ARM-based offering to my knowledge, though their lonely MIPS MK4 based PIC32 chip is pretty good. If only it had better free tools to work with. But I digress.)

14

OK. So I got the ST-Link/V2 working nicely yesterday with st-util and st-flash on my Mac (see two posts back.) Then I go to bed, wake up, brush my teeth, take a shower etc, only to find that it no longer works, at all. I have changed NOTHING.

Even stranger, my Olimex ARM-USB-OCD that was giving me all kinds of grief until I purchased the ST-Link/V2 to fix all that, is now working without a glitch!! WTF?! So confused.

[emotional-rant]
I have never in my 20 odd years of playing with microcontrollers ever had such random, unreliability with programmers and debuggers (Intel 8051, Microchip PIC 8/16/32 bit, Atmel AVR) as I have since starting to play with ST ARM chips. It's very frustrating and difficult to understand what is going on. Am I the only one? Is there some conspiracy that I don't know about? :stuck_out_tongue:
[/emotional-rant]

The first clue that something was wrong was the difference seen in the following two examples. The first is from yesterday, thanks to not closing the terminal window and being able to scroll back. Note the Flash size being reported by st-util ...

Yesterday ...

$ st-util
2014-04-18T17:07:58 INFO src/stlink-usb.c: -- exit_dfu_mode
2014-04-18T17:07:58 INFO src/stlink-common.c: Loading device parameters....
2014-04-18T17:07:58 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2014-04-18T17:07:58 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0 bytes (0 KiB) in pages of 1024 bytes
Chip ID is 00000410, Core ID is 1ba01477.
Target voltage is 3217 mV.
Listening at *:4242...

And today ...

$ ./st-util
2014-04-15T19:48:52 INFO src/stlink-usb.c: -- exit_dfu_mode
2014-04-15T19:48:52 INFO src/stlink-common.c: Loading device parameters....
2014-04-15T19:48:52 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410
2014-04-15T19:48:52 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes
Chip ID is 00000410, Core ID is 1ba01477.
Target voltage is 3229 mV.
Listening at *:4242...

The next and arguably more serious sign that things were not right came when running GDB and noting the initial (corrupted) PC address ...

$ arm-none-eabi-gdb -x gdb-st.rc ../build/core-firmware.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /Users/bryan/sparkcore/core-firmware/build/core-firmware.elf...done.
0x8a3442ba in ?? ()

Nope. That just aint right at all.

FWIW, here's what OpenOCD had to say, using the Olimex ARM-USB-OCD ...

$ openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.8.0-rc1 (2014-04-13-19:52)
Licensed under GNU GPL v2
For bug reports, read
OpenOCD: Bug Reporting
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : device id = 0x20036410
Info : flash size = 128kbytes
undefined debug reason 7 - target needs reset
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)

And the related, successful GDB session ...

$ arm-none-eabi-gdb -x gdb.rc ../build/core-firmware.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20131129-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-apple-darwin10 --target=arm-none-eabi".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /Users/bryan/sparkcore/core-firmware/build/core-firmware.elf...done.
0x00000000 in ?? ()
JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800010c msp: 0x20005000
(gdb) break main
Breakpoint 1 at 0x80057ec: file ../src/main.cpp, line 156.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at ../src/main.cpp:156
156 {
(gdb) c
Continuing.

Much better.

So, you tell me. Everyone is saying the ST-Link/V2 is THE way to go with the Sparkcore. But I cannot even get mine to work at all under its intended Windows environment -- and although it worked for a day yesterday on my Mac, today it does not. I suppose it could be faulty, somehow. Perhaps I'll buy another one, just to try and get to the bottom of this. Thankfully, they're not too expensive.

15

I replied to @gruvin in another more focused thread, but I wanted to make sure the link was available from here too:

1 Like
16

Thanks Zach.

The story in this thread is long enough already, so briefly …

The ST-Link/V2 and st-util is working again on my Mac

I found an older version (V2.14.3) of the ST-Link/V2 firmware, here. Now everything is working well.

Summary

For whatever reason, my experience here suggests that at least ST-Link/V2 firmware versions V2.19.4 and upwards have some kind of incompatibly with their Windows 8.1 Pro / St- Link Utility and OS X 10.9.2 / st-util / gdb host computer counterparts. Downgrading the ST-Link/V2 debugger’s firmware to V2.14.3 appears to have fixed the problem for me, hopefully once and for all.

@zachary says that his ST-Link/V2 and st-util on his Mac are very stable. In due course, I hope to get a report back from he or @Dave as to exactly what version of Firmware happens to be in his ST-Link/V2 debugger. With any luck, that will help validate my experience here. I hate it when things don’t makes sense. :stuck_out_tongue:

1 Like
17

Hi my dears!

I need an firmware to ST-Link-V2/1 and I just found a google drive folder with ST-Link-V2 firmwares that you share (link).

Anybody have any ST_Link_V2/1 firmware too? Like V2J28M16.

Thanks for you attention.

18

Hello

The firmware I currently have in my ST-Link V2 is: V2.J24.S4. Unfortunately, despite significant and perplexing efforts, I am unable to find a copy of that version anywhere, now. :cry:

Either way, I have found the ST-Link / OpenOCD set-up to be anything but cooperative for anything but the most basic tasks -- and I never seemed to be able to get ST-Util to work much at all, back then anyway.

More recently, I have been using cloned Segger J-Link devices like this one in Serial Wire Debug (SWD) mode -- well that one only has that option, actually. It works great! But it's also in disagreement with Segger's software licence (BAD!) and so not the way I wish to proceed.

Frustrated and frankly pissed off over all this (ST's lack of care for us makers -- not those who have given it a their best shot already) I was about ready to scratch-write my own damn tools when ...

THANKFULLY ... there is now the, Black Magic Probe ARM debug tool (curenlty a KickStarter campaign) which I expect will solve all the above problems and just generally WORK properly, on ALL platforms (even a VT100 terminal, probably!) -- and it's 100% open source (legal!) I cannot wait to get mine.

The BMP is beautifully built, but bit pricey. However, I've heard that its firmware can be flashed into some $4 ST-Link clone.

Good luck!