Bootloader support for new CortexM3 devices

glenn2 · ‎2010-07-07

Posted on July 07, 2010 at 23:07

#stm32

sjo2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

engineering samples, they must be old :)

v2.2 supports the HD parts, so it may be down to the early silicon you have.

Cheers

Spen

Nickname12657_O · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Dear Glenn, Spen,

STM32F103ZGT6 engineering samples are not High Density devices but XL-density devices with 1Mbytes of flash and these engineering samples do not contain embedded boot-loader in the SystemMemory ROM area. However Flash Loader V2.2 is fully supporting the XL-density that are shipped in production samples and containing the Boot-loader.

Cheers,

STOne-32.

glenn2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

glenn2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Hello STOne-32,

You nailed it, thanks.

-Glenn

glenn2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Hello

STM

,

We received the new parts yesterday and one is mounted on our board.

The part seems to function just fine except for this problem.

The Flash Loader Demonstrator

V2

.2.0 program does not recognize the part.

When I connect the

ULINK2

to the board, the flash memory is viewable and has these characteristics.

I can see the

bootloader

code in system memory at

0x1FFFE000

...

0x1FFFEE3B

.

If I have the

BOOT0

pin at logic one, The same code is visible at location

0x00000000

and the

bootloader

code begins execution after reset as expected.

What looks weird is the

bootloader

option bytes at location

0x1FFFF800

.

This data looks like a test pattern in the first two bytes.

Here is the data from

0x1FFFF800

,

A5

5A

FF FF FF FF FF FF FF 00 FF 00 FF ......... FF

Would you check into this please. Here are the details.

Part on the board

STM32F103VGT6P

(note the P at the end, it does not say

PROTO

on the chip)

chikos332 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

.ExternalClassE5CE9E69E9064EF99366074693392C32 p.MsoNormal, .ExternalClassE5CE9E69E9064EF99366074693392C32 li.MsoNormal, .ExternalClassE5CE9E69E9064EF99366074693392C32 div.MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;font-family:'Calibri','sans-serif';} .ExternalClassE5CE9E69E9064EF99366074693392C32 span.EmailStyle15 {font-family:'Times New Roman','serif';font-variant:normal !important;color:#365F91;text-transform:none;text-effect:none;text-shadow:none;text-effect:none;text-effect:none;text-decoration:none;text-underline:none;text-decoration:none;text-line-through:none;vertical-align:baseline;} .ExternalClassE5CE9E69E9064EF99366074693392C32 .MsoChpDefault {;} @page WordSection1 {size:8.5in 11.0in;margin:70.85pt 70.85pt 70.85pt 70.85pt;} .ExternalClassE5CE9E69E9064EF99366074693392C32 div.WordSection1 {page:WordSection1;}

Hi,

The pattern on Option bytes is normal , these are the default values on all new chips (lets say factory values). Once you modify them, they will behave correctly (complement of each byte will be set).

For the connection issue:

- Which USART interface are you using, and how do you connect unused IOs ?

- Have you tried to increase the timeout or decrease the Baudrate value ?

glenn2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

I am using USART1 which works fine with my code (loaded with ULINK2).

The RX input of USART2 is pulled to ground with a 1 meg resistor. I measured 0.0 VDC on the pin. I have tried lower baud rates like 38400 bps with no success. The timeout is not an issue as the program reports immediately that the device is unrecognized. I have a text file dump of the flash data at 0x1FFFE000 ... 0x1FFFFFFF. If you like, I will send it. The code executes when the BOOT0 pin is tied high, I can single step through the bootloader.

What do you mean in regard to modifying the option bytes?

This data does not get erased when I program my code in the part, even with the option set to erase the whole chip.

The labling of this pre-production part is:

STM32F103

VGT6P A

HPAMM 93

KOR HP 061

ST ARM

-Glenn

glenn2 · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Hello STM,

I have a correction to my previous statement. The USART2_RX pin on the LQFP100 package is pin 26. This is port PA3. This is tied to a 1KHZ clock on the board.

It is not pulled down to ground as I thought.

After reading closer in AN2606, the USART2 pins are suppose to be remapped.

Therefore, the USART2_RX pin on the LQFP100 package is pin 87. This is port PD6 which is pulled to ground through a 1 meg resistor.

Since USART RX inputs are normally at logic one, should this be pulled high instead of being pulled low?

-Glenn

Nickname12657_O · ‎2011-05-17

Posted on May 17, 2011 at 13:57

Dear Glenn,

Since the sample yo have is a prototype sample not yet put in production and as you are now with direct contact with our Local support Office. We will follow your case locally.

Cheers,

STOne-32.