STM32F103 any good?

[Muxr]

I've done some AVR development in the past. My background is software engineering so I don't mind learning a new language or environment.

But basically I've been shopping around for an MCU to migrate to after using 8Bit AVRs. I was mainly looking for cheap MCUs in case I decide I want to mass produce one of my projects, so the price is really important.

I was shocked with how cheap these (STM32) F103s are. For instance one of my projects is a clock and I have a need for an RTC module but this STM32 comes with a built in RTC. It's actually kind of mind boggling how much more advanced and how many more features F103 packs for the same price as an AVR Atmega328.

I mean you get: 75Mhz, 32Bit arch, 64Kb Flash, 20Kb SRAM, 2x12Bit ADC, bunch of interfaces, USB2.0, 7-channel DMA

I ordered a few of these $4 boards to play with: http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

There is an open source Arduino toolchain: https://github.com/rogerclarkmelbourne/Arduino_STM32  It's pretty experimental though.

So I guess the question I have is, what's the catch? Anyone have experience with STM32 Cortex M3 F10x controllers, are they any good? And where should I begin in terms of software tools to program these guys? (preferably OS X / Linux toolchains).

[HackedFridgeMagnet]

It's a great step forward to get out of the Arduino ide.
I use eclipse with the cdt plugin and gcc and openocd(i think that is its name) for the debugger.

There is a fair bit of effort to set it up if you haven't done it before.
But there is plenty of support around and you wont look back.

the best way to start coming from arduino is probably the nucleo boards and some intro (limited) ide that should come with a board.

[chickenHeadKnob]

The stm32f103 is one of the older cortex m3 processors and for historical reasons unknown to me became very popular in china some years ago. That means you can find many ebay offerings at well below digi-key pricing so they are great value for the money. If you want cortex m4F (hardware floating point) some members of the stm32f3xx can be found cheap from north American disti's, but not as cheap as the 103. The newer stm chips have better (and more) timers and other peripherals.

[Jeroen3]

The RTC in the F103 is only a 32 bit counter and does not provide calendar features. And usually the inernal 32Khz oscillator does not run on Vbat, something to be aware of. (I'm not sure in this chip)
The F103 can only run 36 MHz from internal oscillator. For 72 MHz you'd need an external source. (You'd need it USB anyways)

[neslekkim]

Look at this thread: https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/
and all the spinoff threads..

[andersm]

The I2C peripheral is badly designed, otherwise it's a pretty straightforward chip.

[Psi]

Yep f103 is good, be prepared to learn a standard peripheral library as opposed to fiddling with the raw registers as you do on AVR.
Its much more feature advanced so you really need a peripheral library or it takes ages to get stuff working.

Also the AVR registers are as dream to code, everything is layed out in a way that makes sense. Stm32 not so much, but with the library you don't need to go  down to that level anyway.

Be aware there are many things in stm32 you need to enable that were on by default in AVR. Clocks for various parts of the chip and stuff

[muvideo]

The RTC in the F103 is only a 32 bit counter and does not provide calendar features. And usually the inernal 32Khz oscillator does not run on Vbat, something to be aware of. (I'm not sure in this chip)
The F103 can only run 36 MHz from internal oscillator. For 72 MHz you'd need an external source. (You'd need it USB anyways)

In the F103 the RTC runs off Vbat, internal oscillator can be used to clock the chip up to 64MHz.

[Jeroen3]

In the F103 the RTC runs off Vbat, internal oscillator can be used to clock the chip up to 64MHz.

Yes. And that's where you need to read carefully. There are multiple series sharing the documentation and number STM32F1xxxx. Very ambiguous.
Connectivity line devices can only go up to 36 MHz and Low-, medium-, high- and XL-density series can go up to 64 MHz from hsi.

[tszaboo]

Yes the F103 is one of my standard components to use. It is good, well designed. I think the only time when it was a letdown, when we realized that the USB and the CAN cannot work concurrently.
But you need to be aware that only the smaller F103s are the ones I can recommend. If you need more than the 20K SRAM and 128K flash, there are much better choices even in the F300 and F400 series.

[poorchava]

Yes the F103 is one of my standard components to use

Ditto. I tend to standarize on STM32F030F4 for small stuff, STM32F103 for medium and STM32F407 when in need of serious processing power.

As for IDE, I recommend CoIDE from CooCox. For me it is practically problem-free, and all the external setup you need to do is to install the arm-gcc and provide the path to it in IDE. It's totally free (no limitations whatsoever) and in general supports most of ST's Cortex uCs

[daybyter]

This board does not support external RAM, right? (Ordered one, too.)

[Brutte]

These F1/F2/L1 chips from STM have very similar peripherals.
The F103 is a faster and feature-rich version of F102, although F103 is cheaper in retail, it may not be in volume.

For development, I'd suggest picking a 512kB flash/64kB SRAM in LQFP100 or higher, for release you can pick anything that barely matches the requirements (down to 16kB QFN36). Mind these 72MHz chips are optimized for speed so jumping from coremark=11 for AVR8 to coremark=108 of F103 may not be what you expect (GCC).

Now the differences..
These chips use 3,3V nominal voltage, some IOs can operate up to Vcc+4V, around 8V max in open drain mode (I think they refer those as "5V tolerant"). This "feature" means that internally these 8V IOs do not have the upper clamping diodes. So, if you apply 12V through 4k7 resistor to an IO of AVR8 then nothing spectacular happens, IO is driven up to Vcc+0,7V and upper clamping diode limits the voltage.
The problem is that same experiment should fry the 8V IO on STM32.
Now, not all STM32 IOs are 8V compatible. Some are just regular IOs with both clamping diodes. Here injecting current won't damage the chip "if you limit the current to the one specified in maximal ratings of course " but can ruin ADC readings of the uC.

As of the toolchains, if you pick the IDE with wizarding (like uVision or CooIDE) then the setup is similar to the one with AVRStudio. Just name the project and:

Code: [Select]

int main void(){..... return 0;}However, if you decide to pick a bare metal route, then it is same as with bare metal AVR8 and you have to provide your own linker, startup code, IRQs etc. If you never wrote startup code and/or linker scirpt for AVR8 then most likely writing one for STM32 is going to discourage you (even configuring a clock tree can ruin your day).

[poorchava]

Another thing: as with almost every ARM uC you need to remember to enable the clock to a peripheral before you can actually use it.

[Muxr]

Thanks for the replies guys, awesome info!

Another thing: as with almost every ARM uC you need to remember to enable the clock to a peripheral before you can actually use it.

Yes I read that, it seems to be ARM's way of making you think of power utilization I believe.

Found their peripheral library as well for F103, STs website is kind of a mess. Found this index of F103 stuff if anyone else happens to be looking for it: http://stm32.eeelec.com/html/STM32F1%20resources.htm  3.5.0 seems to be the latest version of the standard peripheral library.

Browsed around the source, seems pretty straight forward.

[poorchava]

It's not how ARM does it. It's how ST, NXP,  Atmel and such do it. ARM only provides the core,  all peripherals are of particular vendor's design.

[Muxr]

It's not how ARM does it. It's how ST, NXP,  Atmel and such do it. ARM only provides the core,  all peripherals are of particular vendor's design.

I stand corrected. Although they all seem to be doing things in a similar fashion, perhaps something mandated by ARM via CMSIS?

[poorchava]

I don't know. If I had to guess,  my first bet would be on the fact,  that those chips are loaded with many modules and features,  each of which draws some current and not all of them can be used at the same time, so if they were all turned on at all times,  the power consumption figure would be much higher. Since nowadays there is almost always some pressure on reducing the power consumption of a product, this is a really useful feature. Lower power is not only longer battery life but also smaller regulators,  less filtering capacitance lower transient currents when switching and so on.

[langwadt]

I don't know. If I had to guess,  my first bet would be on the fact,  that those chips are loaded with many modules and features,  each of which draws some current and not all of them can be used at the same time, so if they were all turned on at all times,  the power consumption figure would be much higher. Since nowadays there is almost always some pressure on reducing the power consumption of a product, this is a really useful feature. Lower power is not only longer battery life but also smaller regulators,  less filtering capacitance lower transient currents when switching and so on.

it also mean a single part can cover a lot more applications. Compared to the size of ram and flash the peripherals are tiny so it makes sense to add as many as you can think of and just turn them on and off as needed

[Jeroen3]

They typically put the bare die full of stuff they disable later one. Such as extra ram, flash, timers, or maybe even entire Cortex M0's. Such as the lpc43 en 18.
Because if you compare the LPC18 and LPC43 addresses, they are remarkably similar. Just otp't the configuration differently. This is nice, because you don't need to bake many different chips. Just a few, and later on you decide what configuration you'll give them.

Obviously, enabling everything will be problematic with power consumption, and thus temperature specs.

I'm currently working on an small 3xAAA powered proprietary remote control. The STM32F1 XL series (with the 1 MB flash) is capable of doing that.
But it seems just a little bit underpowered for doing a 320x240 spi-lcd, the fancy way. Sure it can draw lines and stuff (using STemwin) but it's a bit slow-ish. I was unable to get the fancy features of emwin working. Maybe because a copy of the LCD does not fit in ram. I was unaware of the "feature" that USB and CAN use the same RAM block. It was nice if one of them was capable of being remapped. This is one of things you discover if you inherit a project.
The power consumption of the STM, with life-support, in this application is about 20mA (3.3V). When I unplug the LCD, obviously.

[Muxr]

Yeah, I was reading the other Ghetto STM32 thread while mostly about the smaller F0s Dannyf actually tested F103 going beyond the Flash 64kb boundary specified in the spec sheet.

Apparently they can have usable 128kb. https://www.eevblog.com/forum/microcontrollers/stm32-ghetto-style/msg516439/#msg516439

[Jeroen3]

On the St forums, Clive1 actually confirmed this for 407 parts.

The ones above the 512KB threshold (>= 0x08080000) have not been tested. The 405/407 parts typically have the same 1MB dies. There is only a single bank of flash.

Just remember that although the memory is available, there are no guaranteed specifications on those parts of flash.

[Muxr]

On the St forums, Clive1 actually confirmed this for 407 parts.

The ones above the 512KB threshold (>= 0x08080000) have not been tested. The 405/407 parts typically have the same 1MB dies. There is only a single bank of flash.

Just remember that although the memory is available, there are no guaranteed specifications on those parts of flash.

Yeah no telling if extra Flash is faulty or a higher grade part bined for lower spec demand.

[poorchava]

Another thing that is different between ARM uCs and AVR/PIC/MCP430. A lot of time-critical registers have different address for disabling and enabling. For example for a gpio port in STM you have a BSRR (bit set reset register) and BRR (bit reset register). When you write 1 to BSRR on position 0 you set gpio0 high, is you write 1 into BRR on position zero, you set gpio0 to low. There is obviously also traditional way via ODR (output data register) where you write 1 or 0 and gpio assumes this logic state.

Another useful thing is bit-banding, which is a mechanism available in CM3 and CM4. It mans that particular registers have an alias somewhere in the memory for every bit in that register which allows truly atomic modification of registers (no read-modify-write problems). Read up on bit-banding.

[Muxr]

That's pretty slick, this article explains it pretty well: http://spin.atomicobject.com/2013/02/08/bit-banding/

[HackedFridgeMagnet]

That's pretty slick, this article explains it pretty well: http://spin.atomicobject.com/2013/02/08/bit-banding/

IMO that article just confuses me.
the link on the ARM website doesn't help much either.
Then the example? I should submit this code to www.thedailywtf.com Why the mailbox analogy?? for something supposedly atomic. Is it like an example of a single bit mailbox between processes?

#define BITBAND_SRAM_REF 0x20000000#define BITBAND_SRAM_BASE 0x22000000#define BITBAND_SRAM(a,b) ((BITBAND_SRAM_BASE + (a-BITBAND_SRAM_REF)*32 \    + (b*4))) // Convert SRAM address#define BITBAND_PERI_REF 0x40000000#define BITBAND_PERI_BASE 0x42000000#define BITBAND_PERI(a,b) ((BITBAND_PERI_BASE + (a-BITBAND_PERI_REF)*32 \    + (b*4))) // Convert PERI address
#define MAILBOX 0x20004000#define TIMER 0x40004000// Mailbox bit 0#define MBX_B0 *((volatile unsigned int *)(BITBAND_SRAM(MAILBOX,0)))// Mailbox bit 7#define MBX_B7 *((volatile unsigned int *)(BITBAND_SRAM(MAILBOX,7)))// Timer bit 0#define TIMER_B0 *((volatile unsigned char *)(BITBAND_PERI(TIMER,0)))// Timer bit 7#define TIMER_B7 *((volatile unsigned char *)(BITBAND_PERI(TIMER,7)))
int main(void){    unsigned int temp = 0;
    MBX_B0 = 1; // Word write    temp = MBX_B7; // Word read    TIMER_B0 = temp; // Byte write    return TIMER_B7; // Byte read}

"// Convert PERI address" what a useless comment, it only makes sense if you know what they are doing.
Is it implemented in hardware? I guess you have to set up the bit banding to work in certain memory areas and by default they are normally turned off.
If you set it up for an area then you reduce the memory available drastically.
Is it only for peripherals? It seems not, the mailbox is in RAM.
Can anyone explain it a bit more clearly? Or have another link?

[Muxr]

That's pretty slick, this article explains it pretty well: http://spin.atomicobject.com/2013/02/08/bit-banding/

IMO that article just confuses me.
the link on the ARM website doesn't help much either.
Then the example? I should submit this code to www.thedailywtf.com Why the mailbox analogy?? for something supposedly atomic. Is it like an example of a single bit mailbox between processes?

#define BITBAND_SRAM_REF 0x20000000#define BITBAND_SRAM_BASE 0x22000000#define BITBAND_SRAM(a,b) ((BITBAND_SRAM_BASE + (a-BITBAND_SRAM_REF)*32 \    + (b*4))) // Convert SRAM address#define BITBAND_PERI_REF 0x40000000#define BITBAND_PERI_BASE 0x42000000#define BITBAND_PERI(a,b) ((BITBAND_PERI_BASE + (a-BITBAND_PERI_REF)*32 \    + (b*4))) // Convert PERI address
#define MAILBOX 0x20004000#define TIMER 0x40004000// Mailbox bit 0#define MBX_B0 *((volatile unsigned int *)(BITBAND_SRAM(MAILBOX,0)))// Mailbox bit 7#define MBX_B7 *((volatile unsigned int *)(BITBAND_SRAM(MAILBOX,7)))// Timer bit 0#define TIMER_B0 *((volatile unsigned char *)(BITBAND_PERI(TIMER,0)))// Timer bit 7#define TIMER_B7 *((volatile unsigned char *)(BITBAND_PERI(TIMER,7)))
int main(void){    unsigned int temp = 0;
    MBX_B0 = 1; // Word write    temp = MBX_B7; // Word read    TIMER_B0 = temp; // Byte write    return TIMER_B7; // Byte read}

"// Convert PERI address" what a useless comment, it only makes sense if you know what they are doing.
Is it implemented in hardware? I guess you have to set up the bit banding to work in certain memory areas and by default they are normally turned off.
If you set it up for an area then you reduce the memory available drastically.
Is it only for peripherals? It seems not, the mailbox is in RAM.
Can anyone explain it a bit more clearly? Or have another link?

I am going to try and explain my understanding of it. Let's first explain what issue it's trying to solve.

Suppose you have a register in memory that is of value 01001001. And suppose the first bit of that byte (currently 0) determines the GPIO pin mode and you want to flip it. You would have to load the entire byte 01001001 just to manipulate that one bit.

Why is this bad, you might ask? Well depending on how you manipulate it your manipulation might take multiple clock cycles to flip just that one bit, because you're dealing with a much bigger chunk of data. If your flipping of that bit takes multiple CPU cycles chances are something else might try to manipulate that byte and cause a race condition. It's basically equivalent of multiple people editing their local copies of the same spreadsheet, you get a mess, you don't know which one is the correct one.

For example, let's call your main program flow, program A, and some piece of code that runs on an interrupt, interrupt B.

Your program A is trying to flip the first bit, it reads the register. So far so good, but before it gets a chance to write the modified version of it, interrupt B piece of code flips a different bit in that byte. And since your program A is unaware it tries to save a stale version of the register byte into the memory, overwriting the change interrupt B was trying to accomplish. Very bad.

So to help developers avoid race condition Bit-banding was implemented. Bit-banding is a pseudo memory location with an interesting property. It's basically a mirror of all the registers but instead of storing 8 bits per byte it only stores one significant bit per byte.

So our little 01001001 becomes 8 distinct bytes in the bit-banding space: 00000000 (only holding the our first bit), 0100000 (only holding the 2nd bit)...etc The bytes in the bit-banding space are interconnected behind the scenes, and flipping a bit in one space, alters it in the other.

So now you can safely take a byte from the bit-banding location to only modify one bit without the fear of accidentally overwriting other bits with stale state. There is also a mention that manipulation bit-banding bytes is a single clock cycle operation making it fully atomic (impervious to race conditions, even on the same bit).

ps. bit-banding sounds terribly memory inefficient, you know "exploding" a byte into 8 bytes each containing 1 bit, but most likely it's all done logically so no memory is actually wasted, it's just wired like that behind the scenes.

[HackedFridgeMagnet]

Thanks for the attempt, but you explained the bit that I do know and not the bit that I don't know.
How is it wired behind the scenes?
What limitations, restrictions or compromises are there? 
I guess I could look it up in the M4 data sheet but until I get the time or use the something of the M4 series I wont worry.
I guess once you get the macros done it is easy to use, but the macros look fairly intimidating at the moment.

[Muxr]

There is a bit more info on LinkedIN of all places: https://www.linkedin.com/groups/How-is-Bitbanding-actually-implemented-85447.S.5834088429486354434

Senior Embedded Technology Manager at ARM

The AHB interface on the processor automatically remap and generate the two bus accesses. it have a side band signal to indicate the read-modify-write sequence is locked (atomic). So even if there is a separate bus master in the system, the other bus master should not be able to inject another transfer in between. (That's assumed the bus interconnect in the system was designed properly :-) )

Applications Engineer at ARM

Try: http://infocenter.arm.com/help/topic/com.arm.doc.set.amba/index.html#amba3

You should find AHB-Lite under AMBA Specifications / AMBA 3

[poorchava]

I will make an attempt to explain.

Suppose you have a register under address A with 32 bits in it. In order to change a bit you'd need to read the register, make a logic operation (for example |= 0x01 to set LSB high) and write it back. If the value in that register has changed in the meantime this change will be overwritten. Thi also takes more time as you have to read, modify and write.

Now the bitbanding works like that: for every bit-band-aliased register under address A, every bit X has an alias-address B which is a function of A and X. This address does not correspond to entire register, but rather to the bit X in register A. You can write a logic value L into address B, which will result in value of bit X in register A changing to L. So in short, every bit in a bit-band-aliased register has its own address somewhere in the address space. Formulas and macros for calculating bit-band alias addresses are availale on ARM website.

In the end if your macro and compile settings are done right, your instruction to switch bit 17 in register 0xDEADBEEF should compile to a single STR instruction (given, that number if bit is known at compile time). This way you could theoretically toggle a gpio pin with FPCU/2 frequency (leaving aside the limitations of gpio ports themselves and assuming that toggling is unrolled and not looped - looping overead in CM3 and CM4 is terribl)

[HackedFridgeMagnet]

Thanks again for explaining. But I still haven't got to the nub of what doesn't seem right.

I can see how it works for registers, this doesn't seem hard at all, some RAM must be permanently dedicated to alias the registers, easy.

What I couldn't see was how it works to bitband some RAM.
Or is it only registers that are aliased? Initially I thought this but the sample code seem to be bit banding the RAM.
Which RAM is an alias for which RAM.
How do you set up a memory map for this?
Ok I will read the doco. I should address my ignorance. No pun intended.

[poorchava]

I don't think that bulk RAM is bit-banded. And if it is I have never used this feature.

The alias addresses are not in RAM, they are simply in address space. When CPU detects write instruction to particular alias register is calculated backwards which bit in which register it should write.

[Jeroen3]

Here you find official documentation from ARM regarding bit-banding. With drawing 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337h/Behcjiic.html

[HackedFridgeMagnet]

Ok thanks now I got it.

[Muxr]

They map two different regions: the lowest 1Mb in SRAM gets mapped as well as the peripheral 1Mb registers get mapped into 2x32Mb bit-banding regions.

While this doesn't take any actual RAM it does eat away 64Mb of the available addressing space which is now 4Gb-64Mb.

[old gregg]

Hi,

I've bought one of those : http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I wanted to jump into ARM processor for some time and I thought this could be a good start. Being from China, no documentation comes with it and what made hesistant abouf ARM is the large choise of IDE/dev board. Is Coocox sufficient ?

[FreddyVictor]

ST are very good at doing their own boards at a reasonable price: F103 version
not as cheap as your ebay one, but it does come with builtin STLink for easy code upload/debugging plus lots of documentation on their website

an alternative to the F103 is the F401 which I believe includes floating point unit

[donotdespisethesnake]

Hi,

I've bought one of those : http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I wanted to jump into ARM processor for some time and I thought this could be a good start. Being from China, no documentation comes with it and what made hesistant abouf ARM is the large choise of IDE/dev board. Is Coocox sufficient ?

CooCox should work, I had trouble when I tried it. I found emblocks worked better for me, together with an STLINK JTAG-SWD adapter which works well and is a lot cheaper then Segger.

If you are at all Arduino inclined you might look at www.st32duino.org, for an Arduino STM32 compatible package.

[old gregg]

thanks,

actually I've just realised that I needed an external programmer. I'm on the hunt for that now. I've documetation to read I think.

Those uC seem to be very interesting.

I don't know emblocks, I'm gonna do some homework.

If you are at all Arduino inclined you might look at www.st32duino.org, for an Arduino STM32 compatible package.

I'm not really keen on Arduino but I must admit that their plug-and-play system is sometime very enviable.

[ajb]

Hi,

I've bought one of those : http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I wanted to jump into ARM processor for some time and I thought this could be a good start. Being from China, no documentation comes with it and what made hesistant abouf ARM is the large choise of IDE/dev board. Is Coocox sufficient ?

CooCox should work, I had trouble when I tried it. I found emblocks worked better for me, together with an STLINK JTAG-SWD adapter which works well and is a lot cheaper then Segger.

I'll second this.  CoIDE was great and easy to use when it worked, but would frequently fail to build or debug a project for no obvious reason, would occasionally crash and destroy my project file in the process, and finally crashed so badly I had to reinstall it.  I didn't have the patience for all the configuration that Eclipse required, so I finally landed on Em::Blocks and am pretty happy. 

If you go with one of ST's dev boards they typically have a built in debugger, so no external tools is required.

If you're already comfortable with AVR, Atmel does make ARM MCUs as well, and they are fully supported by Atmel Studio just as their AVRs are.

[old gregg]

Yes I'm comfortable with AVR but I don't use their software, it crashed the machine at the first run  . I'm using AVRdude but I won't say no to debugger/simulator now...

If you go with one of ST's dev boards they typically have a built in debugger, so no external tools is required.

that was actually my first entention, buy a "discovery board" to get started. I think I still buy one, they're so cheap that it won't be a pain on the wallet.

I think there's also a ARM facility in code::block now that I'm writting this.

[old gregg]

I bring life back to the thread.

I've this board that I'd like to use for a small thing


but I saw it mentioned along with Arduino or Mapple and wonder if I can program it without both. I know there's the SWD pin header which supposes that I can but maybe I'm missing something.  I've got a discovery board from ST that I can, apparantly, use as a programmer for external chip. I tried but nothing good.

Some people had experience with this board ?

[Jeroen3]

The shown board does not pass the absolute minimum to operate. Because it lacks capacitors. Or is the bottom loaded?

Also, if programming fails. The headers are for the bootloader, which should have no effect for swd, but still.
You do also know the Discovery board has headers you must change to use it as ST-Link only?
 

[Hideki]

I have used that board before with no trouble. There are more components on the bottom, including capacitors.

You will need a programmer. I used a cheap ST-LINK V2 clone like this  http://www.ebay.com/itm/ST-Link-V2-Mini-Metal-Shell-STM8-STM32-Emulator-Downloader-Programming-good-/251642538698?hash=item3a97106aca
I'm sure you can use the ST-LINK on the discovery board instead. It may have to be disconnected from the onboard chip first. I suggest reading the docs.

The header at the bottom is SWD. Connect up four wires from the programmer to the board and off you go (look up the pinout first).

[langwadt]

I have used that board before with no trouble. There are more components on the bottom, including capacitors.

You will need a programmer. I used a cheap ST-LINK V2 clone like this  http://www.ebay.com/itm/ST-Link-V2-Mini-Metal-Shell-STM8-STM32-Emulator-Downloader-Programming-good-/251642538698?hash=item3a97106aca
I'm sure you can use the ST-LINK on the discovery board instead. It may have to be disconnected from the onboard chip first. I suggest reading the docs.

The header at the bottom is SWD. Connect up four wires from the programmer to the board and off you go (look up the pinout first).

using a discovery board as st-link is simple, theres a six pin connector with the debug signals and then you move two jumpers

[andersm]

I've this board that I'd like to use for a small thing but I saw it mentioned along with Arduino or Mapple and wonder if I can program it without both.

The chip has a ROM serial bootloader. The two jumpers control the boot mode. Read the documentation for details.

[SundayProgrammer]

Too bad that 48pin F103C8 does not have any DAC(s)...
(Dacs are only included in high density devices)

Axel.

[poorchava]

DACs on most STM32 chips suck. They have trouble reaching the bottom rail (minimum is like 30mV). If you enable output buffer,  then it gets completely ridiculous (like 0.3V). In general external rail to rail buffer is almost necessity...

Wys?ane z mojego HTC One M8s przy u?yciu Tapatalka

[Rolo]

I bring life back to the thread.

I've this board that I'd like to use for a small thing


but I saw it mentioned along with Arduino or Mapple and wonder if I can program it without both. I know there's the SWD pin header which supposes that I can but maybe I'm missing something.  I've got a discovery board from ST that I can, apparantly, use as a programmer for external chip. I tried but nothing good.

Some people had experience with this board ?

You could also take a look at the Maple Mini clone boards that are available all over ebay. They have the STM32F103CBT6 MCU that has 128 Kb flash, the board in your picture you has 64K. You must make the translation from the Maple pin numbers but that's easy, all the original docu about the Maple Mini is still online. Extra bonus is that these boards can be used in mbed, just select the NucleoF103RB as platform.  Flash the bin file with the ST Link V2 programmer. One thing, the nucleo MCU has more pins so keep in mind not to use them in your code for the maple mini. In mbed the USB port on the Maple Mini does not work,  I use it as 5 volt supply in this setup. The USB pins are on the header so can be used as I/O.

[old gregg]

I managed to flash the chip. I'll try to hook up some SPI dac and potentiometers in the next few days.

You could also take a look at the Maple Mini clone boards that are available all over ebay. They have the STM32F103CBT6 MCU that has 128 Kb flash, the board in your picture you has 64K

thanks I will. Right now it's more about the clock speed and processing than the memory size. By the way, is there any other ARM boards with other cortex? I can't really work with such small package (not equiped for) and these boards are better than nothing.

[Muxr]

I managed to flash the chip. I'll try to hook up some SPI dac and potentiometers in the next few days.

You could also take a look at the Maple Mini clone boards that are available all over ebay. They have the STM32F103CBT6 MCU that has 128 Kb flash, the board in your picture you has 64K

thanks I will. Right now it's more about the clock speed and processing than the memory size. By the way, is there any other ARM boards with other cortex? I can't really work with such small package (not equiped for) and these boards are better than nothing.

There are other Nucleo boards as well as Discovery ones. There is one for pretty much every model of STM32. I've been working with the F0 chips. The F030 for instance is a great tiny MCU for small projects. Less than a buck a piece.

[old gregg]

There are other Nucleo boards as well as Discovery ones. There is one for pretty much every model of STM32. I've been working with the F0 chips. The F030 for instance is a great tiny MCU for small projects. Less than a buck a piece.

yes but they're too bulky for my needs. I'll have a check on ebay.

However, yesterday I could flash the chip for the chinese board, today nothing ! grrr...

[old gregg]

Oddly enough I've just found out that the clock and data pin needed a pull down resistor in order to get connected. Since then, no issues at all. If this could useful to someone else.

[bson]

It's not how ARM does it. It's how ST, NXP,  Atmel and such do it. ARM only provides the core,  all peripherals are of particular vendor's design.

Some peripherals such as the NVIC and the SysTick timer are part of the core.  The MPU is an optional core peripheral, so when implemented and present will be the ARM supplied one.

This may seem like counting angels, but it's important to know that all M3 processors have an NVIC (which includes NMI and software-generated interrupts and traps) and SysTick and that they will always look exactly the same.

[MT]

I've done some AVR development in the past. My background is software engineering so I don't mind learning a new language or environment.

But basically I've been shopping around for an MCU to migrate to after using 8Bit AVRs. I was mainly looking for cheap MCUs in case I decide I want to mass produce one of my projects, so the price is really important.

I was shocked with how cheap these (STM32) F103s are. For instance one of my projects is a clock and I have a need for an RTC module but this STM32 comes with a built in RTC. It's actually kind of mind boggling how much more advanced and how many more features F103 packs for the same price as an AVR Atmega328.

I mean you get: 75Mhz, 32Bit arch, 64Kb Flash, 20Kb SRAM, 2x12Bit ADC, bunch of interfaces, USB2.0, 7-channel DMA

I ordered a few of these $4 boards to play with: http://www.ebay.com/itm/311156408508?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

There is an open source Arduino toolchain: https://github.com/rogerclarkmelbourne/Arduino_STM32  It's pretty experimental though.

So I guess the question I have is, what's the catch? Anyone have experience with STM32 Cortex M3 F10x controllers, are they any good? And where should I begin in terms of software tools to program these guys? (preferably OS X / Linux toolchains).

Yes they are god, ST hardware is often very god! Download EMbitz/Blocks and create a F103 project and off you go in seconds.
Pricing? Now that's the hard part. You are then way better off with newer devices then F103, my experience from Farnell, Digikey, Mouser etc. 

[Rolo]

Oddly enough I've just found out that the clock and data pin needed a pull down resistor in order to get connected. Since then, no issues at all. If this could useful to someone else.

Thanks ! I had problems to get my Nucleo F401 board to work as ST-LINK programmer to program the Maple Mini clone. Now added two 4K7 pull-down resistors and it works.

[jnz]

Yes they are god, ST hardware is often very god! Download EMbitz/Blocks and create a F103 project and off you go in seconds.
Pricing? Now that's the hard part. You are then way better off with newer devices then F103, my experience from Farnell, Digikey, Mouser etc.

Well..... I don't know if they are THAT GOOD.

I do agree, starting a new project today, it'll be based on the F0, F2, or F4 depending on the project.

[richardman]

The F1xx series is very old, so comparing with an AVR, it does not have enough cost saving advantage like the F0xx, nor the power advantage like the F4xx. I would imagine that the F0xx (and other m0 cores) will dominate the low cost market and the F4xx (and other m4 cores) will dominate the power market.

Once the Cortex-M begins to "take over" the embedded mass market, for example, when a hobbyist/engineer that only makes one, or two, or ten units of a widget, and they still choose the Cortex-M instead of PIC or AVR, then that means that they have a good set of usable tools for the Cortex-M. At that time, the F1xx will be interesting again.

[bingo600]

I do like the F103 , but mostly for the price of assembled boards fro *bay or AliExp

I can get a board for $3.50.
If it's a "genuine" ST chip , then there's 128K Flash on the die, and you just need to convince OOCD  that the 64K ID has 128K, and you're good to go.

It's my new "Plugin board".

/Bingo

[old gregg]

Thanks ! I had problems to get my Nucleo F401 board to work as ST-LINK programmer to program the Maple Mini clone. Now added two 4K7 pull-down resistors and it works.

glad it helped !

Since I installed the two resitors, no issue occured again.

talking about the 103, I'm trying to write directly into register for the init of a pin. It doesn't work, What am I missing ?

Code: [Select]


RCC->APB2ENR |= RCC_APB2ENR_IOPCEN ;
GPIOC->CRH |= GPIO_CRH_MODE15; //OUT, 50Mhz
GPIOC->BSRR |= 1<<15;

I've got the nose in it so deep that I can't figure it out....

this works:

Code: [Select]

GPIO_InitTypeDef GPIO_InitStructure;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_15;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(GPIOC, &GPIO_InitStructure);
GPIO_SetBits(GPIOC, GPIO_Pin_15); // LED2 On
Ideally, I'd like to have a look into the CRH registers to know what the bits are but I'm using coocox and I don't find a way to connect the stlink debugger.

[westfw]

Code: [Select]

GPIOC->BSRR |= 1<<15;This should just be "GPIOC = 1<<15;", but I don't see that that should stop it from working.
It looks OK to me; are you still using "proven" code to initialize the system clocks?
https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg509546/#msg509546

[old gregg]

actually I assumed that the ports were loaded at 0 for all bits at boot time, which they aren't (noted in the datasheet, they're configured as floating input). I realised that with another line I found :

  GPIOC->CRH &= ~(GPIO_CRH_MODE12 | GPIO_CRH_CNF12);

I made a test, putting 0 in CRH and CRL at boot up, and then write the register as i want it to be, it worked.

Now I'm stuck with the SPI interface which output nothing. I haven't done things with the ADC neither, this seem to be a big one !

It's always a bit of pain when you move to other processor but I hope once all those settings learned this will go more easily.

Also, I don't want to use API libraries, just for the sake of understanding.

[daybyter]

If you want to explore the ADC, I would check the 10$ oscilloscope project of the stm32duino guys. Seems like they spend quite some time on optimization.

http://www.stm32duino.com/viewtopic.php?f=19&t=107

[old gregg]

I managed to get few things working. However, I've issue trying to get the SPI transmitting data via a timer interrupt. The chip select is switching fine but no clock and data (even with low prescaler for both)

Maybe someone encouters this problem and share the info.

I haven't reach DMA yet, so maybe it is related.

[Brutte]

Seriously, man, why cannot you run through the examples provided by STM first instead of.. ok I wanted to write "wasting time" but let it be "personal quest" to save 1k of 128k available in that 2$ chip? They have put a lot of effort into these libraries and examples that come included. From my experience I can tell you that you won't be able to optimize much. Definitely you won't save on time (on writing+debugging+maintaining code) that could be spent on something "more challenging".

[Jeroen3]

You can save 10us by not using the can library provided by ST.
You can save significant seconds by not using the spi library when writing an LCD without dma.
So well, yes. It takes a day. But gets you the few extra can messages per second. As well as a faster lcd refresh. Could be subject to debate. Some people have time, some don't.

[Brutte]

(..)You can save significant seconds by not using the spi library when writing an LCD without dma.
So well, yes. It takes a day.(..)

Well, for SPI without DMA there is only one STM32F103 library function that does this job...

Code: [Select]

/**
  * @brief  Transmits a Data through the SPIx/I2Sx peripheral.
  * @param  SPIx: where x can be
  *   - 1, 2 or 3 in SPI mode
  *   - 2 or 3 in I2S mode
  * @param  Data : Data to be transmitted.
  * @retval None
  */
void SPI_I2S_SendData(SPI_TypeDef* SPIx, uint16_t Data)
{
  /* Check the parameters */
  assert_param(IS_SPI_ALL_PERIPH(SPIx));
 
  /* Write in the DR register the data to be sent */
  SPIx->DR = Data;
}

Seriously, what would you like to optimize here?
Shorter functions names?
Less doxygen or assert?

[westfw]

for SPI without DMA there is only one STM32F103 library function that does this job.

Perhaps, if you're going to use the OLD Standard Peripheral Library.  that's not recommended any more, you know.   You should now be using the STM32 CUBE HAL library, where the SPI transmit function reads:

Code: [Select]

HAL_StatusTypeDef HAL_SPI_Transmit(SPI_HandleTypeDef *hspi, uint8_t *pData, uint16_t Size, uint32_t Timeout)
{

  if(hspi->State == HAL_SPI_STATE_READY)
  {
    if((pData == NULL ) || (Size == 0))
    {
      return  HAL_ERROR;
    }

    /* Check the parameters */
    assert_param(IS_SPI_DIRECTION_2LINES_OR_1LINE(hspi->Init.Direction));

    /* Process Locked */
    __HAL_LOCK(hspi);

    /* Configure communication */
    hspi->State = HAL_SPI_STATE_BUSY_TX;
    hspi->ErrorCode   = HAL_SPI_ERROR_NONE;

    hspi->pTxBuffPtr  = pData;
    hspi->TxXferSize  = Size;
    hspi->TxXferCount = Size;

    /*Init field not used in handle to zero */
    hspi->TxISR = 0;
    hspi->RxISR = 0;
    hspi->pRxBuffPtr  = NULL;
    hspi->RxXferSize  = 0;
    hspi->RxXferCount = 0;

    /* Reset CRC Calculation */
    if(hspi->Init.CRCCalculation == SPI_CRCCALCULATION_ENABLE)
    {
      SPI_RESET_CRC(hspi);
    }

    if(hspi->Init.Direction == SPI_DIRECTION_1LINE)
    {
      /* Configure communication direction : 1Line */
      SPI_1LINE_TX(hspi);
    }

    /* Check if the SPI is already enabled */
    if((hspi->Instance->CR1 &SPI_CR1_SPE) != SPI_CR1_SPE)
    {
      /* Enable SPI peripheral */
      __HAL_SPI_ENABLE(hspi);
    }

    /* Transmit data in 8 Bit mode */
    if(hspi->Init.DataSize == SPI_DATASIZE_8BIT)
    {
      if((hspi->Init.Mode == SPI_MODE_SLAVE)|| (hspi->TxXferCount == 0x01))
      {
        hspi->Instance->DR = (*hspi->pTxBuffPtr++);
        hspi->TxXferCount--;
      }

      while(hspi->TxXferCount > 0)
      {
        /* Wait until TXE flag is set to send data */
        if(SPI_WaitOnFlagUntilTimeout(hspi, SPI_FLAG_TXE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
        }
        hspi->Instance->DR = (*hspi->pTxBuffPtr++);
        hspi->TxXferCount--;
      }
      /* Enable CRC Transmission */
      if(hspi->Init.CRCCalculation == SPI_CRCCALCULATION_ENABLE)
      {
        SET_BIT(hspi->Instance->CR1, SPI_CR1_CRCNEXT);
      }
    }
    /* Transmit data in 16 Bit mode */
    else
    {
      if((hspi->Init.Mode == SPI_MODE_SLAVE) || (hspi->TxXferCount == 0x01))
      {
        hspi->Instance->DR = *((uint16_t*)hspi->pTxBuffPtr);
        hspi->pTxBuffPtr+=2;
        hspi->TxXferCount--;
      }

      while(hspi->TxXferCount > 0)
      {
        /* Wait until TXE flag is set to send data */
        if(SPI_WaitOnFlagUntilTimeout(hspi, SPI_FLAG_TXE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
        }
        hspi->Instance->DR = *((uint16_t*)hspi->pTxBuffPtr);
        hspi->pTxBuffPtr+=2;
        hspi->TxXferCount--;
      }
      /* Enable CRC Transmission */
      if(hspi->Init.CRCCalculation == SPI_CRCCALCULATION_ENABLE)
      {
        SET_BIT(hspi->Instance->CR1, SPI_CR1_CRCNEXT);
      }
    }

    /* Wait until TXE flag is set to send data */
    if(SPI_WaitOnFlagUntilTimeout(hspi, SPI_FLAG_TXE, RESET, Timeout) != HAL_OK)
    {
      SET_BIT(hspi->ErrorCode, HAL_SPI_ERROR_FLAG);
      return HAL_TIMEOUT;
    }

    /* Wait until Busy flag is reset before disabling SPI */
    if(SPI_WaitOnFlagUntilTimeout(hspi, SPI_FLAG_BSY, SET, Timeout) != HAL_OK)
    {
      SET_BIT(hspi->ErrorCode, HAL_SPI_ERROR_FLAG);
      return HAL_TIMEOUT;
    }
 
    /* Clear OVERUN flag in 2 Lines communication mode because received is not read */
    if(hspi->Init.Direction == SPI_DIRECTION_2LINES)
    {
      __HAL_SPI_CLEAR_OVRFLAG(hspi);
    }

    hspi->State = HAL_SPI_STATE_READY;

    /* Process Unlocked */
    __HAL_UNLOCK(hspi);

    return HAL_OK;
  }
  else
  {
    return HAL_BUSY;
  }
}


[Jeroen3]

The lack of multi byte write in the first driver is more what I'm pointing at. Which is more of an application example which should be phased out slowly when the software gets more mature.

[Brutte]

Perhaps, if you're going to use the OLD Standard Peripheral Library.  that's not recommended any more, you know.

Perhaps try Standard Peripheral Library when it does the job, before diving into HAL with OS.

You should now be using the STM32 CUBE HAL library, where the SPI transmit function reads:

That comes with whole HAL layer for OS. Anyway, what would you like to optimize in this polling:

Code: [Select]

      while(hspi->TxXferCount > 0)
      {
        /* Wait until TXE flag is set to send data */
        if(SPI_WaitOnFlagUntilTimeout(hspi, SPI_FLAG_TXE, RESET, Timeout) != HAL_OK)
        {
          return HAL_TIMEOUT;
        }
        hspi->Instance->DR = (*hspi->pTxBuffPtr++);
        hspi->TxXferCount--;
      }? I cannot see a place for any improvements in terms of speed. Besides, STM32F103 SPI modules do 18Mbps max so with 16-bit data that gives at least 64 instructions for one loop. Same limit for -O0 and assembler and you won't make it faster anyway. If you want speed then use DMA (HAL provides separate API for that).
 

The lack of multi byte write in the first driver is more what I'm pointing at.

The STM peripheral library is just peripheral library. It does not make coffee, it does not play chess. If you want polling and multibyte transmission then you have to include your higher level layer above it (similar to example above). However, library comes with extensive set of examples (polling included) which are worth trying before considering the library "uselessly slow" and rewriting everything.

[gogoman]

I bring life back to the thread.

I've this board that I'd like to use for a small thing


Some people had experience with this board ?

I have the board,  it works.  can someone provides a schematic?
thanks

[HackedFridgeMagnet]

I haven't got a schematic, but really you can see just about everything from the photo.

Low speed crystal + caps, High speed crystal (no caps?), USB, programming interface, 2 x jumper inputs, momentary button and a stack of pins brought out to the edge.

[donotdespisethesnake]

I have never seen an official schematic for that board, despite much searching. The website https://vcc-gnd.world.taobao.com/ has a bunch of stuff, nothing I can find in English though. I might try asking a Chinese speaking colleague to have a look. Maybe one of the dodgy .rar files has a schematic.

There is a reverse engineered schematic here http://www.mikrocontroller.net/attachment/249868/STM32_Min_System_Dev_Board.pdf, which is probably close enough.

[Brutte]

Looks like it has a permanent 3,3V pullup on DP.
Another thing is that VDDA is short-circuited to VCC. Was it that hard to put an LC in between, Mr. Wong?
Then, there is 10u + 100n on the +5V input. That violates USB specs.
And 100n cap in parallel with pushbutton 

[asgard20032]

Looks like it has a permanent 3,3V pullup on DP.
Another thing is that VDDA is short-circuited to VCC. Was it that hard to put an LC in between, Mr. Wong?
Then, there is 10u + 100n on the +5V input. That violates USB specs.
And 100n cap in parallel with pushbutton 

Why LC? Why a 100n cap? Most of the time, when I open schematic with mcu, i see L, some C i didn't expect, and bunch of other piece. But when i look at the datasheet, for a typical/minimum/recommended design, they just put most of the time a resistor between the mcu reset and Vdd. (I am not talking about a particular mcu, but in general). Did I miss an application note, an interesting document, or a book like "How to electrically plug an mcu"? It would be interesting if someone here could guide me to the right resource to learn those subtlety or explain it here.

[newbrain]

Why LC? Why a 100n cap? Most of the time, when I open schematic with mcu, i see L, some C i didn't expect, and bunch of other piece. But when i look at the datasheet, for a typical/minimum/recommended design, they just put most of the time a resistor between the mcu reset and Vdd. (I am not talking about a particular mcu, but in general). Did I miss an application note, an interesting document, or a book like "How to electrically plug an mcu"? It would be interesting if someone here could guide me to the right resource to learn those subtlety or explain it here.

Pretty much standard practice: LC as a low pass filter to reduce noise passed from the digital side of the supply (VDD) to the analog one (VDDA), a cap across the reset pushbutton to provide a minimum of debouncing.
Example of LC (a ferrite bead, actually) in the picture, cropped from a Discovery board schematic.

[asgard20032]

Why LC and not RC? Which L to choose?

[donotdespisethesnake]

A reset switch doesn't need debouncing!

IME a lot of EEs have a rote method of design, often under the guide of "best practice", which leads to overcomplicated design and unnecessary components.

[old gregg]

I bring life back to the thread.

I've this board that I'd like to use for a small thing


Some people had experience with this board ?

I have the board,  it works.  can someone provides a schematic?
thanks

I uploaded the schematic.

[Brutte]

Why DP pullup is 4k7?? And Boot0 is just flapping in the breeze?

[Bruce Abbott]

Why DP pullup is 4k7?? And Boot0 is just flapping in the breeze?

The standard D+ pull-up value is 1.5k to +3.3V. However in this case the resistor pulls up to +5V so the value should be higher. This board does not have zener protection on D+ so 4.7k is sufficient, and since the resistor is not switched out after USB negotiation the less current it injects the better. Crude, but it works!

BOOT0 is connected through R3 to pin 44 of the STM32. The jumper sets it to GND or +3.3V.

[ea_man]

Why DP pullup is 4k7?? And Boot0 is just flapping in the breeze?

You are lucky: mine came with 10K and I had to solder a new one.
Weird thing is that now I have to use a USB HUB in order to upload, I'put a ~1.5k ohms resistor in that.

With 4.7k resistor does it work ok, enumeration and upload?

[Brutte]

The standard D+ pull-up value is 1.5k to +3.3V. However in this case the resistor pulls up to +5V so the value should be higher.

This design is a disaster. Looks like the USB spec has not been translated to Chinese yet.

BOOT0 is connected through R3 to pin 44 of the STM32. The jumper sets it to GND or +3.3V.

Ahh, now I can see that those are jumpers and select boot modes. PB2 is not routed externally.

Thanks for clarifying that.

[dannyf]

for historical reasons unknown to me became very popular in china some years ago.

It is one of the first CM3 chips that are so versatile at such a low price:

1) aside from the typical peripherals, it has DAC, lots of timers, DMA, CAN / USB, and built-in random number generator.
2) undocumented features.
3) good availability + form factor.

It is a little bit slow by today's standards but for many jobs it is fast enough.

Because of that, it is one of the very first cloned STM32F chips as well.

[MagicSmoker]

A reset switch doesn't need debouncing!

True, but the capacitor from !RESET to ground isn't for debouncing, it's for preventing spurious assertion from noise. Furthermore, a cap on reset costs very little, while the consequences of an unintended reset range from annoying to catastrophic, so there's no rational argument for leaving it off.

That said, I do agree with your general premise that most EEs seem to make things needlessly complex for the task at hand.

[donotdespisethesnake]

Yes, with hindsight (and some reading of data sheet  ) I would change that opinion - Reset is the only switch that needs a cap .

I was recently reviewing a debug board we created at work, and 95% of it's functionality I've never used, and of the 5% there were other simpler says to do it. Plus the mounting by the mechanical guy was the worst design I have ever used. All it needed was a 10 pin JTAG IDC connector, would have been fine. I gave a colleague a copy of the "what the customer wanted" cartoon, he thought it was amusing but showed no signs of getting the message!

I concede this may say more about the ill-advised over-engineering we do at our company than the state of the industry in general.

[dannyf]

the capacitor from !RESET to ground isn't for debouncing, it's for preventing spurious assertion from noise.

It is also a "power-good" indicator - to create a power-on delay.

[zapta]

What kind of bootloader does this board use?  Is it a stock preprogrammed  bootloader that comes with the MCU?

[donotdespisethesnake]

If I recall correctly, there is only the built-in STM serial bootloader.

[Jeroen3]

Most parts have bootloaders. Some only for UART, some also have CAN or USB. These are ROM bootloaders, you can always add your own through the ARM SWD interface.
Especially on these parts with their variety you should consult the manual before assuming that it will have bootloaders.

[zapta]

Most parts have bootloaders. Some only for UART, some also have CAN or USB. These are ROM bootloaders, you can always add your own through the ARM SWD interface.
Especially on these parts with their variety you should consult the manual before assuming that it will have bootloaders.

I am using an NXP Arm MCU that comes stock with a USB virtual disk bootloader. It's very handy because no software is required to upload, just file copy. Would like to try a similar one from ST if available.

[donotdespisethesnake]

I am using an NXP Arm MCU that comes stock with a USB virtual disk bootloader. It's very handy because no software is required to upload, just file copy. Would like to try a similar one from ST if available.

That is a nice feature, but I haven't seen it on any other MCUs so far - it's great for hobbyists, maybe not so useful in a commercial environment?

[neslekkim]

The nucleo's from st have it, but that is maybe custom bootloader?

[zapta]

The nucleo's from st have it, but that is maybe custom bootloader?

One important feature in those MCU boards is the ability to clone them. Not to sell competing products but for application specific custom PCBs that are based on the same MCU design. If ST provides an after market bootloader, it's still very useful.

[donotdespisethesnake]

The nucleo's from st have it, but that is maybe custom bootloader?

I think all the Nucleo boards have a secondary MCU which provides the USB disk programming method for Mbed, as well as a JTAG interface via USB (ST-LINK).  STM have not published the source code for the firmware AFAIK.

[Brutte]

The nucleo's from st have it

The nucleo st-link V2-1 USB mass storage class feature is not a bootloader but a programmer (it runs on a device that is external to the target). A bootloader is the name of the code that resides inside of the target that is being programmed.
The st-link does come with a USB bootloader (that allows upgrading st-link itself) however it is not a mass storage class.

BTW, nucleo 64 do not provide target USB receptacle.

[poorchava]

The ST-Link mass storage component contains only some advertising and propaganda. As a matter if fact I recall reading somewhere that both versions of ST-Link use some side channel in disk management protocol to talk to PC. I recall having huge problems with V1 under Win7.

I think all newer STM32s have bootloaders over USB,  UART and some other interface (SPI iirc). Not sure about F103 as it is a pretty old part. I think it has UART bootloader.

Sent from my HTC One M8s using Tapatalk.

[Bruce Abbott]

Not sure about F103 as it is a pretty old part. I think it has UART bootloader.

Yes, it has the serial bootloader. To use it you just need a TTL serial adapter and ST's Flash Loader Demonstrator. This has a command line version which can be run from a batch file.

I am using the vcc-gnd dev board that old gregg posted the schematic for. I modified the batch file in the "1 dollar 1 minute" thread so that an asm source code file can be 'drag-and-dropped' onto it. It takes less than a second to assemble, download and run a program. For debugging I use Hyperterminal. 

To make a self-contained environment for each project I put the arm assembler and flash load programs in subdirectories. I just copied over the essential files so the whole lot only takes up 4.8MB on disk.

The attachment below includes my batch file and source code for an LED blink program that works on the vcc-gnd board. The batch file is set to use COM5. If you use a different port then change the number '5' in the stmflashloader parameter '--pn 5' to the number of your com port.

[old gregg]

that's great Bruce, thank you. I'll check it out.

I should add the 2 pull resistor on the programming buss required. It won't work without if programmed via the st-link of the discovery board.

At the moment I've terrible experience with the ADC, it simply doesn't work. It enters the IRQ_handler fine but it seems that the adc pin isn't mapped to the ADC or something.

 Although my understanding goes nicely on the F4 discovery board, the Vcc-Ground board is very frustating.

[Brutte]

but it seems that the adc pin isn't mapped to the ADC or something.

I suggest that you should start with examples provided by ST instead of reinventing the wheel. Besides, all STM32F103 chips have internal temperature sensor so it could be a good starting point for verifying your theory.

And about the bootloader - the chip has USB device peripheral and ST provides DFUse.

[old gregg]

I suggest that you should start with examples provided by ST instead of reinventing the wheel. Besides, all STM32F103 chips have internal temperature sensor so it could be a good starting point for verifying your theory.

i've actually tried that as well and any of those examples worked.

[Brutte]

At the moment I've terrible experience with the ADC, it simply doesn't work (..)
i've actually tried that as well and any of those examples worked.

Sounds like a contradiction.

[old gregg]

oups...I meant none of the example worked.

the ADC OEC flag is set and working but nothing moves in the ADC data register.

[Kilrah]

And about the bootloader - the chip has USB device peripheral and ST provides DFUse.

The F1s however don't have the DFU bootloader, only F2 and up.

[Rasz]

And about the bootloader - the chip has USB device peripheral and ST provides DFUse.

The F1s however don't have the DFU bootloader, only F2 and up.

http://libopencm3.org/wiki/USB_DFU

[Brutte]

oups...I meant none of the example worked.

What have you done to that poor uC?  It is hard to blame a uC when other (last week at Nuremberg ST stated 1.6 billion of them) work as expected. Can you tell us something about your hardware design? Perhaps get some reputable f103 eval (nucleo) to run ST examples. BTW, the f103 is used in numerous USB scope designs as even smallest versions are capable of converting 2x1Msps at 12-bit resolution.

The F1s however don't have the DFU bootloader

in ROM but you can download anything to flash. Of course there is this chicken-egg problem at the beginning. Just my remark about using a USB-to-serial converter to upgrade a USB chip.

[dadler]

Is there any real reason to use these when the F410 is about the same price with better specs?

http://www.mouser.com/Search/ProductDetail.aspx?R=STM32F410RBT6virtualkey51120000virtualkey511-STM32F410RBT6

[dannyf]

In many cases costs are not the only reason or even a major reason to pick a part.

[old gregg]

What have you done to that poor uC?

you guessed it....I've fried it it seems (or at least the input).

I used a second identical one and it worked as expected. Go figure what I've done to that uC.

Is there any real reason to use these when the F410 is about the same price with better specs?

it was cheap, small enough for what I want to do with it and easy to manage for one-off project.

[Brutte]

What have you done to that poor uC?

you guessed it....I've fried it it seems (or at least the input).

I have made some remarks about STM32 IOs at the beginning of this topic. Not all IOs are 8V tolerant. However, that does not explain how come the internal temperature sensor misbehaved. Perhaps you have fried a multiplexer or ADCs..

[old gregg]

I must have coocked the input driver or something. I'll check if the logic driver still work or not. I hate Breadboard for that kind of crap... (or it may as well be the uC which was already dead on the inside ... just to pretend I'm not responsible )

[rexnanet]

I've known ST microcontrollers existed for a long time but haven't really used any.

But after getting very frustrated with a PIC32MX that didn't want to work (or failled after a few flash writes) (maybe because of cloned pickit lol) I quited! $%#$% them!

I'm also using a Stellaris Launchpad (now TIVA) to do some projects but it's a bit pricy to have a board for each project.

Then I saw that some people got F103 overclocked (up to 128M) and some other guys got it to work with arduino IDE (I'm not a big fan of arduino but it has lots of code already done...) I started to get interested.

Then I saw the price!!! 2-3€ for a board and 2-3€ for a programmer?!?! "Thats worth giving a try!"

It's fast I've managed to get SPI and I2C working with the master clock at 128Mhz and its faster than the Stellaris!
It has fewer pins but for small projects it's enough. For bigger ones I'm getting a F429 and also a F746.

There are not many ready made examples to get started but going step by step it's fairly easy to get stuff working.

[Sal Ammoniac]

It's fast I've managed to get SPI and I2C working with the master clock at 128Mhz and its faster than the Stellaris!

Do you really need the extra speed enough to risk running the part at a clock rate well above what it's specified for?

[rexnanet]

Do you really need the extra speed enough to risk running the part at a clock rate well above what it's specified for?

In this case yes

First, I'm just testing the micro to see what it's capable of.
Second, Im not making anything that has a risk involved.
Third, I'm using it to interface a SPI TFT, so more speed=more fps=nicer interface

Yes, it's a risk and it might fail but for this purpose it's not a big deal.

[TonyD]

I'm a bit late to the discussion but I'd just to say we've been using the STM32F103RB at work for the last 5-years or so, in about 30 products will in total volume of 40K+ pieces a year. We found it a fine uC and good support from ST (sorry for the flag waving). It must have something going for it if its being copied by a far-east company ;-)

[dannyf]

if its being copied by a far-east company

GD......,

I suspect many of the 103s on ebay are actually GD.

[martinayotte]

I suspect many of the 103s on ebay are actually GD.

GD are not fake/clone of STM, only that they are almost compatible.
So, pictures of board on eBay that showing STM should be STM. Boards with GD will cleary show the GD logo.

[michaeliv]

GD are not fake/clone of STM, only that they are almost compatible.
So, pictures of board on eBay that showing STM should be STM. Boards with GD will cleary show the GD logo.

Any reason to think that they are genuine other than the rock-solid trustworthiness of Chinese sellers ?
I think he was saying that the STM32 chips are re-branded GD32 chips.
Kind of like how certain op-amps & voltage references are re-marked and sold for higher prices (happened to me).
Are the GD32 / STM32 chips not 100% compatible ? Does anyone know any differences between them ?

[stmdude]

Are the GD32 / STM32 chips not 100% compatible ? Does anyone know any differences between them ?

They seem to be at least very compatible. There's no way of testing every single gate in them.

Olimex got in contact with GigaDevices, and got samples to test:
https://olimex.wordpress.com/2015/12/21/gd32f103rbt6-the-stm32-pin-to-pin-compatible-chinese-mcus-sample-test/

[dannyf]

Are the GD32 / STM32 chips not 100% compatible ?

The demo I have seen suggests that they are binary compatible. You can also use ST libraries to develop for GD32, .

From a hardware perspective, the GD has a newer core, runs faster, and has a "working" I2C module - the I2C module on F1 is not exactly flawed. Just that they are not compatible with ST library but that's more (but not a complete) an indication of ST software developers than its hardware developers.

The only known issue (that I'm aware of) is that the GD chips have a noisier ADC.

[michaeliv]

the GD has a newer core, runs faster

Do they actually run faster or is it more a case of "well we clocked it higher at 25C and it worked for us, mark it faster in the datasheet".
As in, if you clock the STM32 & GD32 at 120MHZ, the STM32 will give errors when the GD32 will not ?
Also is there a software way to tell which chip is which, like FTDI detected managed to detect non-FTDI chips? I'm asssuming that measuring ADC noise would not be that reliable.

[dannyf]

GD32(F103) runs at 108Mhz, on a r2p1 core, with WS0 flash. Whether that translates into actual faster speed all depends on what you are "running" on it: Reading from flash for example is much faster. Writing to flash is considerably slower however.

There are also some well-known differences as well.

One of the frustrations with GD32 has been the inability to tell it apart from STM32 using software alone.

[martinayotte]

Yes, GD and STM are almost compatible. One difference that I know is that PLL has more bits to provide more frequency ratios, for example, to get proper USB clock even if MCU isn't at the same frequency as STM.

BTW, for those who wish to see that the GD die isn't a clone of STM at all, here is a nice link, which also explain why the Flash is much faster on GD than STM :

http://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

[savril]

Are the GD32 / STM32 chips not 100% compatible ?

The demo I have seen suggests that they are binary compatible. You can also use ST libraries to develop for GD32, .

If I'm right, the SDK for GD32 was a carbon copy of STM32 SDK only with the ST copyrights removed (GD have changed some source files since the launch however).
There is a legal complaint from ST and that source copy seem an advantage on ST side.

Even if they can't forbid the chip as it is not a silicon copy, ST may be able to make all software developed with their SDK illegal to run on non ST chips. And so all products made with ST SDK (or GD copied one) could be marked as counterfeits...

As a hobbyist, I don't care. But if I was making a product, I would think twice before including a GD chip in my design.

[dannyf]

the SDK for GD32 was a carbon copy of STM32 SDK

Some changes to the stm libraries are needed to support the higher clock rates. Other than that, you can literally use the stm32 library to develop code for gd32.

[Rasz]

Yes, GD and STM are almost compatible. One difference that I know is that PLL has more bits to provide more frequency ratios, for example, to get proper USB clock even if MCU isn't at the same frequency as STM.

BTW, for those who wish to see that the GD die isn't a clone of STM at all, here is a nice link, which also explain why the Flash is much faster on GD than STM :

http://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

now THAT is fascinating, imagine if there was a way to use that SRAM as real ram and not serial flash buffer

[Sal Ammoniac]

Yes, GD and STM are almost compatible. One difference that I know is that PLL has more bits to provide more frequency ratios, for example, to get proper USB clock even if MCU isn't at the same frequency as STM.

BTW, for those who wish to see that the GD die isn't a clone of STM at all, here is a nice link, which also explain why the Flash is much faster on GD than STM :

http://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

now THAT is fascinating, imagine if there was a way to use that SRAM as real ram and not serial flash buffer

Yes, fascinating. If his post was a day later, I probably wouldn't have believed it and assumed it was an April Fools Day joke.

[technix]

the SDK for GD32 was a carbon copy of STM32 SDK

Some changes to the stm libraries are needed to support the higher clock rates. Other than that, you can literally use the stm32 library to develop code for gd32.

It won't be long before someone develop a LGPL-licensed replacement (like avr-libc and avr-gcc.) Then there is no control over ST on the SDK. GD will have all the intention to do that.

[martinayotte]

Simply go to stm32duino.com, there is already GD32 support.

[textshell]

The small chinese boards that are all over aliexpress and ebays as "minimal system board" are possibly made by Haoyu electronics. At least that’s what the german store watterott gives as manufacturer. They even have schematics:
http://www.haoyuelectronics.com/Attachment/STM32F103C8T6-DEV-BOARD/STM32F103C8T6-DEV-BOARD-SCH.pdf

Also if anyone wants to understand what is really needed and why for the gcc toolchain (linkerscripts, etc) i wrote a blog series about bringing up such a board[1] just using the register headers and a linaro bare-metal gcc. (questions and ideas improvements welcome too of course). Without a single line of assembler. But it might contain c++

[1] http://tty.uchuujin.de/2016/02/stm32-from-scratch-bare-minimals/

[dannyf]

I have used those boards under keil (from 3.24 to 4.x), iar (through 6.4), coide (1.x plus an old gcc), and arduino, programmed through stlink and jlink, with cmsis and stdperipheral libraries.

They are some of the easiest think to do: either copy over an existing project or click some butons under coide. 30 seconds tops will get you up and running.

They are amazing values, especially coupled with stlink clones.

[textshell]

does anyone have a recommendation what debugger adapter works well with a pure open source toolchain (i.e. gdb, maybe openocd or something else?) and JTAG and SWD?

[HackedFridgeMagnet]

stlink v2 works fine, but its the only one I've tried but I have only tried it with SWD though I think it does JTAG.

[Sal Ammoniac]

does anyone have a recommendation what debugger adapter works well with a pure open source toolchain (i.e. gdb, maybe openocd or something else?) and JTAG and SWD?

The most robust debugger I've worked with is the Segger J-Link. Works with GDB and does both JTAG and SWD. The EDU version is only $60/€48.

[Jeroen3]

Segger has an ethernet version! Slap on a small wifi router and you have wireless debugging.
But I use a uLink, got one when they dismantled the department I was an intern.

[neslekkim]

this thingy ? https://github.com/texane/stlink

[neslekkim]

The small chinese boards that are all over aliexpress and ebays as "minimal system board" are possibly made by Haoyu electronics. At least that’s what the german store watterott gives as manufacturer. They even have schematics:
http://www.haoyuelectronics.com/Attachment/STM32F103C8T6-DEV-BOARD/STM32F103C8T6-DEV-BOARD-SCH.pdf

Also if anyone wants to understand what is really needed and why for the gcc toolchain (linkerscripts, etc) i wrote a blog series about bringing up such a board[1] just using the register headers and a linaro bare-metal gcc. (questions and ideas improvements welcome too of course). Without a single line of assembler. But it might contain c++

[1] http://tty.uchuujin.de/2016/02/stm32-from-scratch-bare-minimals/

This looks cool, i bought some of those boards, but newer got around to do anything, this blogseries would help jumpstarting it.
But, what about an 0 post, prerequisites for software setup?

[dgtl]

this thingy ? https://github.com/texane/stlink

This works well, been using it on a lot of projects. My setup is:
* gcc-arm-embedded from https://launchpad.net/gcc-arm-embedded
* eclipse + cdt
* gnu arm plugin for eclipse
* texane stlink gdb server
The linker script and cpu init code can be generated using cubemx and then customized for own needs (I'm not using any st-provided hal libs, only the cpu header file).

[textshell]

Also if anyone wants to understand what is really needed and why for the gcc toolchain (linkerscripts, etc) i wrote a blog series about bringing up such a board[1] just using the register headers and a linaro bare-metal gcc. (questions and ideas improvements welcome too of course). Without a single line of assembler. But it might contain c++

[1] http://tty.uchuujin.de/2016/02/stm32-from-scratch-bare-minimals/

This looks cool, i bought some of those boards, but newer got around to do anything, this blogseries would help jumpstarting it.
But, what about an 0 post, prerequisites for software setup?

Yes, maybe i should add something more about prerequisites. For now the README.md on github (linked from every post) has the software versions i use. But it’s somewhat minimal because most of everything is just part of my OS (Debian linux). I guess on windows setup would be a bit more painful. But i think even for windows the gnu toolchain is not too complicated to get.

And as i don’t use any IDE like eclipse or anything like that, you only need stm32flash and the arm bare-metal version of the gcc toolchain.

If you have any questions, i’m happy to help.