AVR Parallel Programming Testbed

The machine required a lot of software which I had to wrote. We need to log every fault of the target pcbs, generating and writing a serial number. A GUI for the worker. Software for the Slaves, Testsoftware for the Targets, Bootloader for the Slave and the Target and so on.

Master Controller

The worker needs a GUI, that he can see, if there is a problem with the targets. The GUI also shows the system state, the number of panel for each version of the target PCB.
In the background the software also logs the states of the PCBs.
The main routine is the controlling of the test and the programming of the targets. The software talks to each slave controller and tell them, what to do.

Slave Controller

The slave controller is a AVR programmer and Target tester. The software implements the ISP Protocol, the test routines. For Testing, the target gets a special test software. The slave talks to the tarket and read or measure results. Each test is controlled by the master. After each test, the master require the test result from every slave.

For easier handling, the slaves has a special bootloader. This bootloader doesn't answer unless the Upload Tool told him to do. The reason is, that all slaves are on the same wire and talk via UART.

Target

The target needs three parts of software. The test software, the bootloader and the final software. The master send the test software via the slave to the targets and perform the hardware test. If the test went fine, the bootloader will be flashed. Because for our special hardware design of the product, I wrote a special bootloader. When the bootloader is flashed and the serial number is set, the final software will be flashed. I didn't merge the both hex files of the bootloader and the final image for some reason. One of them is, that I can even test the bootloader in that way, that the flashing doesn't went wrong.

Finally, the Master runs a test to check the final firmware output.

Conclusion

There is a lost software and hardware which needs to play together. Sometimes it was a tricky task to find bugs. But today, after one year, the machine went fine. All hardware problems the machine found were correctly discovered. And thousands of PCBs were tested and programmed.

After some research and some test I came to following solution:

We will need a Master, which displays the current state of each target. Also this Master holds the target software. For some reason (price and size) i choose a Raspberry Pi 3 with Wifi and Bluetooth.

The Slave are based on an Atmega328PB which was brand new that days. The reason is that I need two serial Interfaces. One for the communication with the Master and on for the targets. Because our target have AVR Microcontrollers too we will have no problems even without level shifting.

The communication between the master and the slaves is a UART based bus. To prevent any weird behavior the slaves are not aloud to send anything as long they are not getting a specific command. Each slave has an individual address. The master can choose each slave individually or broadcast to all.

The slaves can communicate with the targets normal via UART. Also, each slave measure the current of his target, enable and disable the power, can measure some voltages. For USB test, there is a USB Host chip on each slave.

When I start the development, I needed to consider the demands for testing and programming. We had two different kind of PCBs which need to be tested and programmed. They had only the programming interface in common, ISP.

What I need to test:

• 5V / 3.3V Output
• Motor controller Output
• Current
• LED
• Communication Interface
• USB
• I2C Interfaces
• Eeprom

USB means here, that one PCB can be an USB Device, that makes a USB Host functionality necessary.

Our panels are designed for 20 PCBs. They all should be tested and Programmed as fast as possible. We need a system which makes all parallel.

Other Requirements:

• generate and set a Serial number to each Target PCB
• log Serial number and test results
• GUI for the Worker to identify problems easily
• One Pushbutton control
• Simple Setup
• Testbed update possible

All together I needed 3-4 month with the development.