Bus Pirate 6 boards are half tested, and the factory ran into a snag. At some point we started using the flash serial number to get unique COM ports for each Bus Pirate. Well, around 200 tests the workstation ran out of visible COM port numbers.
This was not a problem for BP5 because we still do manufacturing testing with an older firmware. It evidently was a problem on BP5XL and BP6, but there was so much chaos it didn’t really get my attention. The factory just suffered through.
The other issue for manufacturing is the time needed to connect to a new serial port for each unit, instead of letting teraterm auto connect.
There is now a flag in pirate.h to disable unique COM numbers to build manufacturing testing firmware.
Just wanted to ensure you don’t miss this! There is now a solution for the problem of the FACTORY running out of assignable COM port numbers.
As of PR #162 and the build of ~1 hour ago, there are now four conditions, any of which will cause the BusPirate to enumerate without a unique USB serial number:
firmware was compiled with BP_MANUFACTURING_TEST_MODE (as previously)
storage was unformatted / corrupt / otherwise failed to mount
system configuration file (\bpconfig.bp) has a config setting to disable it
storage mounted properly and contains a file, \FACTORY.USB
In combination, this should allow the factory to avoid this problem.
For example, the following workflow might help visualize the minor changes needed:
When factory first connects a fresh buspirate device:
No unique USB serial number because the NAND storage will not have been formatted yet.
At some later point, factory will format the NAND storage…
Whatever script causes this must be updated to also immediately create in the root of that FAT volume, named FACTORY.USB.
That file’s existence will prevent subsequent reboots of the BusPirate from enumerating with a unique USB serial number, allowing the test process to reboot the device.
NOTE: This change must occur ANY time the onboard mass-storage device is re-formatted (as that will remove the file).
As a final step of the manufacturing process, just before disconnecting the device for the final time…
The factory scripts should delete the \FACTORY.USB file.
Can be done from terminal (rm FACTORY.USB)
If done from host, should then use Windows’ “safe remove” function to remove the BusPirate device (ensure file system contents are flushed from Windows Host point of view).
That’s all there is to it … should “just work” with minimal one-time changes and testing on the factory side.
Please let me know if this works for you.
Sincerely,
Henry
P.S. – And consider it an early Christmas present, Ian … since you can now just add the \FACTORY.USB file on your devices, and enjoy this factory-mode style behavior like you wanted.
Thank you so much! This is really great, and will save a lot of pain during manufacturing testing and development work.
I believe you asked in the git pull request if we should remove the old define that forces the manufacturing mode. I’m inclined to keep it if it’s not too much trouble.
Another thought: the way manufacturing testing works is really primitive compared to the v3.x. It is not automated at all, and it happens at 3 stages of production.
Before LCD is taped down
After the LCD is taped down
After going into the enclosure
They simply do the self test in a terminal with the ~ command. If the nand is not formatted, the self test reports that and offers to format. They hit yes the first time and the rest is history.
I could imagine a few scenarios that might automate the factory.usb slightly more, given our primitive testing setup. For example:
self-test format writes the factory.usb file (probably sufficient)
self-test format writes the factory.usb file with content “3” or “4”, each time the self test is run it de-increments the value and when 0 erases it. (in theory I like this, but in reality it will cause absolute chaos )
I don’t want to interfere with your factory test setup because there are probably good reasons for doing it the way you do, but might I suggest some improvements?
You have the SWD pins easily accessible for a jig. So why not use them?
For example what I’m doing in a factory test setup is using SWD for automatically programming the firmware. My firmware is usually also accessed via a CDC-ACM serial port over USB, just like the BP. What I have done in my regular firmware is add an additional serial port that can be accessed via RTT.
So I can use my regular firmware and access the shell either via USB or SWD+RTT. The RTT shell is then used by my automated test script that tests most of the functions that are testable without needing external connections. So I can use a minimal test jig that just connects power and SWD.
The test script is a simple python script that runs on linux and forks OpenOCD to flash the firmware and set up the RTT connection. This all runs on a small raspberry pi that is built into a box with the test jig. So I have a self-contained box that I can ship to the factory that does all the testing.
That’s definitely the way I like to do it, and similar to what we did for v3.x Bus Pirate (minus the RTT). We’ll get there I’m sure. For now it’s just easier to pay the factory to do it manually than find the time to get it put together. I imagine it happens some time in the middle of next year.
It would be quite easy to do this. RTT Channel 0 is currently setup for debug output. It would be quite easy to also add terminal output, and to check for terminal input. It’d just need to be well-tested.
I could also easily ensure all the debug output is sent to a different virtual terminal than the interactive one… it’s just a matter of adding two bytes to the start and end of each RTT_PRINT call.
With that done, only two steps would remain:
hook the calls to get a character, so that it reads from either / both the USB CDC and the RTT channel.
hook the output to print to both the USB CDC and the RTT channel.
This ties in nicely with an optimization I had in mind anyways, where the formatting of the printf()-like strings occurs once, and then gets sent to whatever output channel(s) are enabled … USB CDC (default), UART (config), RTT (default).
I’ve written this up as new GitHub Issue #164, in case someone wants to play with it.
Our test setup is two-fold: first test is just the bare boards, second test is the full product, mounted in a case and so on.
I was primarily writing about the first test of just the bare board. Just using SWD + power is important for us there, because we test all the boards that are on one panel while they are still in the panel. I run power + SWD in between the mousebites to a central connector on the panel frame. So the factory just has to plug the test jig into this connector and test test for one whole panel runs automatically. This is faster than having to connect each single board.
For the final test we also connect USB and other connectors. But catching a problem before having mounted everything in the case saves time, this is why we do the two-step testing.
