Automated Testing System for BootLoader Programming Based on Python

It takes ten years to grow trees, and a hundred years to cultivate people; it takes ten years to write software, and a hundred years to refine BT!

The BootLoader programming function is the most core foundational feature of the vehicle ECU, it is the “program of programs”, the mother of software, and the premise of all functional logic!!

Even if your ECU software is still blank, you still deserve to invest effort in perfecting the BootLoader module, because the latter is the road, and the former is the vehicle. Building the road is work that deserves our early planning and execution.

If the programming function is not done well, it may lead to weak control by car manufacturers, with various suppliers’ diverse programming tools and processes coexisting on the same vehicle; more seriously, it may require disassembling the ECU and returning it to the factory, which is extremely costly and inconvenient.

If the programming process is not standardized, another problem arises: you don’t know whether its “non-standardization” will cause issues.

Just because there are no problems now does not mean there won’t be in the future. For instance, if you change a chip or memory in your hardware, and if a problem occurs while programming the ECU, you will be confused about whether to ask the chip manufacturer to amend (continuing to tolerate this non-standard process) or to ask the diagnostic tool manufacturer to modify the upper computer process?

Introduction to the Testing Scheme

Consequently, vehicle technology joint developers have developed an automated testing system for BootLoader programming based on Python, which can fully automatically and strictly check whether the ECU programming steps are executed according to your company’s defined process.

Automated Testing System for BootLoader Programming Based on Python

Of course, programming successfully is not the goal; reliably programming it, ensuring it doesn’t fail, and never turning into a brick is our goal.

From this perspective, positive testing only ensures that the function can be realized and can be programmed successfully, while reverse exception testing holds greater significance as it ensures that the ECU is robust, follows commands, and never turns into a brick!

Our reverse testing includes

1. Programming condition testing.

For example, if a vehicle speed signal of 20 is given, the ECU is expected to fail the programming; then a vehicle speed signal of 0 should be given, and the ECU should succeed. In other words, if programmed twice, the first time should fail, and the second time should succeed, with the only difference being the condition signal (of course, other custom condition signals are also supported).

2. Exception unlocking programming.

First, simulate an incorrect key, proceed with the programming process, and it should fail; then simulate the correct key, and the ECU should succeed.

3. Block loss programming.

The programming data packets are numerous, starting from serial number 1. We can simulate skipping a certain data packet, and the ECU should fail the programming. Then do a normal programming again, and the ECU should succeed.

4. Programming under abnormal voltage conditions, including under-voltage and over-voltage.

Under-voltage especially tends to cause problems; the manifestation of the issue is that the ECU can still program at around 8V, which is unreliable and unsafe. Generally, the voltage range for the ECU is 9~16V; we can simulate an 8V voltage, then proceed with the programming process, and the ECU should return a prohibition on programming rather than struggling through. Afterward, set the voltage to 12V, and proceed with the programming process, the ECU should succeed.

This feels like some employees clearly being sick but still not resting at home, insisting on coming to work; this is against regulations! 😂

Correspondingly, there is also an over-voltage programming situation; you can first simulate a 17V power supply, then simulate a 12V power supply; the probability of issues arising is generally lower.

5. Data length anomaly.

For instance, when programming, if the requested length is 1000k, but you only transmitted 998k and exited, the ECU should also return a failure.

Then conduct a normal programming again; it must successfully program the software!

6. Checksum anomaly.

After the data transmission is completed, a checksum is performed. We can simulate an incorrect checksum, send it to the ECU, and the ECU should return a negative response.

Then conduct a normal programming process again; the ECU must successfully program the software!

7. Disconnecting constant power during programming.

8. Disconnecting constant power during erasure.

9. Durability testing.

……

These are just 8 examples, while in reality, the system can check up to 30 different conditions, aiming to verify whether the ECU is obedient and reliable, whether it follows commands, and whether it is robust enough!

It should be particularly noted that, except for durability testing, all other test items must result in the first conventional programming failing, and the second must succeed. If the second does not succeed, it indicates that this condition may lead to the ECU turning into a brick, and the BootLoader module has defects, or at least does not comply with the process!

In addition,it should be particularly noted that, this system supports one-click full automation execution, where all test parameters are pre-filled into an external document and read into the system. This document can be a txt, excel, or even a server’s json interface, greatly lowering the technical threshold for users.

After the automated testing is completed, it cangenerate exquisite test reports, making it very convenient for users to review test results and analyze abnormal causes.Report formats can be excel, word, pdf, html, or can be directly sent to the server API, aligning with your existing workflow.

It should be particularly noted that the test reports generated by this system are extremely detailed, recording and verifying every step and return value during the programming process, marking any discrepancies. It will record and statistically analyze the transmission situation of each block, helping you quickly find optimization directions.

Of course, most importantly, we can provide source code delivery and offer enterprise-level programming process customization, which is very beneficial for your subsequent capability development, programming function, and testing item upgrades and optimizations.

【Recommendation】

Lecture 10 on Buses, the best excel2dbc tool in the Eastern Hemisphere, always free to give away

Leave a Comment Cancel reply