STM32, ghetto style

[Koepi]

I keep looking around for other ways to get power to the µC as well. I even thought about the most ghetto variant - a Joule Thief But that is way too inefficient and wouldn't deliver stable output for higher loads like for example 100mA.

I was looking into charge pumps as well, but those are quite expensive ...

Cheapest offers I could find for the  LT1073:
http://www.aliexpress.com/item/32214105960.html
http://www.aliexpress.com/item/LT1073/2011254186.html

just like the TPS60302 charge pumps:
http://www.aliexpress.com/item/1798864746.html

They share the little possible load of about <=20mA, though.

[Kjelt]

Cheapest offers I could find for the  LT1073:
http://www.aliexpress.com/item/LT1073/2011254186.html

I would not trust such an offer. An ic that regularly would cost $4 /100 pcs now for $1  that smells..... Could be excess stock but I had my share with fake chips.

[dannyf]

100ma would need a real amps. Converters like lt1073 are only useful for low power applications, unfortunately.

[dannyf]

Nothing new but in case you are wondering, you can indeed download stm8s003 binaries into stm8s103 and run flawlessly, or download stm8s103 binaries into stm8s003 and run flawlessly.

That's useful because at this moment, stm8s103f3 is actually cheaper than stm8s003f3 - the two chips are identical except for a couple minor differences in spec (no differences in the actual chips that I have examined).

[Koepi]

Great observation! I would expect that a .hex works for the the same family of µCs (like stm32f103<xxx>, stm32f407<xxx>), but depends of course on the peripherals feature set. Should try some more variants like F030->F051; that's where I think problems could arise (at least if you use a binary for the bigger µC on the smaller one). For the ARM based µCs, ST has an AppNote (AN3364) which explains the compatibility a bit: http://www.st.com/web/en/resource/technical/document/application_note/DM00024853.pdf

Good news here as well, TI shipped some ICs on monday which are already close to my place now and should arrive today
Monday: 11:45 am   Picked up      GRAND FORKS, ND
Tuesday: 5:24 am   Departed FedEx location      MEMPHIS, TN
8:08 pm   Arrived at FedEx location      ROISSY CHARLES DE GAULLE CEDEX FR
9:33 pm   International shipment release - Import      COLOGNE DE
Wednesday: 4:05 am   Arrived at FedEx location      HANNOVER DE
... which is ~100km from here and thus should get delivered soon.

These parts are in the envelope:
TPS60302 - Single-Cell to 3.0V/3.3V, 20mA Dual Output, High Efficiency Charge Pump
TPS60200 - Regulated 3.3-V Low Ripple Charge Pump With Low Battery Indicator
TPS61097A-33 - 0.9Vin, 3.3Vout Boost Converter with Bypass Switch - 5nA Shutdown Current
TLV61225 - Single Cell High Efficient Step-Up Converter in 6 pin SC-70 Package

I think they are a good choice to also compare different technologies for buck and/or boost.

[dannyf]

Within the S-series, binary compatability should be very good - they use the same header file so register locations must be the same.

There are, however, two L families, L10x and L15x, I think.

F030->F051; that's where I think problems could arise (at least if you use a binary for the bigger µC on the smaller one).

They should be identical (other than the perpherals) - the same header file is used for those chips.

On the TI parts, look like they have done a good job sending them to you. Charge pumps tend to be more efficient but not as capable current-wise as a real dc/dc converter.

[Koepi]

Built up a step-up from TI now - man, it's so tiny! Especially with the Murata coil/inductor; only half the size of my NCP1402 board!
Tested it with the STM32F030 in SoftPWM LED dimming. I replaced the 400mA fuse with a new one in the multimeter and had the issue that the board won't start up in the 400mA fuse mode; it does in the 10A mode with less precision in the measurement though. It is more efficient as it doesn't use a wrong diode like my NCP-pcb.
The huge no-load-current is alarming, seems something is wrong there; the input voltage of 1.25V from the battery drops to 0.7-0.9V when using the 400mA-fuse; with the 10A fuse, no load can be measured. (This seems correct. When using a 500mA fuse, the drain goes up to 160mA and the capacitors start whining with high frequency. Must be part of this circuit/IC that it can't be measured this way. Might be some voltage drop over a diode, for example. 0.3-0.5V sound like that.)

V_in was 1,25V from the alcaline battery.

Step-up	Vout	mAin	mAout	NoLoad µA	mWin	mWout	Eff %
NCP1402	3.32	75	16	18.5	93.75	53.12	56.66
(1N4148)	3.32	100	25	18.5	125.00	83.00	66.40
TPS61097A-33	3.28	58	16	~0mA	72.50	52.48	72.39
	3.28	85	25	~0mA	106.25	82.00	77.18

For comparison, the LDO-table again:
V_in was 3,901V from the LiIon battery.

LDO	Vout	mAin	mAout	NoLoad µA	mWin	mWout	Eff %
MCP1700	3.283	1.89	1.88	1.3	7,37	6,17	83,71
PAM3101	3.303	1.96	1.88	57.6	7,65	6,21	81,21
MCP1825S	3.334	1.97	1.93	44.0	7,68	6,43	83,73
RT9166	3.260	1.87	1.86	6.1	7,29	6,06	83,12

As comparison, using the battery directly to feed the clock results in a 2.41mA load, which are 9,40mW. It is more efficient to use a LDO as the 7-segment drains less current with less voltage supplied.

[dannyf]

I read it to mean two things:

1) under comparable load (the same Iout), the TI charge pump is more efficient than the ON semi dc/dc converter - no surprise there;
2) between the smps regulators and the ldos (under different but light load conditions, however), the ldos are more efficient than smps - no surprise there too.

The most efficient way would be to go ldo-less - when you need a reference, use the onboard Vref generator or external Vref.

[Koepi]

Oh, that was a classic "step up" above. Yesterday evening I built a charge pump, finally. Since they are MSOP10 they are quite hard to handle without adapter board. Which is why I deliver measurements now, I had to fix the connections again and finally managed to get it running a few moments ago.


V_in was 1,25V from the alkaline battery.

Charge pump	Vout	mAin	mAout	NoLoad µA	mWin	mWout	Eff %
TPS60302	3.35	71	17	33	88.75	56.93	64.15
	3.35	92	24	33	115.00	80.38	69,89

Since those 24mA out are already beyond the load recommended in the datasheet, the efficiency looks bad in this example. In real-world it should work a bit better. 20mA is very little load, though.

[dannyf]

That's tiny. Your soldering skills are infinitely better than mine.

[dannyf]

I am not reverting to an old version of EWSTM8 that supports only STM8S103F to develop code for STM8S003F. No problem whatsoever in debugging and execution.

[Koepi]

Too bad the STM8 support is so Windows centric. I have three nice STM8 boards around, but fail to get a guide to setup Eclipse/SDCC (which supports STM8 - allegedly) on Mac. Which is my usual work space now. If that support would be better I'm sure it would be easy to hype and use STM8 more.

[dannyf]

So true.

The future is STM8 is uncertain, given the CM0/CM0+ competition.

[dannyf]

fail to get a guide to setup Eclipse/SDCC (which supports STM8 - allegedly)

I can confirm that SDCC does indeed support STM8S, with some modifications to the header / source files. I could get it to compile (my code + st's library) and link to produce a .hex file.

Two issues:

1) the compile time is horrendous: stm8s_tim1.c for example takes 30 - 60 seconds to compile. That's like forever;
2) more importantly, the produced code is huge: a simple blinky yields a .hex file of almost 60k. Maybe there is a switch to trim unused code sections.

This is for SDCC + CB.

[Koepi]

Thanks for testing that, dannyf! Also for verifying that it really works.

Did you see
http://sdcc.sourceforge.net/mediawiki/index.php/Stm8_code_size ?
As compiler options, setting
--opt-code-size --max-allocs-per-node 10000000

should shrink the binary significantly.

[dannyf]

I already had the code size flagged but adding the 2nd flag made no difference.

The code size comparison quoted is both fair and unfair.

It is fair in that it is an accurate description of how each compiler translated a piece of C code into executable.

It is unfair in that that's not how most people code: we often have large number of modules in a few files. You would include those modules in your project but you may not use every function in every module included. Instead, you rely on the compiler / linker to not link in the unused modules, significantly shrinking the size of the executable.

SDCC does not have the ability to trim unused code - stunning in this time and age, if you ask me. So the only solution is for you to only include those functions in your project.

Or use really really big chips to contain the code that you don't use,

[true]

SDCC does not have the ability to trim unused code - stunning in this time and age, if you ask me. So the only solution is for you to only include those functions in your project.

Yes, this is a serious omission of the linker. Compiler quality is sub-par but usable but the linker is just terrible.

There are some workarounds of putting common code into libraries but it's really a total PITA. This optimization is something any modern linker (especially one for small platforms like SDCC) should be taking care of already.

[westfw]

Code: [Select]

        RCC_DeInit(); //reset rcc
RCC_PLLCmd(DISABLE); //disable PLL
RCC_HSICmd(ENABLE); //enable hsi;
RCC_HCLKConfig(RCC_SYSCLK_Div1); //set sysclk divider
RCC_PLLConfig(RCC_CFGR_PLLSRC_HSI_Div2, RCC_PLLMul_12); //configure pll / divider. _x=[2..16]
RCC_PLLCmd(ENABLE); //enable pll
while (RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET) continue; //wait for pll to be ready
RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); //set pll as sysclk
while (RCC_GetSYSCLKSource() != RCC_CFGR_SWS_PLL/*0x08*/) continue; //wait for PLL to be ready

SystemCoreClockUpdate();

This is the sort of vendor library code that I really dislike.   All that to set up the clock; a feature that most programmers really don't care that much about at the detailed level.  You should be able to say "my crystal is xxx and I want the cpu to run at yyy", and there should be a function that goes off and DOES that without worrying about PLL inputs and multipliers and such.  And it should generate pretty minimal code; not dragging in a lot of libraries.
So I wrote such a function:  SimpleClockInit(long desiredcpuspeed, long xtalspeed), in the way I think such functions should be written.  It's verbose, but inline.  If given a reasonable compiler and constant arguments, it optimizes to relatively minimal code.  It generates information useful for debugging its own operation.

For example, here's the code that it generates if you tell it you want 8MHz with no crystal:

Code: [Select]

00000000 <main>:
   0: e7fe      b.n 0 <main>
   2: bf00      nop(you're right; there is nothing there.  Because operation off of the 8MHz internal clock is the default state.)

Here's the more inclusive code for getting 72MHz from an 8MHz crystal:

Code: [Select]

Crystal: 8000000, Desired: 72000000

00000000 <main>:
   0: bf00      nop

00000002 <PICK_HSE>:
   2: bf00      nop

00000004 <HSE_ON>:
   4: 4b12      ldr r3, [pc, #72] ; (50 <Clock_done+0x2>)
   6: 681a      ldr r2, [r3, #0]
   8: 4619      mov r1, r3
   a: f442 3280 orr.w r2, r2, #65536 ; 0x10000
   e: 601a      str r2, [r3, #0]
  10: 680a      ldr r2, [r1, #0]
  12: 4b0f      ldr r3, [pc, #60] ; (50 <Clock_done+0x2>)
  14: 0390      lsls r0, r2, #14
  16: d5fb      bpl.n 10 <HSE_ON+0xc>

00000018 <Latency2>:
  18: 4a0e      ldr r2, [pc, #56] ; (54 <Clock_done+0x6>)
  1a: 6811      ldr r1, [r2, #0]
  1c: f041 0102 orr.w r1, r1, #2
  20: 6011      str r1, [r2, #0]
  22: 685a      ldr r2, [r3, #4]
  24: f442 6280 orr.w r2, r2, #1024 ; 0x400
  28: 605a      str r2, [r3, #4]

0000002a <PLL_9>:
  2a: 685a      ldr r2, [r3, #4]
  2c: f442 12e8 orr.w r2, r2, #1900544 ; 0x1d0000
  30: f042 0202 orr.w r2, r2, #2
  34: 605a      str r2, [r3, #4]

00000036 <PLL_CR>:
  36: 681a      ldr r2, [r3, #0]
  38: f042 7280 orr.w r2, r2, #16777216 ; 0x1000000
  3c: 601a      str r2, [r3, #0]

0000003e <PLL_SPIN>:
  3e: 6819      ldr r1, [r3, #0]
  40: 4a03      ldr r2, [pc, #12] ; (50 <Clock_done+0x2>)
  42: 0189      lsls r1, r1, #6
  44: d5fb      bpl.n 3e <PLL_SPIN>

00000046 <USE_PLL>:
  46: 6853      ldr r3, [r2, #4]
  48: f043 0302 orr.w r3, r3, #2
  4c: 6053      str r3, [r2, #4]

0000004e <Clock_done>:
  4e: e7fe      b.n 4e <Clock_done>
  50: 40021000 .word 0x40021000
  54: 40022000 .word 0x40022000(The nop's are for testing purposes, so that the generated labels actually show up in the disassembly.)

(detailed study will reveal that the compiler is NOT doing a great job of optimization (at least, it looks that way.)  There are constants being unnecessarily being re-loaded into registers, inside of loops, for example.  But it's a lot less code than using the ST peripheral library...)

[Kjelt]

This is the sort of vendor library code that I really dislike.

Well AFAIAC this maps directly on the datasheet/ ref. manual and allows all the flexibility that may be required by a user, such as dynamic clock alterations for some functions, PLL changes etc.
It also easily allows you to write higher level functions (as you did demonstrate) so to say put another abstraction layer on top of it.
I don,t see the harm. It supports both ways, if they only would have supplied the higher abstraction level functions than a lot more people would be dissatisfied i think.

[Kjelt]

@Koepi : great job! I do see the normal smps efficiencies of around 80+% as expected but what would it take to get to 90%?
Higher switching frequencies?

[dannyf]

This optimization is something any modern linker (especially one for small platforms like SDCC) should be taking care of already.

Agreed. It basically renders the compiler not usable for small devices.

[dannyf]

It basically renders the compiler not usable for small devices.

Having said that, this thing does work (at least in blinking an led).

I can write a step-by-step tutorial if anyone is interested.

[paulie]

I would definitely like to see what you can come up with. Maybe another 21 step GUI procedure like the one earlier in this thread. For those who want to avoid some fuss here's a more streamlined approach:

https://www.eevblog.com/forum/microcontrollers/one-dollar-one-minute-arm-development/msg506113/?topicseen#msg506113

Unzip and hit 'a'. Notice as usual the entire compiler and programming tools have been attached to the thread and not just linked. However I do think there might be something wrong if your setup takes 60 sec to compile. For me a timer1 demo takes only a fraction of a second to produce hex and maybe another sec to flash the chip. Of course that's CLI which is not very popular with the mainstream community.

It's true this compiler does not hold a candle up to commercial deals like IAR or Keil or even GCC which has had hundreds of top experts working on it for many years. If you review the history it's basically a one man show and fairly recent effort. It's more like comparing Turbo-c with MS Visual and C# compilers. In fact SDCC feels and performs very similar to that old Borland standby. I really like Turbo-C for PC programming and SDCC is one of my favorite MCU utilities.

BTW thanks again for bringing these great chips to my attention and, even if nobody else seems to appreciate these STM8 parts, I personally would be very interested to see what you can come up with for another tutorial.

[dannyf]

I think those 003s are actually 103s marked down.

I can confirm that 003 binaries can be flashed to 103s and run flawlessly; and 103 binaries can be flashed to 003s and run flawlessly.

[Koepi]

I ordered PCBs for STM32F030 boards from JM Electron and they arrived today. My solder iron tip from the new soldering and hot fan station is a bit big compared to my previous Ersa tip, so it was a bit complicated to build it up. (I ordered a set of different tips and some smaller ones now.)

What is different to the ghetto style version? Well, it has a mini USB plug for feeding it directly with power. A LDO (XC6202) delivers the needed 3.3V, up to 200mA. A reset switch is prepared, a power LED and a user LED which can be disconnected from PA1 via jumper; also a Boot0-jumper is on there. UART and SWD have additional pins so periphery can stay plugged in while uploading a new firmware. Useful are two additional GND, 5V and 3.3V pins. Also, an external oscillator can be soldered in.

But all in all it isn't far better then our ghetto style version. At least for my taste.

(Yes, I know - I didn't think while soldering the pin headers, so the UART/SWD pin headers are on the bottom, too They belong to the top for better accessability.)

Edit: Jeez. Just took a closer look at the XC6202 datasheet. It needs 1µF capacitors, those are placed directly left and right from the IC (which is very close and the good part of the design). Replaced them now with correct capacitors. Vdda is not filtered with a ferrite bead, but has a 0R bridge. Will replace it with a ferrite, too. The BOM from the PCB is a bit of a mess. Room for improvements at least!