STM32, ghetto style

[Kjelt]

Concerning cheapo ebay stm32 chips/boards, just an observation, the prices are really low for the 103s with and without boards, almost impossible to beat, the chip alone from farnell is more expensive.
But then you want to step up to lets say a 207 or 217 to do some IP stack and have some more ram.
You get a shock the cheapest listings on the same china ebay stores are now more expensive then farnell. Strange is it not?

[paulie]

Maybe it's so cheap because it's the most popular ARM in the world (scale of mfg). Maybe it's most popular because it's cheap. Either way there is no competition in it's class. About time to start showing up in the "ghetto".

[westfw]

prices are really low for the 103s

Does anyone have the historical background for this chip/board?  Usually, when some board appears on eBay from all the Chinese entrepreneurs who also sell clothing and cosmetics, it's a copy of something.  (something profitable.)  For example, there are plenty of "arduino pro micro" clones, and the DIP version of this ARM board looks like a clone of the Leaflabs "Maple mini."  Sometimes they're involved in some quasi-legal hack (rooting your video game or cable box, for example.)   But I don't recall seeing this "big JTAG connector + breakout" STM32F103 board before ...

[dannyf]

the prices are really low for the 103s

Google GD32F103C8T6. Compatible down to the binaries and works with STM standard peripheral library. Less than 80 cents each in large quantity.

I suspect EBay 103's are re-masked GD chips.

But then you want to step up to lets say a 207 or 217 to do some IP stack and have some more ram.
You get a shock the cheapest listings on the same china ebay stores are now more expensive then farnell. Strange is it not?

F2s are very / fairly rare. So high prices are not unusual.

[Kostas]

Concerning cheapo ebay stm32 chips/boards, just an observation, the prices are really low for the 103s with and without boards, almost impossible to beat, the chip alone from farnell is more expensive.
But then you want to step up to lets say a 207 or 217 to do some IP stack and have some more ram.
You get a shock the cheapest listings on the same china ebay stores are now more expensive then farnell. Strange is it not?

Surprisingly, it doesn't seem to be the case, at least for the STM32F207VCT6. It costs 7,84€ at Farnell, while Mouser sells them for 8,83€. The two Chinese sellers I found at Ebay sell them considerably cheaper and Aliexpress prices drop to below 5€, if you buy more than 1 ic. The two ebay sellers that were more expensive than Farnell were British and I have a strong suspicion that they just list whatever Farnell has and order - resell as needed.

[dannyf]

For those of us who are too cheap to spare $5 (I am one of them), there is an approach that requires zero / no (incremental) cost to program those STM32 chips: your discovery boards. They have a debugger on board and can be made as programmer for those chips.

It cannot be true ghetto without somehow having a STM32 Discovery board in the mix,

Here is a picture of a STM32VL Discovery powering and programming / debugging the STM32F030F ghetto style.

Just follow 3 simple steps below:

1) Take off jumper CN3 on the discovery board -> see the green arrow numbered "1";
2) Wire Vdd (pin 16) on the ghetto board to a 3.3v pin on the Discovery Board, and wire Vss (pin 15) on the ghetto board to one of the GND pins on the Discovery Board. BOOT0 on the ghetto board is already wired to the Vss (pin 15) on the ghetto board -> see the green arrow numbered "2";
3) Wire SWCLK (pin 20) on the ghetto board to SWCLK (pin 2) of CN2 on the Discovery Board. Wire SWDIO (pin 19) on the ghetto board to SWDIO (pin 4) of CN2 on the Discovery Board -> see the green arrow number "3".

Now, sit back and relax - you are all done. The Discovery board is now a ST-Link (v1) to the ghetto board. Full programming / debugging capabilities available.

Without resorting to iap, you cannot get any more ghetto than this,

[dannyf]

This basic approach can be used to other STM32 Discovery Boards -> most discovery boards follow the same layout / jumper set-up.

Most of those boards are very inexpensive and you probably already have them laying around. So zero incremental costs.

[dannyf]

The assembly file is coded in the most primitive way, on purpose - you will see lots of repetitions there.

You can easily replace those with macros or functions once you get up to speed. But for a minimalist approach, it works.

[paulie]

LOL

[Kjelt]

Surprisingly, it doesn't seem to be the case, at least for the STM32F207VCT6. It costs 7,84€ at Farnell, while Mouser sells them for 8,83€. The two Chinese sellers I found at Ebay sell them considerably cheaper

Well then you have a different ebay search results than I do, I came up with only one supplier for around $11 incl shipping 
To give you an idea, if you order a couple of thousand these will cost you around $2 - $3 each.

[dannyf]

for around $11 incl shipping

No clones for the STM32F2 chips, yet: the GD32 chips are F1 chips at this point.

[dannyf]

If sometimes it is desirable to use blocking transmission routines, it can be done this way:

Code: [Select]

  usart1_init(MYBAUD_RATE); //initialize the module

  while (1) {
    while (usart1_busy()) continue; //wait for the prior transmission to end
    usart1_puts(my_string);  //load up the string to be transmitted
    //while (usart1_busy()) continue; //wait for the current transmission to end.

The while state can be placed before or after the usart1_puts(). Putting it before usart1_puts() makes the transmission more efficient - you load up the string to be sent and the mcu can go do other things while the transmission is in progress.

Putting the while statement after usart1_puts() ensures that the uart module is always available when you need it.

[dannyf]

The set of usart routines utilizes usart1. But it can be modified, with minimum changes, to run on usart2 or usart3.

If you were to do that, it is best to split this into a .c/.h file so those pieces can be reused on other projects.

[dannyf]

The code is fairly straight forward. With probably one exception:

Code: [Select]

//in the ISR:
if (*_UxTX_ptr) { //0 indicates the end of the string - send null at the end
//if (*(_UxTX_ptr+1)) { //0 indicates the end of the string - don't send null at the end

As structured, the routine will send the null character at the end of a C-string. I find this useful as a way to frame a transmission.

Sometimes you don't want to send the null character - it would mess up copy-and-paste for example.

Alternatively, you can uncomment the next line, which, if activated, will NOT send the null character.

However, that means you cannot send an empty string -> ie, the first character of a string to be transmitted cannot be null.

Hope it helps.

[dannyf]

Here is one of the largest projects I have ever compiled.

ucos2 + emwin on an old keil uvision. Pictured at O0 but minimum changes at O3. Unused code already trimmed.

It is amazing what those little things can do.

And how broad the range of application is, from the ghetto chips to the CM4 (this one).

[dannyf]

F103C8s definitely have more than 64KB of flash -> they are actually CBs?

STM32F103C8 is spec'd to have 64K flash.

Reading the flash size register @ 0x1fff f7e0 shows 0x0040 -> 64K. All is good.

[dannyf]

Write 0x12345678 to flash offset 0xf000 (just shy of 64K):

all is good.

[dannyf]

"wiring?"

I used a ghetto board -> point to point connection on hook-up wires for the test STM32F103(C8). The programmer is a clone ST-link v2.

Ghetto Board              ST-link v2
=========================
BOOT0                        GND
VDD                            3.3v
GND                            GND
SWCLK                        SWCLK
SWDIO                        SWDIO


If you use a F103 board with jtag, you can use jlink on the jtag or wire the st-link v2 pins to their corresponding jtag pins -> BOOT0 is already grounded.

The only question there is if your F103 board is externally powered. If it is, do NOT connect the 3.3v line; Otherwise, you connect the 3.3v line and the st-link can power the F103 board.

I can post a picture later if that helps.

[paulie]

Aha... so looks like we finally move out of the ghetto and into the burbs. Inevitable I suppose because that crippled STM8/FO stuff was getting old. At last dannyf figures out (with a little help) where ARM is really at. Except that decrepit JTAG baloney. So looks like the 103 stuff finally came in. Better late than never. I for one would love to see some pics.

[Koepi]

I checked how the tiny STM32F030 fares with its power supply, putting the probe between GND and VDDA on the soldered DIP pins. I use a small usb-2-serial adapter which also feeds the board with power. It has a small LDO aboard which spits out ~3.3V, up to ~150mA load.


I had to decal the scope (as I didn't know about "AC" when testing yesterday ) to see something, thus the amplitude looks less than it really is. Even with full proper decoupling (100nf+10µF VDD, 10nF+1µF VDDA+ferrite bead) according to the data sheet, there is a ripple of ~40mV. You can see the pseudo PWM for LED dimming quite clear in the scope.

Therefore the nearly stable readings from the ADC are quite amazing.

When trying to even that out with an additional 470µF electrolyte capacitor on GND+VDD, the "jumps" become waves. And then the ADC is getting instable, jumping around +-1 ADC value for each measurement.

I wonder how the ghetto version looks on the scope. Maybe later on I will solder a naked board, unfortunately my time is too limited to do that right away.

[dannyf]

I wonder how the ghetto version looks on the scope.

Roughly in the same neighborhood.

Here is the STM32F030F ghetto board blinking an led randomly (using adc). The led is wired across two pins, without a resistor -> on current of roughly 17-20ma. No supply decoupling at all. Powered by a st link v2 clone.

The chip itself runs at 8Mhz.

The scope is ac coupled. You see the baseline ripple caused by the mcu itself, and on top of it, the randomly little bumps when the led is turned on. The ripple caused by the led is less than 1 div but more than half a div -> 10 - 20mv.

ADC fluctuates 20 - 30 digits.

[Koepi]

Thank you for the graph!

Well, that looks a whole lot different, the decoupling is really effective then on my board - only the jumps from the current draw of the LED are visible.
My LED is sitting there ghetto-style as well, no series resistor. Thus it should take 20mA, give or take a few mA.

Maybe that is really enough, the supply has to be somewhat stable, it only mustn't jump around in very small time-slices for proper IC function.

[dannyf]

I had tried to put a 10ohm serial resistor in the supply line -> causing 200mv of ripple. I couldn't program the chip with the serial resistor in but it otherwise runs just fine,

As long as you don't do analog stuff, I think the ripple requirement is fairly low.

[dannyf]

Here is a shot of the supply ripple with a 0.1uf capacitor attached.

It basically eliminated the 8Mhz baseline you saw earlier. With that gone, the rippled cause by the led is super-evident.

[Koepi]

Hehe - yes, that's what I'd expect from missing decoupling: Weird effects where you wouldn't expect them, like not being able to flash the µC.  I'm getting closer to understand this thing a bit better:

http://youtu.be/1NuCtXfbq4U

Found the opportunity to build up the scope again, this time with AC coupling. Now I can perfectly monitor the power supply. I had a 100 Ohms resistor flying around, so I added it to the LED. What I can see now is a ripple of around 1mV, which seems to be quite ok or even good. And a slow voltage drop of ~12mV from the LED. That slow voltage drop doesn't seem to cause any issues with the µC's periphery, while short time ripple itself has possibly weird results, depending on the earth ray angle

Thanks for the direkt comparison with and without a 100nF capacitor; this shows the big effect in practice, in a realistic scenario!