2013-01-16 02:13 PM
I'm developing an application on a STM32L Discovery card (with an STM32L152 MCU), although our final target is an STM32L151. I wanted to try out the system memory boot mode, that is boot0=1, boot1=0, and then using the UART. I have the latest STM Flash Loader Demonstrator connected to the specified pins for USART1. Several different results: One of my Discovery boards has a revision X MCU. In at least one of those, the loader demo program finds nothing and times out. One also has rev W. On this one, the loader demo connects but then claims that the return value is wrong (and suggests resetting...to no avail.). I also connected this setup to a terminal emulator. With the rev W MCU, typing on the termEm echoes. With rev X, nothing.
So the question becomes: Does it make sense that the X rev does not have the loader, and the X rev does have it but it is buggy? Or does the demo loader program not support this particular MCU? How about the STM32L151?
Thanks!Burns #bootloader2013-01-16 04:53 PM
Don't PA9/PA10 attach to the LCD glass?
The errata doesn't suggest there is a problem. The initial test for the loader is sending 0x7F at 8E1 and looking for an 0x79 response. Try at 9600 baud. You could then send other command sequences to check for functionality or version information.2013-01-16 06:12 PM
It makes good sense to try go figure out what else the boot loader CAN do, or even to figure out what it is returning when it should not. However, the ST code does not allow you to do that. The GUI version won't do anything at all but give an error. The command line interface just returns with ''KO'' (as opposed to OK). I also tried a bunch of different baud rates including 9600. It seems a bit odd that the STM tool lets you choose parity...you'd think it would be required to be a certain way. But I tried all the possibilities there too.
Oh, did I mention that if I don't have anything plugged into the serial port, the software times out. So it DOES see something and initially ''make a connection.''It would be nice if the software would write a log file to tell what it was seeing.So as far as you know, the boot loader and the STM software should work with an 'L152?
Thanks2013-01-16 07:53 PM
I don't have a whole lot of familiarity with the STM32L15x parts, I'll look see what STM32L-Discovery boards I have.
I've built some programmers that use the System Loader, and have generally tested things in RealTerm which can send hex sequences. If it is responsive that might shed some light on the issue.2013-01-17 06:29 AM
Thanks. I appreciate your checking. I'll see what I can do to find what the card is actually sending back also.
2013-01-17 10:13 AM
The one in hand is a W
What you could check is it's general responsiveness, these codes are from notes, not specifically the L152 115200,8,E,1 Send 0x7F Response 0x79 Send 0x01,0xFE Response 0x79,0x22,0x00,0x00,0x79 (Or similar VER ROPS) Send 0x02,0xFD Response 0x79,0x01,0x04,0x10,0x79 (Or similar CHIP ID) Send 0x11,0xEE,0x1F,0xFF,0xF0,0x00,0x10,0xFF,0x00 // 256 Bytes @ 1FFFF000 Response (lengthy)2013-01-17 03:39 PM
Oh! It is supposed to respond to the 7f? Hmm. Unless I was messing up using RealTerm, it did not. Have to play more. Thank you!
2013-02-06 11:11 AM
Ok, solved (after going away for a while and coming back). It works great! I mis-read the Discovery card schematic. Boot1 (PB2) is pulled high by default, not low. You have to either jumper it low or close a solder bridge. With Boot0 high, boot1 low, the STM loader demo works fine. I also used RealTerm to enter a jump command; that works great too!
Thanks for your help, and especially thanks for point out RealTerm. What a useful program!