Production Flashing, Parameterization & QA Platform

Context

Firmware programming and final configuration were required across the company’s controller portfolio before products could leave production. The same production workflow had to support the company’s complete controller portfolio, spanning multiple product generations, different controller sizes and configurations, as well as an additional remote-control product. Individual products also existed in numerous order-specific variants.

The existing production process relied on an internal tool that was difficult to operate and required considerable product knowledge. Firmware updates were cumbersome, production employees required substantial training, and QA information such as serial numbers and device IDs was recorded manually.

I developed a new production application to replace this process with one controlled workflow for firmware programming, software updates, customer-specific parameterization, guided QA, reporting and traceability.

The workflow is deliberately linear and controlled: each stage of order input, device processing and QA/traceability has to complete before the next can begin, and normal production accounts cannot skip or reorder a step.

My Role

I designed and developed the complete application from scratch, including its architecture.

The software was written in C# using WPF and MVVM. My scope included the UI, device and parameter models, communication layer, XML interpretation, firmware flashing and update logic, parameterization, test engine and QA workflow, user accounts and permissions, PDF reporting, server archiving and application update functionality.

This was not a front end around the previous production software. The new application replaced the production workflow while reproducing the controller communication required to work directly with the existing embedded products.

Software Architecture

The application was separated into functional layers and objects around the production process:

• WPF / MVVM user interface
• Device model
• Device parameter model
• Communication layer
• XML interpreter
• Firmware programming and update logic
• Test engine and workflow control
• User and permission management
• PDF reporting and network archiving

The workflow was intentionally restrictive. Operators were guided through each required action in sequence, and normal production users could not simply skip a failed test or bypass a required step.

Higher-permission accounts were available for exceptional operations and rework.

Embedded Communication

The production PC communicates with the controllers through a USB-connected infrared transceiver. The application automatically detects and connects to the interface.

One of the central technical tasks was implementing the company’s proprietary controller protocol in C#. I recreated the communication behavior based on the embedded C implementation and an existing internal R&D tool written in Visual Basic.

The implementation covered the complete communication behavior required by the production application, including framing and command handling, checksums / CRC, acknowledgements, retries, communication timeouts, error handling and device identification.

This allowed the application to communicate directly with the different controller families rather than relying on the previous production software.

Firmware Programming & Updates

The software supports two different firmware paths.

For initial programming of a blank microcontroller, the application integrates Microchip IPECMD for direct device programming. Because this operation works with an unprogrammed controller and requires greater access, it is restricted to appropriately authorized users.

For controllers that already contain the bootloader, firmware can be updated through the product’s normal infrared communication interface.

The update sequence is controlled by the application:

Identify controller → determine correct firmware → enter bootloader → transfer firmware → CRC verification → reboot → reconnect → verify firmware version

Once a programmed controller identifies itself, the software automatically selects the appropriate firmware version. This reduces the possibility of an operator loading firmware intended for another product.

I also optimized the update transfer for unused regions of the firmware image, allowing empty areas to be represented with fewer communication frames instead of transferring them byte-for-byte. Since firmware transfer had previously been one of the slowest production steps, this substantially reduced update time.

The new tool also made direct flashing practical for trained production employees on larger controllers, where the previous workflow had relied more heavily on slower update procedures.

Order-Specific Parameterization

The controllers were not produced with one universal configuration. Customers ordered devices with predefined settings such as operating temperatures, limits, enabled channels, device IDs and other controller parameters.

When an order is created, the ERP system generates an XML configuration file and a corresponding barcode is included on the production paperwork.

At the production station, the operator scans this barcode. The software uses the configuration number to retrieve the matching XML file from the server and loads the required parameters automatically.

This removed manual transcription of order-specific configuration data and reduced the opportunity for serial numbers, device IDs or parameter sets to be entered incorrectly.

Guided QA Workflow

After programming and parameterization, the same application guides the operator through the QA procedure.

The tests cover functions including temperature sensing, relay operation, controller communication, analog outputs and firmware version.

The physical test actions are performed by the production employee, while the application controls the sequence and records the results. The number of required checks adapts to the controller configuration, for example according to the number of active channels.

Steps cannot be performed out of sequence or silently skipped by normal production users. A failed test remains recorded as failed; only users with elevated permissions can perform exceptional actions where required.

A persistent concern during development was ensuring that the application could not enter an undefined state or fail midway through a test sequence in a way that disrupted production. The workflow and communication handling were therefore designed around predictable state transitions, explicit error handling and controlled recovery.

Traceability & Reporting

At the end of the QA process, the software automatically generates a PDF report for each individual device.

The report records the serial number, order number, firmware version, parameter set, test values, pass/fail result, operator and timestamp.

Reports are automatically named using the serial and order numbers and archived on the company’s network document storage.

Operator identity comes from the application’s authenticated user account, providing a traceable link between the device, production order, configuration, test result and employee who performed the QA process.

The archived reports can subsequently be retrieved by production management when the history of a specific device is required.

Production Impact

The application became the standard production tool across the company’s controller portfolio and has been used on several production stations by multiple operators.

It has processed thousands of devices per year and remained in active production use for at least two years.

The largest improvement was not a single software feature but the removal of manual and error-prone transitions between production steps. Barcode scanning replaced manual entry of serial numbers and order configuration, firmware selection became device-aware, QA followed a fixed sequence, and reports were generated and archived automatically.

Firmware programming and update times were also reduced substantially through faster direct-flashing workflows and optimization of the proprietary bootloader transfer.

Although no formal production-time study was performed, the combined changes produced a significant increase in throughput while reducing training requirements, paperwork, configuration mistakes, forgotten QA steps and rework.

For me, the strongest result of the project was seeing software I had architected and developed from scratch become part of the everyday production process for an established series-product portfolio.

Technologies

C# WPF MVVM Embedded Communication UART Infrared USB Proprietary Protocol Bootloader CRC Microchip IPECMD XML Barcode Workflow PDF Reporting Network Archiving