STM32F103RE: ISP bootloader doesn't work correctly

[tilmann]

Posted on September 05, 2012 at 15:58

Hello,

I just started a new project with the F103RE controller. Opposed to the F103RB I have used before, the ISP bootloader in this chip simply does not work. Though it is obviously running correctly (verified by JTAG), the TXD line is not initialized to a high level, and no meaningful answers are sent by USART1 when I try to connect to the boot loader. Just to prevent related questions: BOOT0 and BOOT1 are definitely correct, and verified by JTAG the MCU is running in the system memory. I was able to flash my program using the JTAG interface, and then the application runs perfectly - including communication by USART1. So the chip hardware (USART, port logic) appears to be intact. Is anything known about badly programmed ISP bootloaders in such chips? (Assuming that the loader itself is pretty identical between the chip sizes B (128k) and E (512k).) The errata sheet of the C/D/E sized chips contains very many issues, but this one is not (yet) listed... Thanks, Tilmann

[tilmann]

Posted on September 06, 2012 at 21:47

''...all you need is the power supply and the proper signals at BOOT0/1...''

''And actually believing that may be a problem in itself.  Consider (and actually scope) noise on power pins or the UART Rx pin, bad caps, inductors, etc., even marginal board fab.'' OK, I will do some additional measurements, just to be sure - but I don't expect anything new here. It's not my first design, also not the first with this chip type. That's why I wrote ''Basically...'': Of course all those standard issues need to be taken care about, but I'm pretty sure I did (and I checked that many times before posting here). Again, what puzzles me is that TXD simply is low after starting the ISP bootloader. And it's (correctly) high with the RB chip. Everything else is perfectly fine with those chips - including the ports PA9/10 and the USART1 functions. ''Maybe I missed it, but I don't recall seeing your response to the date code question.  Are all the problematic devices the same date code?  If so, what is that date code?  Possibly someone here has that same one and can comment.'' You're right, I didn't post the date code yet. Yes, the RE chips in question have the same date code, I will post it tomorrow (when back at work). Unfortunately, I don't have too many of them (actually two right at hands, the other samples are already at our costumer), and I also don't have RE chips of other date codes to verify. That's why I posted the question at first... Tilmann

[David Littell]

Posted on September 06, 2012 at 22:29

I have been using the Flash Boot Loader Demonstrator provided by ST, as well as STM32FLASH from the command line.

Is this the stm32flash thing from code.google.com?  Ugh.  I had lots of reliability problems at it's default baud rate using a USB serial adapter with an Olimex STM32-P107 (STM32F107VC).  It's been working very well at a slower baud rate.  (I also spent a lot of time trying to straighten out some of the silliness in that code - painful.)I'd never expected that, or done something like that by myself.. It does make some sense if the autobaud (a really bad idea all by itself, but that's another discussion...) doesn't have direct UART support and requires the core to do the gap timing.

[Tesla DeLorean]

Posted on September 06, 2012 at 23:35

So it's possible that PA9 was configured as (GPIO) output, but without initialization of it's level

It is attached to the AF signal busing/fabric, the clock to the USART1 is running, but it is not initialized.

[tilmann]

Posted on September 07, 2012 at 09:50

I have been using the Flash Boot Loader Demonstrator provided by ST, as well as STM32FLASH from the command line.

Is this the stm32flash thing from code.google.com?  Ugh.  I had lots of reliability problems at it's default baud rate using a USB serial adapter with an Olimex STM32-P107 (STM32F107VC).  It's been working very well at a slower baud rate.  (I also spent a lot of time trying to straighten out some of the silliness in that code - painful.) Yes, it's that program. I was lucky to find a small program running from the command line at all; after having searched extensively at ST (who should have provided such a tool) I finally found this one. It has been working very fine so far (at 115200 Bd), so I didn't look into the details... However, when it didn't work with the RE chip, I also tried the ''Flash Loader Demo'' and after that I had a look at the hardware signal levels. Interestingly, the results of  TXD being constantly active obviously vary between different COM port types (native, different USB/232 adapters). One of them floods the virtual port with NUL characters then, maybe that also annoys the related PC software... I still think it's illegal behaviour, TXD must be initialized to a high after reset.I'd never expected that, or done something like that by myself..It does make some sense if the autobaud (a really bad idea all by itself, but that's another discussion...) doesn't have direct UART support and requires the core to do the gap timing. But even then the port initialization must include setting the correct default level... Tilmann

[tilmann]

Posted on September 07, 2012 at 09:56

Maybe I missed it, but I don't recall seeing your response to the date code question.

Here's the printing on the chips in question:

STM32F103

RET6 GH233 9U CHN GH 220 Tilmann

[stforum.tormod9]

Posted on September 08, 2012 at 11:16

According to the documentation (

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00264342.pdf

) the bootloader scans the RX pin to find the baud rate from the 0x7F signalling, then initializes the serial interface. So strictly speaking it is not a serial device before the 0x7F has been decoded, and you can't assume anything about different USART pins before this happens. OK, I am giving ST a lot of goodwill here 🙂

[John F.]

Posted on September 10, 2012 at 09:43

Has the hardware design changed? All other possible programming pins (other USARTS etc.) must be quiescent when the part first comes out of reset into the bootloader.

[David Littell]

Posted on September 10, 2012 at 17:44 But even then the port initialization must include setting the correct default level... Ah, there's the rub: the UART isn't initialized yet and the pin doesn't become TxD until after the autobaud silliness completes and the UART is initialized.  Before that, the pin-to-become-TxD is just another uninitialized GPIO, right?  Was ths an oversight in the bootloader pin initialization, yes, but actually an artifact of the autobaud brain damage. This is what happens when somebody who doesn't have enough to do sprouts a stupid idea like autobaud for a piece of code whose first and foremost mission should be reliability. How about a nice, little 10K pullup at that pin?  Not enough to cause trouble, but enough to get you the high level before the UART takes over.

[John F.]

Posted on September 11, 2012 at 09:29

You've missed the point. The microcontrollers support booting from any one of a number of different sources (pins / peripherals). It's only AFTER the activity on a particular pin has been detected that the microcontroller can configure that pin ... while leaving the others in their normal post-reset state. It's a good design.

[David Littell]

Posted on September 11, 2012 at 16:19

You've missed the point. The microcontrollers support booting from any one of a number of different sources...

No, I think I get the point: flexibility uber alles.  I just believe it's replete with wrongheaded thinking and leads at best to wasted developer time (e.g., Tilmann's woes here) and at worst to something much, much worse (these tend to pop up in the headlines when people get hurt).