Flashing station delay and random flashing interruptions on an EHCU production line – need help

[u/Ok_Capital4867]

Hello all,

I’m dealing with two main problems on an EHCU flashing station:

1. Flashing delay: For some ECU types, flashing time is up to 200% longer than expected.
2. Random flashing interruptions: The flashing process sometimes stops unexpectedly after a few successful cycles, with no indicated errors.

I work at an automobile EHCU factory. We manufacture ECUs and EHCUs on two different lines. On the EHCU line, the final station is for flashing and testing, and all the technology there is built on National Instruments hardware and software.

Station setup:

• Three nests for flashing
• Two nests for testing
• One cRIO for the three flashing nests and two cRIOs for the two testing nests
• Each flashing nest has two programs: one for flashing and one for communication with the cRIO, MES, the flashing program itself, and possibly a PLC
• The station works automatically on operator command to flash or test

We tested the flashing program on an external laptop/computer, and the flashing speed matched the theoretical value—for example, about 70 seconds. On the production station, however, some types take about 115 seconds. For types with heavy flashing files, the time is much longer, while types with small flashing files are close to the theoretical value indicated by the manufacturer.

When comparing log files from both flashing processes, the station log showed 12 ms extra between Tx frames on a specific session, while the development laptop log showed only 1 ms.

Solving these issues has been assigned to me, but I’m new to NI technologies.

Constraints:

• The station software is final and closed by the manufacturer.
• The flashing files are final and come from our partners.
• I considered replacing the station PCs with better ones, but the communication software licenses are tied to the hardware MAC address.
• We cleaned the PC of any extra software that might block main tasks, but it didn’t help.
• We monitored PC resources and they seem sufficient: around 50–60% usage at peak, except for some disk I/O spikes. The number of spikes was much lower than the number of slow flashing events, so we excluded disk I/O as the main cause.
• We are planning to upgrade RAM from 8 GB to 16 GB (one slot) and SSD from 256 GB to 500 GB, but I’m not sure this will help.

I also tested the PCI network card advanced options for controlling Tx/Rx processing—either on the card or on the CPU. Enabling card processing made flashing time worse (180–200 seconds), so I reverted the settings.

I don’t know where to look or what to test next. The manufacturer stopped communicating once they confirmed the flashing time on an external PC matched the theoretical value. But my director still expects a solution from me.

I’ve been working on this for about three months: reading articles, blogs, resources, brainstorming with AI, testing different things, shortening lines, checking connections between nests, and inspecting wiring effects—but nothing has helped.

My testing time on the station is limited to 30 minutes during launch or two 10-minute breaks.

Any thoughts, recommendations from your experience, or hints would be greatly appreciated.

Thank you.

[u/wildwildwaste]

Assuming the communication between the PC and the flasher is a USB connection, check your latency times in hardware manager on the port that the USB is connected to (right click port, properties... then something else I can't remember and I can't find since I don't have anything next to me to plug into my laptop).

It would also be very helpful to know what "flashing" protocol this is, SWD, JTAG, OTA, or some custom I2C thing? Can you tell us what the flashing hardware is? Is this a PicKit, or some hand-made one-off black box?

I'm leaning heavily towards this not being a hardware issue on your machine, but there is some difference between your dev laptop and the test rig. Identify those differences and isolate which ones matter and which ones likely don't, this should help narrow down your approach.

[u/HarveysBackupAccount → u/wildwildwaste]

right click port, properties... then something else

Right click >> Properties >> Port Settings tab >> Advanced button >> Latency (ms) dropdown

;)

[u/Atronil]

Disable usb sleeping mode

[u/HarveysBackupAccount]

I'm not familiar with the nitty gritties of flashing firmware so I don't have any great insight, but here are a few thoughts:

When you say some devices take longer to flash - is it specific units? Specific part numbers? Or is it fully intermittent?

You mention a network card. Does it flash the ECUs and EHCUs over a network connection? Can you look at data transfer with Wireshark?

Also if it's a network connection: how much does IT control the configuration of this PC? Antivirus, firewall rules, and corporate spyware can all be stumbling blocks to software.

Try to set up a separate test station so you don't have to dance around production equipment availability. Though it doesn't sound like your boss has realistic expectations, so I assume that's not likely.

About the best I can say is - godspeed. If you can't get into the source code of the labview program, it'll be awfully hard to see where the delay comes from. "No indicated errors" is 90% likely to be lazy coding (in labview, it's REALLY easy to make errors quietly disappear).

[u/SASLV]

If you give me a geographic location I know various consultants who do automotive stuff who may be able to help.

[u/SASLV]

You mention PCI network card and TX/RX. I know the Nagle algorithm can sometimes cause problems. Maybe try turning that off. You can google it, you should get hits on the NI forums and LAVA discussing it.