Thanks for sharing your work. I am also implementing a complex factory testing solution for our devices so it was helpful to see how someone else solved for their uses case.
Great idea! Could have used something like this on so many occasions. Automatic SWD programming is a messy affair, while the bus protocol is the same for ARM MCUs anyway, details like how to disable/reset/bypass security, the flash size and what address its located at, fuse bits and many other concerns are all highly variable. It might be possible to do it from an MCU for a handful of specific devices or maybe device families but making it general purpose would be very challenging. Without a doubt involving a small embedded Linux and controlling a debug access probe over USB via OpenOCD would be more versatile. Also opens the door to deploying new binaries over wifi (or even cloud) or doing remote debugging. Modern MCUs with ROM bootloaders make everything way easier -- imagine just loading a firmware bin over USB if the DUT comes online. Many also work over uart, spi or i2c and could be simpler than doing it over SWD.
Yeah, you're confirming my fears about that integrating the programmer. Linux with OpenOCD is an intriguing thought though. I've looked into using the bootloader before, but I'd think that would vary between brands and microcontrollers. I need to look into it more though.
This is really impressive. Thank you for going through all the details of the project. Also, the there is the free-dap firmware that can be used on an RP2040 that turn it into a usb SWD programmer. Maybe the firmware could be modified not to require USB? Probably a lot of work though. Alternatively, a Pi Zero can act as a SWD programmer directly from its GPIO. That would probably be the easiest option.
Good to know, I'll look into that. I've also seen the code for several other debug probes, but I think the hard part is going to be replicating what the computer/IDE/programming software are doing.
Great idea! I'd love a kit or a pre-assembled version. It would be really useful, especially compared to sending boards off to JLCPCB for assembly and getting five back when I only need one. I've been experimenting with this myself and trying to print the results to a BLE thermal printer, like the ones from Opulo.
Great video! This looks great tool for small hardware projects. In my day job is do test automation for electronics and I can really see the value of this for the open source community. On the ISP side: For AVR based Boards there is the "Standalone AVR programmer" by adafruit might be interesting for your project. Keep up the great work. - Max
Very cool project! As I have several PCBs I do small scale production (like 30-50 in one batch mostly), it would be very valuable to have such an automation tool for testing to confirm that the PCBA manufacturer (which happens to be your sponsor for me as well, by the way) didn't mess something up. ;-) Few comments/suggestions: - I didn't fully understand how the test procedure works: I would expect that after the test has been completed the display shows a big green "PASSED" or red "FAILED" as a result. The text protocol is nice, but I would only look at it if a test has failed to get more details what possibly to rework. - At your interface to the PCB under test I saw I2C and SPI, but I was missing UART which I would consider important as well. - Flashing the firmware should directly be done with this tool as well providing a "firmware.bin" file on the SD card. I mainly use RP2040 micro controllers which do support SWD interface. So I hope flashing the firmware automatically can be implemented.
Thanks for the great comments! -Yes, I should add some feedback on the display to show pass/fail and what errors occurred. Adding more pages to the display is on the list, but it is a bit time consuming. -UART would be nice, I just figured I2C and SPI are more commonly found on ICs. I ran out of pins on the Nucleo, but on the next revision I plan to add a second I2C expander to free up a bunch of those pins, and I could add UART back (even if just for debugging) -I agree with your last point, but it looks pretty challenging to implement from my limited research. There was the idea to run Linux with OpenOCD though, which was intriguing, but of course getting hardware to run Linux means a total redesign -I'm also planning to add voltage/current monitoring, which I think would be great for real time probing
Interesting, I've been thinking about some way to help with measuring boards but rather for reverse-engineering… Did you think about interoperating with projects like OpenBoardData, surely these scripts can be converted and published there to help people repair them later ?
I'll just throw the thought that custom scripting can be a effort sink in programming, so using a third party library can be a saver. I've only actually used a lisp-like in an STM32F4 called lispBM
This is perfect for what I was planning! Except I’m going to use AVRs instead of STMs. My project is to make an LM3914 replacement board, because you can’t buy those chips anymore. At least not from a vendor that can automatically solder them. Why. My requirement is that I can load it up with a memory card, plug in the board under test, program it, then have it read the LEDs and check resistances and power consumption and stuff. Most importantly, to do so in an idiot-proof method. There’s already code for an AVR field programmer out there, I’ll likely take that and add my own debug code atop it.
I should look more into JTAG, my understanding is it is a bit more versatile. It can also be used for FPGAs, so it could really open up some possibilities
Why such a small current to determine resistance values or it it changed in code and I'm missing the point ? There are going to be noise issues with low current. I'm a bit puzzled by needing 10's of thousands of lines of code to be written. The HAL is available for interfacing standard devices and there is a lot of pre-written code from ST.
For large resistances you need a very small current to keep the voltage within something readable by an ADC. There's also the risk of damaging the part you're trying to read if the voltage goes too high. I intend to average multiple readings in a future version of the code to help with noise, but it isn't too bad at the moment. Tens of thousands is probably exaggerating a bit. There's probably around 10,000. The interface/GUI is quite a lot of code, display and ADC drivers are also substantial. I use libraries when worth it (for things like USB, graphics, HAL), but I like to write my own as well. That way I know exactly how the part works and what the code is doing. Very useful when it comes to debugging.
@@AllTradesZach Why not split the technique for low and high separately ? It doesn't have to be one or the other. I would put some signal conditioning in anyway to protect the ADC. Software is so bloated today and not just for ST - it's the way everything has evolved. I can understand using libraries for USB and graphics. I remember writing code for a Texas microcontroller in the 1980's for a battery powered data acquisition system. It came to about 300 lines of assembler - and the code was dead reliable once it had been debugged ! How things have changed. I would be interested to see your code.
Thanks for sharing your work. I am also implementing a complex factory testing solution for our devices so it was helpful to see how someone else solved for their uses case.
Great idea! Could have used something like this on so many occasions.
Automatic SWD programming is a messy affair, while the bus protocol is the same for ARM MCUs anyway, details like how to disable/reset/bypass security, the flash size and what address its located at, fuse bits and many other concerns are all highly variable. It might be possible to do it from an MCU for a handful of specific devices or maybe device families but making it general purpose would be very challenging. Without a doubt involving a small embedded Linux and controlling a debug access probe over USB via OpenOCD would be more versatile. Also opens the door to deploying new binaries over wifi (or even cloud) or doing remote debugging.
Modern MCUs with ROM bootloaders make everything way easier -- imagine just loading a firmware bin over USB if the DUT comes online. Many also work over uart, spi or i2c and could be simpler than doing it over SWD.
Yeah, you're confirming my fears about that integrating the programmer. Linux with OpenOCD is an intriguing thought though.
I've looked into using the bootloader before, but I'd think that would vary between brands and microcontrollers. I need to look into it more though.
This is really impressive. Thank you for going through all the details of the project.
Also, the there is the free-dap firmware that can be used on an RP2040 that turn it into a usb SWD programmer. Maybe the firmware could be modified not to require USB? Probably a lot of work though.
Alternatively, a Pi Zero can act as a SWD programmer directly from its GPIO. That would probably be the easiest option.
Good to know, I'll look into that. I've also seen the code for several other debug probes, but I think the hard part is going to be replicating what the computer/IDE/programming software are doing.
Great project! I've been having fun with the Puya PY32002A - can't beat a $0.12 ARM Cortex M0+, and SWD debugging is a total game changer.
Great idea. The features are just right for DIY hobby projects.
You should make a wine rack....
Great idea! I'd love a kit or a pre-assembled version. It would be really useful, especially compared to sending boards off to JLCPCB for assembly and getting five back when I only need one. I've been experimenting with this myself and trying to print the results to a BLE thermal printer, like the ones from Opulo.
Not just the boards, the economies of scale on some of the components are huge as well!
Great video! This looks great tool for small hardware projects. In my day job is do test automation for electronics and I can really see the value of this for the open source community. On the ISP side: For AVR based Boards there is the "Standalone AVR programmer" by adafruit might be interesting for your project. Keep up the great work. - Max
Very cool project! As I have several PCBs I do small scale production (like 30-50 in one batch mostly), it would be very valuable to have such an automation tool for testing to confirm that the PCBA manufacturer (which happens to be your sponsor for me as well, by the way) didn't mess something up. ;-)
Few comments/suggestions:
- I didn't fully understand how the test procedure works: I would expect that after the test has been completed the display shows a big green "PASSED" or red "FAILED" as a result. The text protocol is nice, but I would only look at it if a test has failed to get more details what possibly to rework.
- At your interface to the PCB under test I saw I2C and SPI, but I was missing UART which I would consider important as well.
- Flashing the firmware should directly be done with this tool as well providing a "firmware.bin" file on the SD card. I mainly use RP2040 micro controllers which do support SWD interface. So I hope flashing the firmware automatically can be implemented.
Thanks for the great comments!
-Yes, I should add some feedback on the display to show pass/fail and what errors occurred. Adding more pages to the display is on the list, but it is a bit time consuming.
-UART would be nice, I just figured I2C and SPI are more commonly found on ICs. I ran out of pins on the Nucleo, but on the next revision I plan to add a second I2C expander to free up a bunch of those pins, and I could add UART back (even if just for debugging)
-I agree with your last point, but it looks pretty challenging to implement from my limited research. There was the idea to run Linux with OpenOCD though, which was intriguing, but of course getting hardware to run Linux means a total redesign
-I'm also planning to add voltage/current monitoring, which I think would be great for real time probing
Interesting, I've been thinking about some way to help with measuring boards but rather for reverse-engineering… Did you think about interoperating with projects like OpenBoardData, surely these scripts can be converted and published there to help people repair them later ?
I'll just throw the thought that custom scripting can be a effort sink in programming, so using a third party library can be a saver. I've only actually used a lisp-like in an STM32F4 called lispBM
Which display are you using?
This is perfect for what I was planning! Except I’m going to use AVRs instead of STMs. My project is to make an LM3914 replacement board, because you can’t buy those chips anymore. At least not from a vendor that can automatically solder them. Why.
My requirement is that I can load it up with a memory card, plug in the board under test, program it, then have it read the LEDs and check resistances and power consumption and stuff. Most importantly, to do so in an idiot-proof method. There’s already code for an AVR field programmer out there, I’ll likely take that and add my own debug code atop it.
Power and voltage monitoring are things I'd like to add to the next revisions!
I really like this project. Did you consider JTAG also? From what if read you could use that to run tests in the ICs themselves.
I should look more into JTAG, my understanding is it is a bit more versatile. It can also be used for FPGAs, so it could really open up some possibilities
from where did you get the display? Could you link it?
It's a little pricey for what it is, but here: www.digikey.com/en/products/detail/newhaven-display-intl/NHD-1-8-160128UBC3/23334148
Why such a small current to determine resistance values or it it changed in code and I'm missing the point ? There are going to be noise issues with low current. I'm a bit puzzled by needing 10's of thousands of lines of code to be written. The HAL is available for interfacing standard devices and there is a lot of pre-written code from ST.
For large resistances you need a very small current to keep the voltage within something readable by an ADC. There's also the risk of damaging the part you're trying to read if the voltage goes too high. I intend to average multiple readings in a future version of the code to help with noise, but it isn't too bad at the moment.
Tens of thousands is probably exaggerating a bit. There's probably around 10,000. The interface/GUI is quite a lot of code, display and ADC drivers are also substantial. I use libraries when worth it (for things like USB, graphics, HAL), but I like to write my own as well. That way I know exactly how the part works and what the code is doing. Very useful when it comes to debugging.
@@AllTradesZach Why not split the technique for low and high separately ? It doesn't have to be one or the other. I would put some signal conditioning in anyway to protect the ADC.
Software is so bloated today and not just for ST - it's the way everything has evolved. I can understand using libraries for USB and graphics. I remember writing code for a Texas microcontroller in the 1980's for a battery powered data acquisition system. It came to about 300 lines of assembler - and the code was dead reliable once it had been debugged ! How things have changed.
I would be interested to see your code.
Guys, you both sound so logical, thanks for all the insight you made me gain from this discussion of yours!
@@RainLovesCobain 😁