Dev board fail. STM32L4xx what's the point?

[paulca]

I had a STM32L432KC Nucleo32 dev board without a purpose, so I put it to use writing an advent calendar style gizmo for my daughter with a "sleeps till santa" and maybe a snow globle effect and a few xmas card style pics on SD card.

It was just as I got the external RTC working and decided to make it a little more efficient and sent it into sleep with WFI active.  Powered the LED when it woke and powered it down when it went to sleep.  3ms every 1 seconds.  Not bad.

So I connected the board to a little USB power meter.  It was pulling 50mA and 51mA when active.

So, the question comes.... why bother making a dev/eval board for an "ultra low power MCU" and put it onto a dev board where the STM32F103 ST-Link programmer and associated circuitry, power LEDs and others is pulling 50mA!  It's like 1000 times the power levels you would want to be measuring from this little thing.

For example.  It has an internal RTC and a power mode which runs nothing but the low speed clock for the RTC and only wakes in ultra low power mode from selected interrupt pins (or other PWR related ints).  It doesn't, therefore, have a VBAT pin.  It expects you to be running it from the battery already and just use the ultra low power modes.  But again.  There is no way I can see to test this on the dev board.

So, external CR2030 backed RTC is required and USB power.  I would have liked to run the MCU off a battery with a USB 5VIn monitor, such that when the power is pulled it drops into ULP mode until it's restored.  If I do that with the dev board it will flatten the battery in an hour.

[betocool]

I see your point.

On the other hand, it's just a dev board, and it allows you to test things before you commit to a design. There must also be a cost saving exercise, all STM32 dev board, oh well.. Nucleos and such, are pretty much the same hardware with different micro.

I guess the idea for the dev board is to test if sleep and wake up things work before you commit to hardware. In that regard I've used several dev kits with wires all over the place and then ported the firmware to different hardware with little changes.

I also once bought a dev kit only to realise later on that it didn't have a VBAT input, shoving my well laid plan up my well laid... where the sun don't shine.

Cheers,

Alberto

[langwadt]

sure there isn't some solder jumpers to disconnect the usb supply and st-link and power the mcu from the 3V3 pin?

[dietert1]

The nucleo module supports measuring the processor supply current IDD. There is a jumper JP1, where you can put a 1 Ohm shunt and then measure.
Usually i could adapt the nucleo boards to my needs and i think it should be possible to run the MCU without STLINK.
Once you are ready with development there are provisions to feed the MCU from another source, not USB. For example VIN. It's a bit of work, though. One needs to separate SB2 (STLK_RX), SB3 (STLK TX), SB4 (MCO) and SB17 (MCO). I am currently looking at schematic MB1180.pdf. Then disconnect the power LED LD2 (remove R22). And the F103 needs to be off, maybe SB1 is enough, maybe also disconnect D2.


Regards, Dieter

[boB]

Was the WiFi active when you measured 51mA ?

That alone may explain it.

boB

[Alti]

So, the question comes....

This is their idea of making a fast step from concept to prototype.
That is why boards are generic, span many families of low pin count chips.
As mentioned, it might require some non-obvious solder bridge tweaks but I find those boards quite flexible.

ST made STM32L-Discovery some time ago (Dave made a review of that board, with LCD controller) so you might get an inspiration from there.

[paulca]

Good point there is a micro jumper on the bottom.  There are also some solder links.  I'm sure if I RTFM I'd find a whole section on disconnecting the STM-Link and powering the chip alone from 3.3V.

I could just buy a chip and put it on a breadboard adapter and see.  (Asides, I have moved to bare ESP32 modules for similar reasons, got a spring clip programmer harness for it.  I get all the GPIO pins then.)  They are cheaper too! 

It's not a worry, it was just an idea, I already have the DS3231 module and this is a throw away project that isn't going beyond the world of du-pont wires and a 3D printed box.

The only thing I like about the nucleo boards over others, is that they have the multi-enumerating USB devices which provide the STLink and a useful USB Debug UART.  Yes, you can do that yourself the the USB_Device firmware on a BlackPill or the BluePill if you fix it, but it's just less convenient, than it's just being there.  For that reason, my go to STM is the Nucleo64-F411RE.  I've been tempted by an H7 dev board, but prices and availability are rubbish at the minute.  The H7 is tempting if I get fed up with the ESP32 and audio processing.

[tabemann]

Was the WiFi active when you measured 51mA ?

That alone may explain it.

boB

STM32L4xx dev boards like my STM32L476 normally do not come with WiFi - rather the OP is referring to the WFI instruction, which puts the MCU core into a wait-for-interrupt state where it uses less power than normal until it is woken up by an interrupt.

I should note that STM32L4xx dev boards are designed to be used for testing code during development and not as practical low-power designs; for that you will need to manufacture your own board using an STM32L4xx MCU.

Note that unless one really wants low power, STM32L4xx MCU's are a pain to work with compared to other STM32 MCU's such as STM32F4xx or STM32F7xx MCU's; I learned this the hard way when targeting the STM32L476 for zeptoforth (compared to targeting the STM32F407, STM32F411, or the STM32F746).

[langwadt]

Was the WiFi active when you measured 51mA ?

That alone may explain it.

boB

STM32L4xx dev boards like my STM32L476 normally do not come with WiFi - rather the OP is referring to the WFI instruction, which puts the MCU core into a wait-for-interrupt state where it uses less power than normal until it is woken up by an interrupt.

I should note that STM32L4xx dev boards are designed to be used for testing code during development and not as practical low-power designs; for that you will need to manufacture your own board using an STM32L4xx MCU.

Note that unless one really wants low power, STM32L4xx MCU's are a pain to work with compared to other STM32 MCU's such as STM32F4xx or STM32F7xx MCU's; I learned this the hard way when targeting the STM32L476 for zeptoforth (compared to targeting the STM32F407, STM32F411, or the STM32F746).

what was the issues?

[tabemann]

what was the issues?

The problems I have had with the STM32L476 are that its flash controller requires flash to be written in 16-byte blocks, which is inconvenient for a Forth compiler that compiles code incrementally, and that just everything has to be done differently from the STM32F407, STM32F411, and the STM32F746, and often in a more complicated fashion, meaning that whenever I reimplement code that uses peripherals on those three MCU's for the STM32L476 I have to do significant amounts of rework. Additionally, it takes significant amounts of effort to take advantage of the low power features of the STM32L476, such that I have not even bothered. In the end, as I have not heard of anyone else really using the STM32L476 in practice, unlike the STM32F407, the STM32F411, or the STM32F746, I might discontinue support in the future.

[SiliconWizard]

I have used the STM32L4 series almost exclusively here as far as STM32 is concerned. The low-power features are not any more difficult to use than any other low-power MCU and you can get *very* low average power consumption when done right. But even the consumption in full active mode is very low compared to the F4 series, or to many other Cortex-M4 MCUs.

Now you seem to be in a relatively small "niche" of Forth-based stuff, so maybe this isn't adapted to your needs and that's life. I don't know if there is that much demand for very low-power devices controlled by Forth anyway, but I do not know this niche that well, so I may be wrong.

But the L4 series is definitely great. It is what drew me to the STM32 MCUs in the first place.

[tabemann]

I have used the STM32L4 series almost exclusively here as far as STM32 is concerned. The low-power features are not any more difficult to use than any other low-power MCU and you can get *very* low average power consumption when done right. But even the consumption in full active mode is very low compared to the F4 series, or to many other Cortex-M4 MCUs.

Now you seem to be in a relatively small "niche" of Forth-based stuff, so maybe this isn't adapted to your needs and that's life. I don't know if there is that much demand for very low-power devices controlled by Forth anyway, but I do not know this niche that well, so I may be wrong.

But the L4 series is definitely great. It is what drew me to the STM32 MCUs in the first place.

Part of it is that I am supporting multiple MCU's simultaneously, so any inconsistencies between different platforms means more effort to support them. If there were demand for STM32L4xx support I might take the time to optimize zeptoforth for STM32L4xx low power operation, but I have seen little demand for it. Of course, the RP2040 is also very different from the STM32F4xx and STM32F7xx MCU's as well, but I have seen much more demand for it from my potential userbase, so it's been more worthwhile to accommodate it despite its idiosyncrasies.

[SiliconWizard]

That is understandable, and while I find the L4 series great for my applications, I reckon it's probably a lot less popular than the F4 and F7 series, so you're probably not losing much by not supporting it indeed.

[paulca]

From a beginner they are quite a bit more complicated. 

When you configure the board in MX all the peripherals have about twice as many options, most of which related to added features which allow those peripherals to only use the minimum amount of power to do what you need and no more.

It's also a lot more picky about it's clocks and clock setup.  I think the first time I used it I went straight for 80Mhz.  HSE+PLL.  It hard faulted on boot.  I can't recall what it was actually upset about, I shifted some clock multipliers around, broke the config and hit "Resolve issues" and it came back with an 80Mhz clock that actually worked.  Normally the F4s I have don't care and only get picky when you want a 48Mhz USB clock as well.  It's amusing watching their clock resolution thing trying to work that one out.

I get the idea with it.  You can control so many different features of the chip to reduce power.  Instead of the age old external RTC running on a coin cell and a completely inert MCU, you just power the MCU down bit by bit until it's only pulling as much or less than the RTC would.

Further as covered in a scenario in the datasheets and application notes, it is intended to be able to wake on a "low power" interrupt in a low enough power state to run off a capacitor long enough to take care of things before the caps are dead.

That takes care of the issue with "wake on RTC" stuff.  Normally the MCU goes straight to full boost more and straight to 100% clock and all peripherals on.  The Lxxx can brought down to a very, very low, barely on, 2Mhz mode which draws about 150uA, then put to sleep.  Such that when an interrupt wakes it, it barely cracks open one eye, decides it's not important and goes back to sleep without really waking up at all. 

I believe they fully intend to run these in 100% battery power devices and have pretty long battery life.

The fact my project is running off USB power with a screen which itself draw 100mA makes probably not the right use case for this MCU.  I considered making it 18650 powered and USB charged, which might bring out the features of the L432, but with it being on a dev board for the duration of hte projects life, it's not going to help much.

[gamalot]

There is a jumper (JP6) on the Nucleo64 board that can be used to measure the current of the device.

[eutectique]

The problems I have had with the STM32L476 are that its flash controller requires flash to be written in 16-byte blocks,

It's 8-byte blocks. Document RM0351 rev9, section 3.3.7 "Flash main memory programming sequences" : The Flash memory is programmed 72 bits at a time (64 bits + 8 bits ECC).

[paulca]

Ah, okay, so I read the manual and yes, it has exactly that section:

JP1 (IDD)
JP1, labeled IDD, is used to measure the STM32 microcontroller consumption by removing
the jumper and connecting an ammeter:
• JP1 on: STM32 is powered (default)
• JP1 off: an ammeter must be connected to measure the STM32 current
If there is no ammeter, STM32 is not powered.

Other useful info relating to my project...  if I power it from a USB charger (as I intended), no USB enumeration will happen and the Nucleo32 will power off the STLink entirely including it's LED.  That should save some power.

[gamalot]

There is a jumper (JP6) on the Nucleo64 board that can be used to measure the current of the device.

Sorry, I see it as Nucleo 64 for some reason!

I found my Nucleo 32 board (L011K4), JP1 is a 1mm pitch jumper which is simply too hard to use ...... 

[paulca]

There is a jumper (JP6) on the Nucleo64 board that can be used to measure the current of the device.

Sorry, I see it as Nucleo 64 for some reason!

I found my Nucleo 32 board (L011K4), JP1 is a 1mm pitch jumper which is simply too hard to use ...... 

LOL, yes.  I only found it had a jumper at all when I'd owned it for a week and decided to look at it under a high power lens.  I thought it was a tiny tantalum or something.

[tabemann]

The problems I have had with the STM32L476 are that its flash controller requires flash to be written in 16-byte blocks,

It's 8-byte blocks. Document RM0351 rev9, section 3.3.7 "Flash main memory programming sequences" : The Flash memory is programmed 72 bits at a time (64 bits + 8 bits ECC).

Thanks - I had borrowed my STM32L476 flash code from Mecrisp-Stellaris (it was actually the first platform I targeted), and Mecrisp-Stellaris writes flash on the STM32L476 16 bytes at a time, so I had assumed that was the limitation.

[paulca]

Anyway.  Low power design is not my fortae.  (4th pun?)

I'm designing a schematic with a chip enable circuit and put a 47K pull down on it and a 4.7K pull up.  There's 3mA right there.  I suppose I had best go and read how large the internal pull up is, do some voltage divider sums and pick more appropriate values for low power... or just neatness.

[dietert1]

Started using STM32L4 amidst the availability crisis, as i thought that could be the future with STM32. Today i saw that Farnell have several of those available in amounts of some thousand. There is even a STM32L433 in QFP48 that should serve to fix clone bluepills. That should be a simple path to a low power development kit (with external STLINK).
There is the STM32G line with some availability, too.
Maybe they consider the cloned F line products as obsolete. Also the U line appears to be low priority now.

Regards, Dieter

[DavidAlfa]

If you had read the Board manual (MB1180), you would have find the correct place for measuring current is JP1.
The instructions are clear as water; Open the jumper, then place the ammeter there.

6.7 JP1 (IDD)
JP1, labeled IDD, is used to measure the STM32 microcontroller consumption by removing
the jumper and connecting an ammeter:
• JP1 on: STM32 is powered (default)
• JP1 off: an ammeter must be connected to measure the STM32 current
If there is no ammeter, STM32 is not powered.

More RTFM and less ranting

[paulca]

That was easy.  The full bitmap (borrowed off the web and converted to b16 B5G6R5 format) had me for an hour because it was showing up with garbage and then the image miss aligned.  Turns out missing a single & can make a difference and with such small memory, you are actually highly likely to get part of your image in there.  I passed the first element of the BMP array (0x0000) as the address for SPI to start copying the image from.  At least I got to "see" the memory map or the first 76k of it.    A satisfying "ahhhh! haaa!" moment.

I'll do the current measurements tomorrow, when I can get under board with tweezers.

[DavidAlfa]

Isn't that a 160x128 1.8" display? Yep, plain bitmaps use 40KB, hurts hard when using small devices.

Hint: Try storing them to a external SPI flash, connect MISO & MOSI together, send the read cmd, de-select it (hold mode), select the display, set write mode, select the flash again and issue a 40KB DMA SPI receive, configuring the DMA to not increase the dst address (Avoiding the need of allocating any large buffer).

SPI chips cost pennies and It will only steal 1 gpio.
Works amazingly well!