Programming STM32F103 in Production, medium-high volume

[manuel239955_stm1]

Posted on July 25, 2012 at 13:45

Dear all,

As part of my bachelor thesis, i have to investigate the programming techniques offered by STM32 microcontrollers.

For R&D I would recommend the use of the JTAG port since debugging is also a big point. But what is the best ''programming technique'' for production? The volume is about 100-1000 microcontrollers a day that have to be programmed. Important for our production is flexibility (ISP is definitly prefered over the use of some external program adapters), easy handling, hardware cost and programming time.

Does anyone of you guys got experience about this case?

You would definitely help me a lot!

Thanks in advance

regards, Manuel 

[Tesla DeLorean]

Posted on July 25, 2012 at 14:22

Use the USART1 with the built in boot-loader. Have a method to drive RESET, and BOOT0. Use a header, or test point array, or hardware/connectors already on the final product. Have a multi-headed serial port adapter, and use as high a baud rate as you can. You can use non RX/TX pins to signal/drive the process.

JTAG adapters are expensive, hard to program, and prone to damage. You can get stand-alone push button JTAG programmers, these are even more expensive. Often several times more that a scratch PC. We accumulate obsolete/junker computers as people upgrade, and then use them to build programming stations.

Are you looking to automate, program 1-up, 4-up, 10-up, etc? Use multiple stations? Do you understand the protocols well enough to write your own software and build a programming station?

Does the programmer also do final testing, calibration or serialization, or are these things more efficient for you to do as separate steps, or with test code within a boot loader.

[frankmeyer9]

Posted on July 25, 2012 at 14:27

Not referring to STM32 controllers especially, often are generally available debug adapters used for programming during production. Regardless of the interface (being it JTAG, SWD, SWIM, BDI or what-so-ever), testpads are reserved on the PCB, which are contacted with a needle bed after placement/soldering. Then, the programming application ist started, often as an external cmd. line application call from within another application. Usually, this is the first step in the production test of the device.

[manuel239955_stm1]

Posted on July 25, 2012 at 15:17

Hi clive1,

Thanks for your opinion.

So in your opinion the loss of programming speed by using the bootloader instead of the JTAG/SWD is not as dramatic as the hardware costs / extra hardware inventory etc. you need for JTAG/SWD?

Because the programming speed of SWD should be a lot faster than UART/CAN if you use a bootloader..

Yep, we are looking to integrate the programming into our end-test procedure of the product. Using multiple stations in order to make the programming parallel would also be a good idea, however, extra inventory is required (I have to check if this is possible)

I wont be the person who is responsible for the programming code and so on, it is my task to find a solution for programming and testing the µC/PCB in our production (well, to find the best possible solution of course :)   )

Regards, Manuel

[Tesla DeLorean]

Posted on July 25, 2012 at 18:45

Because the programming speed of SWD should be a lot faster than UART/CAN if you use a bootloader..

Really, do you have anything to prove this assertion? What if I run my USART at 460800 or 921600 baud, with a streaming protocol? I think the flash would be the bottleneck, any improvement from SWD would be fractional at best, not some order of magnitude. CAN would clearly blow given the packet size.

For JTAG/SWD you'd need to buy a lot of hardware and software, or be particularly skilled in the art. Cost per pod w/basic drivers, perhaps $1K licensed, development costs in the order of $10K. Contrast that to some USB serial ports, and cables that might run $20 a head, and software dev time about a quarter, ie 1 week vs 4 weeks. Cost savings there could  be applied to replicating the test set up.

A single station could program multiple devices, would depend on how good you are at scaling your solution. Multiple devices could be programmed in parallel, a whole rack/array sequentially. Put a red/green LED on the individual test fixtures.

For manual labour, you'd want a big enough fixture that the test operator would be kept busy installing/removing devices as the tester rolled from one row to the next. Bin the failing devices for a single up retesting.

[manuel239955_stm1]

Posted on July 26, 2012 at 07:40

Good morning clive1,

According to this paper :

http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php

The programming speed of SWD should be up to 4MB/s

The maximum USART1 speed of STM32F103 should be 115.2KB/s (highest speed verified by the datasheed)

CAN programming speed is up to 1MB/s if i am correct.

I am still a student and i am for sure lacking experience that you have, therefore the informations given above may be incorrect or partly correct.

What do you mean with a streaming protocol?

So in your opinion the procedure with a Bootloader that allows programming via CAN is superior to JTAG/SWD?

As far as i am informed, the production team mounts a product then tests it. In the time of testing they already start to mount the next product. At the moment, testing (including programming) takes longer than mounting a whole product. But i guess that this problem will be solved in future..

Thanks for your help clive!

[manuel239955_stm1]

Posted on July 26, 2012 at 07:41

Sorry for doublepost, i got an error and thought i had to remove the link..

[John F.]

Posted on July 26, 2012 at 09:40

Manuel, please look at some device data sheets and consider both the rate at which programming data can be transferred and also the time taken to program a memory location. For example, the STM32F407 may take up to 875ms to erase a 128KB sector and may take up to 100us to program each double word.

The problem isn't just how fast data can be transferred ... by whatever means.

[manuel239955_stm1]

Posted on July 26, 2012 at 10:11

Hi John,

Ive looked through the data sheet

http://www.keil.com/dd/docs/datashts/st/stm32f10xxx.pdf

and the flash manual provided by ST.

I didnt find any informations about the time that is needed to program the Flash..

but i always thought that i first program a buffer and to program this buffer, only the data rate of the connection is important (is it CAN, UART or SWD/JTAG)

and then the processor writes the data from buffer to flash, and this is the point where i need to consider the programming time given by the processor..

Or am i wrong? Thanks for your help!

[John F.]

Posted on July 26, 2012 at 11:35

You have linked to the Reference Manual. You need to look at the

Data Sheet

/ Electrical Characteristics / Operating Conditions / Memory characteristics.

http://www.st.com/internet/mcu/product/247490.jsp

[manuel239955_stm1]

Posted on July 26, 2012 at 12:34

Hi John,

thanks for that information, ive found what you were refering to:

(see attachement)

What does this information offers me if i want to know the best possible programming procedure to use in production?

Is it correct that this time is independently of my data rate time that UART/CAN/JTAG/SWD offers? I thought that data first gets written into the buffer (with the data rate of the above mentioned) and then the processor writes it with the time mentioned in the table to the flash memory.

or am i wrong?

Thanks!

________________

Attachments :

Prog.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtVo&d=%2Fa%2F0X0000000aR5%2F.s.SL6ACe9WcIDTl8XsomDYjSzbtowDR6jk4S4ZRHOQ&asPdf=false