System Memory Boot Mode and TIM1 usage

[lspr35]

Posted on March 19, 2009 at 07:35

System Memory Boot Mode and TIM1 usage

[lanchon]

Posted on May 17, 2011 at 12:18

Hi,

I read AN2606 (STM32F101xx and STM32F103xx system memory boot mode) a while back and was surprised to find that the AN is sort of general in nature (discusses protocol) and doesn't mention which peripheral(s) can be used for bootloading specific chips. The only mention I found of a specific peripheral is in the caption of figure 1 (Bootloader for STM32F10xxx with USART1) which is sort of an example.

Since I wasn't planning to use the feature I didn't ask around. But I'm curious, where did you get the info that only USART1 is supported for bootloading?

PS. I didn't download the PC software, maybe some more info is buried there?

[ This message was edited by: lanchon on 01-12-2007 21:02 ]

[lspr35]

Posted on May 17, 2011 at 12:18

I would like to use the ''Systemmemory Boot Mode'' which is available via USART1 (only). Additionally I would like to use the TIM1 for PWM generation for motor control. Unfortunately the USART1 RX and TX pins are located on the same pins as the TIM1_CH2 and TIM1_CH3 (PA9 and PA10). Remapping of these pins is not possible:

1. Remapping of USART1

is not possible because after reset USART1 is always mapped to PA9 and PA10

2. Remapping of TIM1

is not possible for devices with (only) 36, 48 and 64 pins. I would like to use the 48 pin device...

Is there any other possibility to use USART1 for System memory boot mode and additionally TIM1 for motor PWM?

Regards

Squonk

[lspr35]

Posted on May 17, 2011 at 12:18

In the Datasheet on page 10 I found:

''The boot loader is located in System Memory. It is used to reprogram the Flash memory by using USART1. For further details please refer to AN2606.''

So obviously the Booltoader uses USART1 only...

What do You think?

Best regards

Squonk

[lanchon]

Posted on May 17, 2011 at 12:18

well STOne-32 has spared the life of your post so you must be right... :)

what I think? AN2606 was written to describe the protocol in a device independent manner supporting any bidirectional byte streams, so I think there should be some other note clarifying how that applies to specific chips, specially if they aren't publishing the source.

I also think that since this code provides a window of visibility to our own code, it'd be a good idea for ST to publish it. Security by obscurity is never a good idea.

[ This message was edited by: lanchon on 04-12-2007 00:59 ]

[16-32micros]

Posted on May 17, 2011 at 12:18

Hi all,

Yes ,you are right :) , I'm joking ... The idea behind is just that we can not create one bootloader for each customer refering to his expectations , this is not feasible and all others semiconductors company do the same, else it would be not under our control and it costs a lot in Manufactuering wafer and silicon processes.

However you are right it seems some pages of our AN2606 are missing describing the hardware to be used with our bootloader which of course will be maintened and enhanced in future revisions. I will request to add more details about HW and USART1 details on this AN. Thank you for your comments :)

PS: The embedded factory bootlader is less than 2Kbytes, so only two flash pages are needed.

[lanchon]

Posted on May 17, 2011 at 12:18

I'm sure they've blocked the range, just to make fun of us...

[lspr35]

Posted on May 17, 2011 at 12:18

I think, if we are interested in the code of the system memory boot mode we could use this bootloader in order to read the binary code from system memory using e.g. the ''Read Memory Command'' of the bootloader. Ofcourse this is not the source code but only the binary. But with some additional work it should be possible to regenerate a commented Assembler file. Is there anybody out there who can do this?

Regards

Squonk

[16-32micros]

Posted on May 17, 2011 at 12:18

Dear Squonk, all,

We have many customers Going to Production and they what to know how to program our STM32 Flash MCU ?

Case 1 : The customer or its manufacturing has the capability to program the parts.

Means he has or wants to invest in the equipment (line/gang programmers), or he has the ability to use the boot-loader.

There are some drawbacks with this:

Need to invest in programming equipment or special development

Need to amortize the equipment

Case 2: The customer does not have this capability

The customer can refer to a programming service company.

There are some drawbacks with this

More complex logistics

Longer lead-time

Difficult to find a good service company

To provide an additional service to our customers, and solve these issues, we offer the “programming service� which is the possibility to program the parts in the factory with the customer code. (Customer Volume > 100.000 units par Year)

This is to offer to our customers

1) A simple alternative for programming

2) Simple logistics: Only ST as supplier

3) Shorter lead-time

4) No investment required

There is a fee associated to this, as for any service.

So you can contact your nearst ST Office to get more information about your Production and when this service will be active in your country/region. Thx.

STOne-32

[lspr35]

Posted on May 17, 2011 at 12:18

Hello STOne-32,

ofcourse the embedded bootloader is smaller than 2k. But if I make my own bootloader residing in two flash pages using e.g. USART2 then there must be a way how this ''myBootLoader'' gets into the flash. So the first programming of this ''myBootLoader'' is different from the programming of the following application programs. This is the situation I wanted to aviod!!!

So I must buy pre-programmed devices from a distributor which will cost e.g. 50ct more. This is a lot of money in my application.

Will there be an enhanced embedded bootloader in future where it will be possible to use e.g. USART2?

Best regards

Squonk

[ This message was edited by: Squonk on 07-12-2007 11:56 ]

[wolfgang]

Posted on May 17, 2011 at 12:18

Hello,

we are testing the boot loader feature at the moment. For your interesst:

1. it is possible to jump into the boot loader from your application. So you do not need to modify the BOOT0/BOOT1 pins.

2. the boot loader does not modify the remap-bit for USART1. So you can remap the USART1 to other pins.

At the moment we do not know if the autobaud feature of the bootloader is hard coded against the standard USART pins. We will test it this week.

Maybe it is flexible at this point, so you can use the boot loader feature even together with TIM1!!!

Regards

Wolfgang Beck