JTAG pins on Maple-mini? « LeafLabs Garden

LeafLabs Garden » Support » Maple Hardware Support

JTAG pins on Maple-mini?

(22 posts) (3 voices)

Started 1 year ago by gruvin
Latest reply from tormod

« Previous 12

gruvin
Member
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.
sudo kextunload -bundle com.FTDI.driver.FTDIUSBSerialDriver
Try that as a first test, to see if openocd 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 ...
sudo kextstat | grep FTDI
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 openocd ...
sudo vi /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist
In that file, we find the Olimex keys and comment them out ...
<integer>1027</integer> </dict>  <key>Olimex OpenOCD JTAG B</key> <dict> <key>CFBundleIdentifier</key> <string>com.FTDI.driver.FTDIUSBSerialDriver</string>
The <-- ... --> part is the commented out section.

Now unload and reload the kernel extension, to make the changes take effect ...
sudo kextunload -bundle com.FTDI.driver.FTDIUSBSerialDriver sudo kextload -bundle com.FTDI.driver.FTDIUSBSerialDriver
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 Info.plist file, above. This lets you still have access to the DB9 serial port.

You should now still be able to use openocd, 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 /dev/cu.usbserial-FTWZWBC0B.
Posted 1 year ago #
gruvin
Member
Those functions for enabling/disabling the JTAG debug ports on the Maple-mini (or others) are as follows ...
disableDebugPorts() enableDebugPorts()
I found this information on JTAG documentation page.
Posted 1 year ago #
gruvin
Member

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 stm32f1x mass_erase and flash write_bank 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.

Posted 1 year ago #
gruvin
Member

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.

Posted 1 year ago #
gruvin
Member
My ST-Link/V2 arrived. Hooked it up. Ran OpenOCD using ...
openocd -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg
.. 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. :-/
Posted 1 year ago #
gruvin
Member
Success with ST-Util and GDB

I have returned to have another look at ST-Util 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 ...
FILE:gdb-st.rc --- set remote hardware-breakpoint-limit 6 set remote hardware-watchpoint-limit 4 target extended-remote :4242 monitor reset halt load
That assumes that st-util is already running, of course.

The load 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 ...
$ cd ~/libmaple/maple-mini-bootloader $ arm-none-eabi-gdb -x gdb-st.rc build/maple_boot.elf
You need to be in the directory containing the C source file, when you launch GDB.

From there, I can do things like this ...
(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)
Pretty cool.

Every now and then, I get a glitch occurring when, evidently, an IRQ routine is running and I hit Ctrl-C. It's usually OK, but sometimes,odd things happen. I've seen one way to get around that, but the command mon cortex_m maskisr on 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).
Posted 1 year ago #
tormod
Member

> 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 https://github.com/leaflabs/maple-bootloader

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?

Posted 1 year ago #

RSS feed for this topic

« Previous 12

Reply

You must log in to post.