LeafLabs Garden » Topic: JTAG pins on Maple-mini?

LeafLabs Garden » Topic: JTAG pins on Maple-mini? http://forums.leaflabs.com/topic.php?id=74300 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:08:54 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php tormod on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105352 Fri, 25 Apr 2014 17:59:31 +0000 tormod 105352@http://forums.leaflabs.com/ > P.S: I actually had to take the main Maple boot-loader source code and manually edit and recompile it to work on the Maple-mini, since I could not find a copy anywhere in the repository. The Maple Mini bootloader is in the "mini-boot" branch on <a href="https://github.com/leaflabs/maple-bootloader" rel="nofollow">https://github.com/leaflabs/maple-bootloader</a> But you are anyway better off using your port of the main Maple bootloader, since it has fixes and features that have not been folded into the mini-boot branch. I don't think it was a good idea to try to maintain these flavours in different git branches, they should rather build from one file using defines. Can you please post the diff of your Maple Mini modification? gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105339 Tue, 15 Apr 2014 03:10:14 +0000 gruvin 105339@http://forums.leaflabs.com/ Success with ST-Util and GDB I have returned to have another look at <a href="https://github.com/texane/stlink">ST-Util</a> and GDB, rather than OpenOCD. Now that I understand the difference in commands needed to make it work, it would appear that st-util and gdb are working very well together. Here's how I set things up, using the Maple-ini bootloader as a test ... First, I create a convenience file of commands to run when I launch gdb ... <blockquote><pre><code>FILE:gdb-st.rc --- set remote hardware-breakpoint-limit 6 set remote hardware-watchpoint-limit 4 target extended-remote :4242 monitor reset halt load</code></pre> </blockquote> That assumes that st-util is already running, of course. The <code>load</code> instruction in there actually flashes the STM32 chip with the program supplied on the command line, when GDB is launched (though I might take this out, if not needed, to save Flash cycles), which I do like this ... <blockquote><pre><code>$ cd ~/libmaple/maple-mini-bootloader $ arm-none-eabi-gdb -x gdb-st.rc build/maple_boot.elf</code></pre> </blockquote> You need to be in the directory containing the C source file, when you launch GDB. From there, I can do things like this ... <blockquote><pre><code>(gdb) monitor reset halt (gdb) break main Breakpoint 1 at 0x80008a2: file main.c, line 37. (gdb) c Continuing. Note: automatically using hardware breakpoints for read-only addresses. Breakpoint 1, main () at main.c:37 37 systemReset(); // peripherals but not PC (gdb) list 32 */ 33 34 #include "common.h" 35 36 int main() { 37 systemReset(); // peripherals but not PC 38 setupCLK(); 39 setupLED(); 40 setupUSB(); 41 setupBUTTON(); (gdb) n 38 setupCLK(); (gdb) n 39 setupLED(); (gdb) s setupLED () at hardware.c:104 104 rwmVal |= 0x00000008; (gdb) where #0 setupLED () at hardware.c:104 #1 0x080008ae in main () at main.c:39 (gdb) list 99 // todo, swap out hardcoded pin/bank with macro 100 u32 rwmVal; /* read-write-modify place holder var */ 101 102 /* Enable APB2 clock (GPIOB) */ 103 rwmVal = GET_REG(RCC_APB2ENR); 104 rwmVal |= 0x00000008; 105 SET_REG(RCC_APB2ENR, rwmVal); 106 107 /* Setup GPIOB Pin 1 as PP Out */ 108 rwmVal = GET_REG(GPIO_CRL(GPIOB)); (gdb)</code></pre> </blockquote> Pretty cool. Every now and then, I get a glitch occurring when, evidently, an IRQ routine is running and I hit <code>Ctrl-C</code>. It's usually OK, but sometimes,odd things happen. I've seen one way to get around that, but the command <code>mon cortex_m maskisr on</code> is not accepted by my set-up. So still looking into this one. Well I guess that about wraps up this thread. We got there in the end. P.S: I actually had to take the main Maple boot-loader source code and manually edit and recompile it to work on the Maple-mini, since I could not find a copy anywhere in the repository. That was because I wanted to use the Maple-mini for these experiments, having experienced obscure, yet to to be resolved issues with the Maple (see earlier in thread). gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105337 Tue, 15 Apr 2014 00:49:56 +0000 gruvin 105337@http://forums.leaflabs.com/ My ST-Link/V2 arrived. Hooked it up. Ran OpenOCD using ... <blockquote><pre><code>openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg</code></pre> </blockquote> .. and all seems to work as expected (with my Maple-mini at least) right off the bat. Yay \o/ I'm quite surprised, considering I'm running on a Mac. That said, whether with the Olimex interface or the ST-Link/V2, GDB isn't really working right -- just as before, though I didn't mention it, thinking it was just me, learning the ropes. Break points don't always break. Continue and next do weird things. Not sure what that's all about. Will continue Googling. I also tried st-util, which seems to work about the same for just flashing etc. But GDB with st-util is a complete fail. All kinds of crazy problems -- can't access memory address xyz etc. So, it looks like I can flash my .bin files reliably. But I still don't have a properly functioning debugger. Rats. :-/ gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105336 Mon, 14 Apr 2014 21:36:41 +0000 gruvin 105336@http://forums.leaflabs.com/ Oh and by the way ... GDB is not actually much use for debugging C code written, compiled and uploaded by the MapleIDE. That's because the bootloader is always part of the program, even though it's not actually part of the program being compiled. So GDB cannot determine the correct memory addresses etc. You can debug at assembler level however, though that's not much fun, when your original code was C. So all in all, as far as Maples and the MapleIDE go, being able to flash a new bootloader is about all JTAG is really useful for. Wouldn't it be super cool if the MapleIDE supported live debugging. But I don't suppose that is ever gonna happen. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105335 Mon, 14 Apr 2014 21:16:38 +0000 gruvin 105335@http://forums.leaflabs.com/ Re-visiting the JTAG 20-to-8 pin adapter Having realised that I never connected Vcc when I was first trying to use the JTAG adapter (see above) I returned again to see if in fact, the adapter works as expected, when connected correctly. First, the Maple(not -mini) To make things easier (or so I thought!) I switched from my Maple-mini to my full Maple (with STM32F103RBT6 chip) simply because it had the convenient 8-pin JTAG connector pads already. With the Maple(not -mini), the JTAG adapter sort of, kind of, seems to work with the Olimex ARM-USB-OCD. That is to say, I can get it to flash the boot loader, if I muck about trying reset and then halt several times and then the <code>stm32f1x mass_erase</code> and <code>flash write_bank</code> commands. The results are unreliable and flakey. When the system reports that flashing was successful, then it actually was. But it only seems to work at all about 2 in every 5 attempts. I then played around with GDB, using the maple-bootloader's maple_boot.elf/bin files for the test. This was also highly unreliable, whereas again, I had not difficulty on the Maple-mini. I tried connecting to this same Maple directly, without the JTAG adapter, like how I had success with the Maple-mini. But I could not get that to work properly, either. Same basic problems. Worked sort of, kind of, some of the time. Testing the JTAG 20-to-8 pin adapter again on the Maple-mini So then I figured I better try the JTAG adapter again on the Maple-mini, just to be sure. I wired up everything, including the hard /RESET line. That didn't work so well. I removed the hard /RESET connection (JTAG/8 pin 8) and everything worked very well, just as with my direct connections, mentioned earlier. GDB appears to work reliably with my Maple-mini and the JTAG adapter, also. Summary The JTAG 20-to-8 pin adapter works -- but there are strange issues perhaps with OpenOCD and/or the Olimex ARM-USB-OCD. TODO - Test the ST-Link/V2 with OpenOCD 0.8-RC1 I expect my 'genuine' ST-Link/V2 to arrive tomorrow. I see that OpenOCD does support that interface. So it will be interesting to see if things work better, by changing just the hardware interface and keeping everything else the same. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105334 Mon, 14 Apr 2014 16:33:29 +0000 gruvin 105334@http://forums.leaflabs.com/ Those functions for enabling/disabling the JTAG debug ports on the Maple-mini (or others) are as follows ... <blockquote><pre><code>disableDebugPorts() enableDebugPorts()</code></pre> </blockquote> I found this information on <a href="http://leaflabs.com/docs/jtag.html">JTAG documentation page</a>. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300&page=2#post-105333 Mon, 14 Apr 2014 16:20:22 +0000 gruvin 105333@http://forums.leaflabs.com/ I have now resolved the issue preventing OpenOCD and the Olimex ARM-USB-OCD from working under OS X. Turns out that the FTDI driver explicitly includes the Olimex vendor/product IDs and loads serial drivers for the two devices there-in. This prevents OpenOCD from claiming the same ports. Since I have no need to directly access these serial ports, they can be disabled. One (sledgehammer) way of doing this is to simply unload the FTDI kernal driver. <blockquote><pre><code>sudo kextunload -bundle com.FTDI.driver.FTDIUSBSerialDriver</code></pre> </blockquote> Try that as a first test, to see if <code>openocd</code> will run now. It should. If not, you may be using the Apple FTDI driver. You can probably find out the name of the driver by running ... <blockquote><pre><code>sudo kextstat | grep FTDI</code></pre> </blockquote> If unloading the FTDI kernal extension (driver) works, then we're almost there. The problem now is that none of your other FTDI USB devices will work. Luckily, we are able to disable only the Olimex serial device needed by <code>openocd</code> ... <blockquote><pre><code>sudo vi /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist</code></pre> </blockquote> In that file, we find the Olimex keys and comment them out ... <blockquote><pre><code><integer>1027</integer> </dict>  <key>Olimex OpenOCD JTAG B</key> <dict> <key>CFBundleIdentifier</key> <string>com.FTDI.driver.FTDIUSBSerialDriver</string></code></pre> </blockquote> The <code><--</code> ... <code>--></code> part is the commented out section. Now unload and reload the kernel extension, to make the changes take effect ... <blockquote><pre><code>sudo kextunload -bundle com.FTDI.driver.FTDIUSBSerialDriver sudo kextload -bundle com.FTDI.driver.FTDIUSBSerialDriver</code></pre> </blockquote> NOTE: The Olimex ARM-USB-OCD has two serial devices. One is available externally on a DB9 connector. OpenOCD only uses the first port, which is why we only commented out the first of the two ports in the FTDI driver <code>Info.plist</code> file, above. This lets you still have access to the DB9 serial port. You should now still be able to use <code>openocd</code>, while at the same time having the use of any other FTDI USB devices you may have plugged in -- including the DB9 serial port exposed on the Olimex OCD, which shows up on my system as <code>/dev/cu.usbserial-FTWZWBC0B</code>. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105332 Sun, 13 Apr 2014 23:07:18 +0000 gruvin 105332@http://forums.leaflabs.com/ OK. I got there in the end. Yay \o/ Turns out that I was using the Maple (RET6?) bootloader source code, which is all the instructions mention where I was reading and differs from that needed by the Maple-mini hardware. When I fixed that, suddenly everything worked. Go figure! So, to summarise my set-up to get things working ... <ul> <li>Firstly -- Throw away most of the How-To documentation you may find on the web. It's all out-dated and in some cases just plain wrong -- this includes documentation linked from the current Olimex ARM-USB-OCD product page itself, especially the one noted as "excellent". Grrrr.</li> <li>I am using an Olimex ARM-USB-OCD(not-H)</li> <li>I connected the relevant JTAG pins directly, from the 20-pin JTAG header to the Maple-mini, as describe previously. The cut-down version of 20-pin to 8-pin adapter mentioned in the Leaflabs wiki -- the one with only three resistors -- does NOT work. The one shown in the circuit-diagram on the wiki page itself, might.</li> <li>I had to include JTAG-20 pin 1 -- input voltage reference, connecting it to Vcc on the Maplie-mini. </li> <li>I am running OpenOCD v0.8-RC1, under Ubuntu Linux (because it won't work under OS X with the Olimex FTDI stuff)</li> <li>To start <code>openocd</code>, there is no need for some custom .cfg file (as all those howtos etc say there is). Simply run ... <blockquote> <code>openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg</code> </blockquote> </li> <li>Use the <a href="http://static.leaflabs.com/pub/leaflabs/maple-bootloader/maple_mini_boot.bin">boot-loader code for the Maple-mini</a> -- NOT the source version, like their instructions say. That one is presumably for the Maple RET6 and uses completely different pins for the LED and USB disconnect circuitry! </li> <li>From there, follow the instructions on the <a href="http://wiki.leaflabs.com/index.php?title=Maple_JTAG_How_To">Maple JTAG How To</a> wiki page, only with some changes, thus ... <blockquote>` $ telnet localhost 4444 ... At the prompt, type one by one, ... reset halt flash probe 0 stm32f1x mass_erase 0 flash write_bank 0 <full-path-to>/build/maple__mini_boot.bin 0 reset ` </blockquote> </li> </ul> I think that's about it. Oh. One more thing. Don't be a numbnutz like me and expect your system's default <code>gdb</code> to be able to debug your ARM chip. You need to be running the version of gdb that comes with with your cross toolchain. In my case, that was <code>arm-none-eabi-gdb</code>. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105331 Sun, 13 Apr 2014 20:45:55 +0000 gruvin 105331@http://forums.leaflabs.com/ OK. So now I have been able to, apparently, flash the bootloader on a Maple-mini clone I made. <blockquote>` $ telnet localhost 4444 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger > reset JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) > halt target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x21000000 pc: 0x08000a48 msp: 0x20004fd0 > flash probe 0 device id = 0x20036410 flash size = 128kbytes flash 'stm32f1x' found at 0x08000000 > stm32f1x mass_erase 0 stm32x mass erase complete > flash write_bank 0 .../maple-bootloader/build/maple_boot.bin 0 wrote 12180 bytes from file /home/bryan/vista/libmaple/maple-bootloader/build/maple_boot.bin to flash bank 0 at offset 0x00000000 in 0.417124s (28.516 KiB/s) > reset ` </blockquote> But it's not executing. After a power cycle, the chip just sits there, seemingly doing nothing. If I use JTAG to again to halt whatever it's doing, it always seems to break at the same address: <code>0xfff7fffe</code>. This suggests to me that some error condition is being trapped and my bootloader code is simply not executing. I am guessing (and soon to scour over data sheets again) that some kind of additional configuration is required to put the SMT32F103 into the right mode or whatever. Trying to find out about this is proving hard going. Seems still that STM32 chips are for men, not boys. :-P gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105330 Sun, 13 Apr 2014 19:28:48 +0000 gruvin 105330@http://forums.leaflabs.com/ Some success, at last! (Evidently. I didn't abandon all hope. ;-) ) I threw out the 20-pin to 8-pin adapter board and connected directly to the 20-pin JTAG header on the Olimex ARM-USB-OCD. Still no go, until I read the documentation to reveal that pin 1 is an input voltage reference. Once I connected that to Vcc on the Maple-mini, hey presto! OpenOCD now communicates successfully with my STM32F103, when my Maple-mini is locked in bootloader mode. Yay \o/ From here, programming and JTAG in-ciruit debugging should proceed much more smoothly. Incidentally, it turns out that there's no need, far as I can tell so far, to write a custom <code>openocd.cfg</code> file. With openocd v0.8-RC1 compiled and installed, all I needed was this ... <code>openocd -f interface/ftdi/olimex-arm-usb-ocd.cfg -f target/stm32f1x.cfg</code> - - - The problems I was having with the Olimex programmer coming and going and being generally unreliable appear to have also been caused by the JTAGE adapter board, somehow loading down the power supply or something. I checked the design once more against the adapter board design mentioned in the Leaflabs <a href="http://wiki.leaflabs.com/index.php?title=Maple_JTAG_How_To">wiki</a> (JTAG Adapter section) and published <a href="https://github.com/adamfeuer/maple/tree/master/jtagadapter">here</a>. My board is definitely correct, in every detail. But this board does NOT work, at all. So not sure what's up with that. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105329 Sun, 13 Apr 2014 16:36:48 +0000 gruvin 105329@http://forums.leaflabs.com/ Ob boy. So I've read everything I can find on the Black Magic probe and I cannot see for sure if it supports gdb's "remote put" command to upload (Flash) my code -- or indeed any examples, showing parameters that would surely be required to select what location the upload goes to (Flash, RAM, what address, etc.) So again, I find myself completely lost. :'( Should I abandon all hope in open source, poorly documented software and devices and just buy an ST programmer and use their proprietary software? (If there is any. Haven't been able to find that yet, either. :'( ) Atmel and Microchip make this SO EASY. WTF is up with ST? I'm really frustrated. gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105328 Sun, 13 Apr 2014 16:15:28 +0000 gruvin 105328@http://forums.leaflabs.com/ Oh dear. I don't see any support in OpenOCD for the Black Magic Probe. Oh but, "... if you are using gdb, there is no other software to bridge between gdb and the STM32 MCU; gdb talks 'directly' to the Black Magic Probe." OK. Need to do more reading, for this and to learn how the BMP implements good old fashioned Flash programming, for which GDB, AKAIK, is of no use. Then of course, I am going to run in to issues with the existing recommended Libmaple <code>make jtag</code> and <code>make debug</code> directives. Yet more hacking to be done, no doubt. Goodness me. This is really turning out to be so much more than I bargained for. Still, what doesn't blow your mind, makes you smarter! :-P gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105327 Sun, 13 Apr 2014 16:12:34 +0000 gruvin 105327@http://forums.leaflabs.com/ Thanks again. Lots to look into there. Seems like I'll now have to buy a Black Magic Probe, in hopes that it works more reliably. I bought the Olimex ARM-USB-OCD purely because the Leaflabs <a>JTAG wiki</a> (JTAG Debugger section) recommended it -- first and foremost. In practice though, let's just say that my opinion of the product is now very low. It has all kinds of silly issues around initialising when plugged in and even staying connected to the USB bus -- especially in a virtual machine Ubuntu environment, such as I am forced to use on my Mac, which itself is very disappointing. Software wise, everyone (including Leaflabs) seem to think that OpenOCD is the way to go. From what I've been able to glean from further research, OpenOCD does provide a gdb bridge for the STM32 series chips. In fact, this seems to be among their primary points of focus at present -- see the video linked on their home page just now. So, I've now read up on a fair bit of OpenOCD's documentation and am gaining an appreciation for why it is, "incredibly complex". It attempts to be many things! The more I learn of course, the less complex it really is. If only the hardware was playing ball. Historically (personally) programming an MCU has always been as simple as wiring up a cheap (often home made) programmer to the right pins, launching some program, selecting the device in question, loading the bin/hex file and clicking, "Program". It is certainly this way for Microchip PIC and Atmel chips I have been familiar with and I've been doing it effortlessly for many years. In-circuit debugging is a breeze too, but a proprietary affair, often only supported under Windows. In any case, OpenOCD and these "programmers" we are discussing are more than that. They are for in-circuit debugging and even JTAG boundary scanning, which is something I looking forward to finally being able to do, since it will help greatly for testing of boards in the small production runs I tend to do. STM32 chips are clearly much less obvious in terms of how to connect them up get code into them, let alone in-circuit debug and ST doesn't seem to prioritise making it easy for anyone. I suppose they rely on universities or class-room training or the like. Altera takes that approach, too. So us learn from home hobbyists have to rely on kind folks in the online communities who have walked that path. Thanks again. gbulmer on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105326 Sun, 13 Apr 2014 08:26:02 +0000 gbulmer 105326@http://forums.leaflabs.com/ The low-cost ST debugger is an ST-LINK/V2 (avoid things called ST-LINK or ST-LINK/V1, IIRC they used a different USB transport): <a href="http://www.st.com/web/catalog/tools/FM146/CL1984/SC720/SS1450/PF251168" rel="nofollow">http://www.st.com/web/catalog/tools/FM146/CL1984/SC720/SS1450/PF251168</a> It is less than 25 USD / 20 GBP, and is available from most distributers, e.g. <a href="http://uk.farnell.com/stmicroelectronics/st-link-v2/icd-programmer-for-stm8-stm32/dp/1892523" rel="nofollow">http://uk.farnell.com/stmicroelectronics/st-link-v2/icd-programmer-for-stm8-stm32/dp/1892523</a> <a href="http://www.digikey.com/product-detail/en/ST-LINK%2FV2/497-10484-ND/2214535" rel="nofollow">http://www.digikey.com/product-detail/en/ST-LINK%2FV2/497-10484-ND/2214535</a> The SWD-only part of the ST-LINK/V2 debugger is built into most ST's ST32M32F Discovery development boards, and all ST Nucleo development boards. These are available at most distributers. Their are many different models with different MCU's. Prices start at under 9 USD/ 7 GBP. This is one example, but there are more than ten different boards under 20 USD /12 GBP: <a href="http://uk.farnell.com/stmicroelectronics/stm32f0discovery/eval-kit-stm32f0-with-st-link-v2/dp/2096251" rel="nofollow">http://uk.farnell.com/stmicroelectronics/stm32f0discovery/eval-kit-stm32f0-with-st-link-v2/dp/2096251</a> <a href="http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-boards-embedded-mcu-dsp/2621773?k=STM32F0Discovery" rel="nofollow">http://www.digikey.com/product-search/en/programmers-development-systems/evaluation-boards-embedded-mcu-dsp/2621773?k=STM32F0Discovery</a> Beware, older Discovery board models had the ST-LINK/V1. The ST datasheet says which it has, so if the datasheet says ST-LINK, and not ST-LINK/V2, avoid it. These need a way to bridge between the debug software and the debug hardware. IIRC OpenOCD has such a bridge.There is also a gdb to ST-LINK/V2 specific bridge at: <a href="https://github.com/texane/stlink" rel="nofollow">https://github.com/texane/stlink</a> This has a few programs. One is a stand-alone program which can upload into the MCU. Another is a gdb-to-ST-LINK/V2 server. Unfortunately, The ST-LINK/V2 protocol is proprietary. Some commercial development companies have signed an NDA with ST to see the documentation. AFAIK the developers of texane/stlink, like several other Open Source ST-LINK compatible gdb servers, have not seen ST's documentation. AFAIK LeafLabs did use an Olimex JTAG debugger. However, more recently LeafLabs have recommended the Open Source Black Magic Probe, which looks like the best solution, because it is so straightforward to use: <a href="http://www.blacksphere.co.nz/main/blackmagic" rel="nofollow">http://www.blacksphere.co.nz/main/blackmagic</a> This implements gdb's protocol over USB serial. Hence, if you are using gdb, there is no other software to bridge between gdb and the STM32 MCU; gdb talks 'directly' to the Black Magic Probe. I keep meaning to either make or buy one. It should save a lot of futzing around installing and setting up software. There is a lot of knowledge encoded in a bridge (gdb server) between gdb and the STM32F MCU's debug interface. I would be surprised if OpenOCD or another gdb server could drive a "USB Blaster" designed for an Altera FPGA. But I have been surprised before :-) gruvin on "JTAG pins on Maple-mini?" http://forums.leaflabs.com/topic.php?id=74300#post-105325 Sun, 13 Apr 2014 04:33:22 +0000 gruvin 105325@http://forums.leaflabs.com/ Got out of bed a little later to try an idea I had. But now, the Olimex ARM-USB-OCD isn't even initialising properly. Even with nothing connected to it but the USB cable, I just get a dim red light. I guess it's cooked or something. I cannot find anything on the Olimex website about self tests or trouble-shooting the device itself. Pretty lame. *sigh* I think it's time I gave up on all this "hackery" and researched official programmers, from ST or Atmel. It's just not worth this hassle. I should have just done that from the beginning. I do have a JTAG "USB Blaster", which I use with my Altera FPGA boards. Can that be used, I wonder?