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 

[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

[John F.]

Posted on July 26, 2012 at 12:44

Hi Manuel,

It's device and implementation dependent. In some cases, a buffer may be available which is large enough to hold code to be programmed - generally, that's unlikely to be true for most devices. Some devices have separate banks of Flash memory and can execute from one while programming the other. You just have to read up on the device Data Sheets to find out more! Your original post discussed programming and testing. Clearly, you cannot begin to test a device until after it's fully programmed - even if the program data had been buffered somewhere. This means that production throughput is dependent on the total erase (if required) and programming time of a device ... which depends on the code size you want to program and then on the test duration. Clive may have more to say when the US wakes up later today. I don't think I can help further.

[manuel239955_stm1]

Posted on July 26, 2012 at 14:33

Hi John,

well, as far as im informed, our assembler tests our PCB without the flash being programmed via an in-circuit test and an optical inspection. Ill check if the STM32F103 µC has a buffer that is large enough to store the program. Thanks!

[Tesla DeLorean]

Posted on July 26, 2012 at 15:04

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

Um, no. The USART1 on a 72 MHz bus is pushing 4.5 Mbit, the loader runs initially at 24 MHz, which might permit 1.5 Mbit. Either way, I'd probably stage the flash loader, and push the bulk of the data with something like XMODEM-1K at higher rates. RM0008 should have a Table 192. Error calculation for programmed baud rates, with notes indicating the max rates, which should be 1/16 of the APB being used. These rates might not be viable, RS232 drivers typically filter at about 1 Mbit, but it's definitely a lot higher than 115.2 Kbit. The erase time for a F4's 128K sector can take several seconds. At least according to the 405/407 Rev 2 manual. Perhaps 4 in particularly aberrant circumstances. As Ron White observed about humans standing in hurricane force winds, it's not that the wind is blowing, it's what the wind is blowing.

[manuel239955_stm1]

Posted on July 27, 2012 at 07:32

Hi clive,

Thanks for your answer Hm, seems you are correct according to this sheet

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00210843.pdf

Ive read something about the maximum verified (tested) Usart speed being 115,2 KB/s, but i do not find the source anymore.. Ill inform myself about XMODEM-1k and RM0008, because these terms are unknown to me :P regards, Manuel

[manuel239955_stm1]

Posted on July 30, 2012 at 15:37

Hi clive,

What are the benefits of using XModem-1k for programming processors in your opinion? Thanks

[Tesla DeLorean]

Posted on July 30, 2012 at 17:32

What are the benefits of using XModem-1k for programming processors in your opinion?

If I was playing a raw speed game I'd probably pick an algorithm that streams better, but some of the advantages of XModem-1K go as follows : a) Very robust, and self synchronizing. b) Very simple, and small. ie I could write it from scratch and have it work in very short order. It's size makes it ideal for implementation in ROM, a lot of SoC designs use it. Sending hex files to a monitor is also very brief. c) The 1K and CRC provide strong integrity, and a reasonable block size. d) The ACK/NACK for each block provide a method of pacing the process, and retrying failures in both data transmission, and flash erase/write. Total failure could be signalled with CAN characters. The implementation could be modified to use larger block sizes if the link is viable. Or could just accumulate larger buffers, ie write 8K buffers to flash holding the eighth ACK, but rapidly ACKing the prior 7 valid blocks. You might also be able to bury the erase time, and background some of the writes. I'd recommend computing the CRC as each byte arrives, so the ACK can have very low latency.

[mcuisp2]

Posted on August 06, 2012 at 06:46

Typical, Programming speed with SWD is 28KB/S, include erase,program,verify.

If only program, The limit speed is 33KB/S.With Uart, It's dramic lower, typical 1xKB/S.Our Handy Programmer EP968, support SWD port and Uart port both. Easy to use. Take a good job for STM32 production.

[Tesla DeLorean]

Posted on August 06, 2012 at 17:12

James, you'd probably sell more of these things if pricing was on your site, and you had an eBay store.

http://www.mcuisp.com/English mcuisp web/index.htm

[manuel239955_stm1]

Posted on August 07, 2012 at 07:38

Hey guys,

Thanks, for the information. I guess we are also looking for such a stand-alone Programmer for firmware updates in field as an alternative to a firmware update with our bus-network, yet im unsure about the quality of those...? Are there any datasheets available for these 2 ''Handy-Programmers''? @clive : Ive thought about the programming cycle like this: Our R&D team is currently working on an own bootloader that will work over CAN (not directly CAN, a new bus-network that will work over CAN but has some specifics). This bootloader will be programmed at our assembler over JTAG or SWD (currently i am preferring SWD since its faster and it requires less ports --> less board space ) The flash of the µC will be programmed via CAN at our production. What do you think about this idea? Another issue that got in my mind is software hacking. Shouldnt it be possible for the customer to hack our software via JTAG or SWD? If yes, how can we protect our products? Thanks!