[x] I made serious effort to avoid creating duplicate or nearly similar issue
I have an automated test setup which works as follows:
[once] upload a jump stub in flash (which jumps to RAM)
compile a (usually very small) test app
put the CPU in reset and halt
upload to RAM, which is fast and avoids flash-wear
prepare SWO output (i.e. ITM uart mode on pin PB3)
take the CPU out of reset
capture SWO output until either an OK / FAIL line, or a timeout
rinse and repeat for each test (there are only two dozen so far)
rinse and repeat for a variety of µC families (half a dozen so far)
The whole process takes about 2s per test (5 min for about 140 tests).
This setup is driven by PlatformIO, and automated in Python.
BTW, I use MacOS and Linux for development.
The entr utility is used to re-run tests for every source file change, for the µC board I'm currently working on. I've found this to be very effective: adding functionality and chasing bugs is "near-interactive" this way.
I've been using OpenOCD until now, but it's slow as I haven't been able to keep it running across test runs (it messes up SWO streams). There's a lot of complexity which I don't use, and some of it seems obsolete.
Another stumbling block is the inability to make this work on Cortex M0+ (and STM32H7?). Obviously, that architecture has no ITM h/w, but it is very easy to bit-bang a fast serial output stream on the same PB3 pin, so the problem is really that the ST-Link refuses to pass through this data stream, since it insists that M0+ can't do it.
For more advanced testing later on, I'd also like to have the VCP serial port connected, to drive tests using commands sent to a "shell" listening on a UART for each µC (and with N boards attached, they could all run the same test sequence in parallel).
As I understand it, only one process can have the USB port open. You can't have one process constantly capturing all SWO output, plus one for the UART, while sending new code and resetting the µC a few times in a row through another process.
With stlink, there are tools for each use case, but I don't think they can be combined in a setup similar to what was described above right now, or at least I haven't figured it out ...
So this issue is really a prelude to a couple of questions:
Is there some way to create this kind of "fast test flow" right now?
Is there any interest in basing such an approach on stlink?
Is MacOS support dropped because of a lack of dev-involvement?
I'm not asking for help or for someone to do the work - merely trying to gauge the general level of interest if I were to start looking more seriously into this and submitting pull requests to this project.
PS. There's also the PyOCD project, but my impression is that it has ceased being worked on (no idea why).
PPS. FWIW, all my projects are open source, they're just not on github.
I have an automated test setup which works as follows:
This setup is driven by PlatformIO, and automated in Python. BTW, I use MacOS and Linux for development.
The
entrutility is used to re-run tests for every source file change, for the µC board I'm currently working on. I've found this to be very effective: adding functionality and chasing bugs is "near-interactive" this way.I've been using OpenOCD until now, but it's slow as I haven't been able to keep it running across test runs (it messes up SWO streams). There's a lot of complexity which I don't use, and some of it seems obsolete.
Another stumbling block is the inability to make this work on Cortex M0+ (and STM32H7?). Obviously, that architecture has no ITM h/w, but it is very easy to bit-bang a fast serial output stream on the same PB3 pin, so the problem is really that the ST-Link refuses to pass through this data stream, since it insists that M0+ can't do it.
For more advanced testing later on, I'd also like to have the VCP serial port connected, to drive tests using commands sent to a "shell" listening on a UART for each µC (and with N boards attached, they could all run the same test sequence in parallel).
As I understand it, only one process can have the USB port open. You can't have one process constantly capturing all SWO output, plus one for the UART, while sending new code and resetting the µC a few times in a row through another process.
With
stlink, there are tools for each use case, but I don't think they can be combined in a setup similar to what was described above right now, or at least I haven't figured it out ...So this issue is really a prelude to a couple of questions:
I'm not asking for help or for someone to do the work - merely trying to gauge the general level of interest if I were to start looking more seriously into this and submitting pull requests to this project.
PS. There's also the
PyOCDproject, but my impression is that it has ceased being worked on (no idea why). PPS. FWIW, all my projects are open source, they're just not on github.