Skip to main content
glenn2
Associate
July 7, 2010
Question

Bootloader support for new CortexM3 devices

  • July 7, 2010
  • 9 replies
  • 1558 views
Posted on July 07, 2010 at 23:07

Bootloader support for new CortexM3 devices

#stm32
    This topic has been closed for replies.

    9 replies

    Nickname12657_O
    Associate III
    May 17, 2011
    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.

    sjo2
    Visitor II
    May 17, 2011
    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
    glenn2
    glenn2Author
    Associate
    May 17, 2011
    Posted on May 17, 2011 at 13:57

    Hello STOne-32,

    You nailed it, thanks.

    -Glenn

    glenn2
    glenn2Author
    Associate
    May 17, 2011
    Posted on May 17, 2011 at 13:57

    chikos332
    Visitor II
    May 17, 2011
    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
    glenn2Author
    Associate
    May 17, 2011
    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)

    glenn2
    glenn2Author
    Associate
    May 17, 2011
    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

    glenn2
    glenn2Author
    Associate
    May 17, 2011
    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

    Nickname12657_O
    Associate III
    May 17, 2011
    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.