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

[frankmeyer9]

Posted on September 05, 2012 at 17:13

If you can rule out an issue with the individual board/controller, such as interfering circuitry or damaged pins, I would contact some ST person.

Not that it would help you in the short run, though...

[David Littell]

Posted on September 05, 2012 at 18:16

Is the board your own design or a development board from some vendor?

[Tesla DeLorean]

Posted on September 05, 2012 at 18:19

Well I've had no issues with the STM32F103RET6 and STM32F103VEH6

I guess you'd need to look at the stepping and date code specifics.

[tilmann]

Posted on September 05, 2012 at 21:38

Dave,

it's my own design - however it's already the fifth one with the F103R, so meanwhile I'm somewhat used to it. Three other boards (with the RB) ran perfectly from the start, also one RE based board (that was programmed by JTAG since the USART1 port was needed otherwise). And the current one also runs fine - as soon as the program was flashed via JTAG. Apparently, it's only the built-in ISP loader that doesn't work correctly. Basically, you can't do much wrong regarding the ISP loader - all you need is the power supply and the proper signals at BOOT0/1... Greetings, Tilmann

[Tesla DeLorean]

Posted on September 05, 2012 at 22:04

If this is with software you've written, have you considered that flash pages are potentially of a different size?

I recall some errata about USB and high current draw, and some releases where the ROM firmware was broken. The date codes might provide some closure. Try using some terminal where you can send 0x7F at 2400 8-E-1 The autobaud is a one-shot deal, if it doesn't measure the data correctly you need to reset and start over.

[tilmann]

Posted on September 06, 2012 at 12:05

Clive,

of course the built-in ISP bootloader was not written by me. :) Thanks for the hint to testing the autobaud function with a terminal program. Interestingly, after having sent the 0x7F (and received the 0x79 ACK), the TXD line is in the correct state then. Obviously, this is a difference between the two chip types I have at hand (RB and RE); with the RB chip TXD is high right from the start. However, I'd still call this (the RE behaviour) a bug since TXD statically being low is not a valid state for RS-232 communication. Tilmann

[Tesla DeLorean]

Posted on September 06, 2012 at 15:39

of course the built-in ISP bootloader was not written by me. :)

But the software on the PC talking to it can be. The pins are initialized as PA10 input floating, PA9 output PP. The USART is not initialized until after the timer has measured the pulse width on the RX pin, the boot loader never reads the 0x7F from the USART.

[David Littell]

Posted on September 06, 2012 at 20:11

''...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. 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.

[tilmann]

Posted on September 06, 2012 at 21:35

''But the software on the PC talking to it can be.''

Sorry, that simply didn't come to my mind... Just the behaviour of the chip resp. bootloader, without any PC software involved, already puzzled me. I have been using the Flash Boot Loader Demonstrator provided by ST, as well as STM32FLASH from the command line. Both worked right from the start with the RB chip, but not with the RE.

The pins are initialized as PA10 input floating, PA9 output PP.

The USART is not initialized until after the timer has measured the pulse width on the RX pin, the boot loader never reads the 0x7F from the USART. So it's possible that PA9 was configured as (GPIO) output, but without initialization of it's level - and only after autobaud is completed, the level becomes correct since the USART takes over the port (alternate output)? I'd never expected that, or done something like that by myself... Tilmann P.S. Isn't it possible to get at least a slightly larger editor window here, instead of wasting 80% of the screen size for white?