Flash Programming in Mass Production

Time Is Money – Programming Time Too

31. Januar 2022, 6:00 Uhr | Harry Schubert
© RS-Studios – stock.adobe.com

Software for embedded systems must be transferred safely, reliably and quickly to flash memory in production. In an interview, Product Manager Peter Orda from Segger Microcontroller, explains the advantages of a programming system with a central hub and distributed programming devices.

Diesen Artikel anhören

In the production of embedded systems, programming the microcontroller firmware is only one of many steps. However, flash programming can be quite a time-consuming step. Thus, to achieve high production efficiency, programming time must be minimized. Segger Microcontroller has developed a programming system with a central hub and distributed compact programming devices that enables high programming speed.

?   Mr. Orda, what motivated you to develop a programming system for use in production lines?

Peter Orda, Produktmanager bei Segger Microcontroller
As product manager, Peter Orda is responsible for the entire Flasher family at Segger Microcontroller: »Our programming time is as close as possible to the technically possible minimum.«
© Segger Microcontroller

!   Peter Orda: At Segger, we already had a solution for aisle programming with the »Flasher ATE«. From discussions and inquiries from customers, we learned that the conception of the ATE did not completely meet the needs of all customers. The main problem mentioned to us was the space limitation due to the cable lengths of the »Flasher ATE«. Many Customers need a solution where a programming adapter can be placed as close as possible to the target to achieve maximum programming speeds, but on the other hand the distances between the ATE can be as flexible as possible.

We are now proud to present exactly such a solution with the Flasher Compact (FC). It is small enough to be placed almost directly on the target and thus enables very short line lengths of the programming interface. On the other hand, with the USB interface we have a fast standard interface with a sufficiently large range to support almost all conceivable geometric distributions of test stations.

Übersicht Flasher Hub und Flascher Compact
Up to 24 Flasher Compact can be operated in parallel at the Flasher Hub to program the flash memory of embedded systems.
© Segger Microcontroller

Thereby, the FC is a typical Segger flasher with the well-known high speed, which in most cases is very close to the theoretical maximum. The configuration programs »J-Flash« and »Universal Flash Loader Configurator« have been available for years for both Windows, MacOS and most Linux distributions for Intel.

The Flasher Hub allows centralized control of up to 24 FC, in addition to the standalone modes supported by the FC, as known from our other Flasher products. Thus up to 24 targets can be programmed in parallel with individual firmware images, stand-alone – operated by keystroke only – or automated controlled via a CLI using UART, including dedicated lines for Ready/Error or TELNET.

In addition, a web server is integrated in the Flasher Hub as a further communication option, besides the CLI via UART and TELNET. This makes it easy to control the network of up to 24 FC and to query the status.

Via the FTP server in the hub, the firmware images and the associated configuration files, including serial numbers and patch configuration, of one or more projects can be transferred to the flashers. The log files of the flasher can also be retrieved in this way.

?   What is the concrete advantage of the Flasher Compact compared to other programming devices?

Unfortunately – or fortunately – every memory wants to be addressed differently.
Peter Orda, product manager at Segger Microcontroller:
© Segger Microcontroller

!   Orda: The Flasher Compact is probably the smallest "industrial grade" programmer available on the market. The housing has the volume of about two matchboxes (72.3 × 4.6 × 16.9 mm³) and is thus small enough to fit in the AT even in very tight spaces. And if that doesn't work out after all, the case can be left out. We have provided mounting holes on the board for such cases.

?   You have highlighted the high programming speed. Why is speed so important and how can it be achieved?

!   Orda: I have learned through conversations with customers, colleagues and through my own experience that programming and test times in particular can be the bottleneck in a production. In a planned output, one second more or less can decide whether an additional test station is necessary. And an additional test station is a not insignificant investment. That's why we want to support our customers by always looking for ways to keep the programming time as close as possible to the technically possible minimum.

In addition to a fast programming interface with clean signals and short line lengths as a physical requirement, we use the fastest programming modes of the targets whenever possible. For many targets, a specially created code is loaded into RAM to do the programming. This eliminates some of the protocol overhead that would be required for direct programming via the ISP.

To also make good use of the time needed to program the flash, our RAM code in turbo mode loads data into RAM during this time so that programming can be done with as little dead time as possible. Whenever possible, amounts of data are moved in the available RAM size to minimize the protocol overhead here as well.

?   There are thousands of different microcontrollers and memory ICs. How many of them does Segger support with the Flasher Compact and what can a customer do if he wants to use other devices?

The Flasher Compact is probably the smallest ›industrial grade‹ programmer available on the market.
Peter Orda, product manager at Segger Microcontroller:
© Segger Microcontroller

!   Orda: Yes, and unfortunately – or fortunately – each memory wants to be addressed differently. Even within a family, there are subtle differences, so it's usually not enough just to adjust the address ranges. In addition, due to increased security requirements, the hurdles to be able to access the memory at all are becoming higher and higher. Therefore, it is unfortunately not possible for us to immediately support every new memory that appears. In addition, the documentation situation is sometimes very poor. Here we are dependent on the manufacturer's willingness to provide us with documentation and support in a timely manner. For some targets we are forced to reverse engineer because we do not get any information or it is useless for our purposes.

We try to support a popular series completely step by step. However, due to the large number of manufacturers, series and newly introduced targets, our developers are pretty busy. more than well utilized.

If a customer uses unsupported memory for a project in the near future, we do our best to provide support for it with our Flasher products. However, depending on the complexity of the component, this may incur costs that we have to charge to the client on what I think are quite fair terms.


Matchmaker+