Fails to detect the STM32L15xxx range of ultra-low power MCUs

[GoogleCodeExporter]

There's no entry in stm32.c for the EnergyLite range (STM32L15xxx), so the 
search performed in stm32_init() returns a null value, pointing to 
uninitialised memory.

It should probably handle this case, and admit it is an unknown device, and 
unsafe to program.

Looking at the datasheet, page 40, suggest these values should be correct:

{0x416, "Energylite", 0x20000000, 0x20004000, 0x08000000, 0x08020000, 4, 1024, 
0x1FF80000, 0x1FF8001F, 0x1FF00000, 0x1FF00FFF},

The entry for fl_end seems at odds with the datasheets. Looks like an 
off-by-one error, as to get the right result (as seen below) you have to give 
the next address up, and not the real end address, which is 0x0801FFFF.

This chip is used in the STM32L-Discovery demo board.

When compiled with the line above added in, we get:

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
Version      : 0x30
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0416 (Energylite)
RAM          : 16KiB  (0b reserved by bootloader)
Flash        : 128KiB (sector size: 4x1024)
Option RAM   : 31b
System RAM   : 3KiB

Resetting device... failed.

Original issue reported on code.google.com by mishg...@gmail.com on 15 Jun 2011 at 12:56

[GoogleCodeExporter]

Looks like something similar is happening with the System RAM calculation too. 
Option RAM I think, on reflection, is just a byte.

{0x416, "EnergyLite", 0x20000000, 0x20004000, 0x08000000, 0x08020000, 4, 1024, 
0x1FF80000, 0x1FF80008, 0x1FF00000, 0x1FF01000},

Pretty sure this makes the program's output correct, even if the values in the 
line above have been fudged to make it that way. How safe that is, I don't 
know, but it's being done on the other PIDs.

Is there a list of the PIDs somewhere? Because these memory sizes are being 
hardcoded in (I appreciate you can't query the chip over the UART), yet this 
range comes in 10kb/64kb and what I have, the 16kb/128kb flavours. I suspect 
the two chips would have different PIDs, but I haven't the other once to test.

Original comment by mishg...@gmail.com on 15 Jun 2011 at 1:38

[GoogleCodeExporter]

Oh bloody hell. Found it at last. Page 45 of AN2606 STM32 Microcontroller - 
System Memory Boot Mode.

They're all there. And the real figures are these:
{0x416, "Medium-density ULP", 0x20000800, 0x20004000, 0x08000000, 0x08020000, 
16, 256, 0x1FF80000, 0x1FF8000F, 0x1FF00000, 0x1FF01000},

That still means the option bytes are showing up one bit short though.

But now I get:

stm32flash - http://stm32flash.googlecode.com/

Serial Config: 57600 8E1
Version      : 0x30
Option 1     : 0x00
Option 2     : 0x00
Device ID    : 0x0416 (Medium-density ULP)
RAM          : 16KiB  (2048b reserved by bootloader)
Flash        : 128KiB (sector size: 16x256)
Option RAM   : 15b
System RAM   : 4KiB

Resetting device... done.

And indeed it has reset- I can run the program again and have it work 
(previously required a trip to the reset button).

Oh, changed the name to me more in line with the technical docs- the name 
"EnergyLite" is more or less restricted to the retail packaging and other 
marketing stuff.

Sorry for all the false starts- and do give the board a look. For less than £1 
more, you get a 6 character starburst LCD and an analogue swipe controller. 
Granted, you lose a lot of pins to that LCD unless you unplug it (easily), but 
it makes for a better demo out of the box!

Original comment by mishg...@gmail.com on 15 Jun 2011 at 2:44

[GoogleCodeExporter]

Thanks for the info, I have added the device info to the source.

Original comment by ge...@spacevs.com on 23 Jun 2011 at 10:25

• Changed state: Fixed

[GoogleCodeExporter]

Added a check for unknown/unsupported devices too.

Original comment by ge...@spacevs.com on 23 Jun 2011 at 10:30

[GoogleCodeExporter]

Revision 14 of AN2606 lists 0x416 with 0x1FF80000-0x1FF80020 for option bytes 
and 0x1FF00000-0x1FF02000 for system memory. If they would follow the same 
convention as for the other devices it should have been 0x1FF8001F for the 
option byte area end, I guess. What a mess...

Original comment by lists.to...@gmail.com on 24 Nov 2012 at 10:34