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.
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! 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.
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
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.
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. The features are just right for DIY hobby projects.
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! 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.
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
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!
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.
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
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.
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