I’m trying to set up an ARM development environment on my windows 7 machine. So far, the 2 micros i’m interested in are:
-
STR731FV2T7 (outdated, I know, but I have at my disposal a large number of prototype automotive ECUs that contain this micro, and I think they would make great dev boards).
-
STM32F407VG (I just bought a STM32F4DISCOVERY board, and this chip looks well suited for use in a couple future projects on its own).
As for programming/debugging adapters,
-
I just bought an Olimex ARM-USB-TINY from this site that i would like to be able to flash both the aforementioned micros with.
-
I would like also be able to use the ST-LINK/V2 on the Discovery board.
I’d like a consolidated toolchain/ide that can use both these debug tools in, and program for both targets, IDE must have built-in debugging support (setting breakpoints by double clicking c-lines, right clicking on variables to add them to my watch list, etc).
The toolchain that SparkFun suggests on the ARM-USB-TINY product page is as follows: “WinArm+OpenOCD+ARM-USB-OCD.” Looking at the WinARM homepage (http://www.siwawi.arubi.uni-kl.de/avr_p … _projects/), I noticed that the latest version was 20060606 (this was the version listed in the obvious download link on the homepage anyway), which implies it was released in 2006? Would this even have support for the STM32F4 with it’s Cortex-M4f core - it seems like a relatively new micro/architecture? There seem to be much more up-to-date GCC toolchains (like GCC-ARM-EMBEDDED or YAGARTO) which seem preferable to me. This brings me to my first question - are WinARM, GCC-ARM-EMBEDDED, and YAGARTO all alternatives/substitutes for each other - are they all the same thing, just made by different groups? Perhaps I interpreted it wrong, but The GCC-ARM-EMBEDDED homepage kind of implies that it is the ‘official’ gcc branch that is developed and maintained by ARM themselves (https://launchpad.net/gcc-arm-embedded). Is this the case? If this is the case, it seems like it would be the most cutting-edge toolchain with support for all the latest arm processors. YAGARTO, however, seems to have by far the greatest following and I see it much more regularly recommended on the net for windows development. Can someone recommend one of these to me? Are any of them ruled out by the STM32F4 requirement?
I’m pretty sure I’ve also read a few forum posts that say other people’s ARM-USB-TINY came with a cd with all the necessary tools to get them up and running. Mine did not - but it did come with a slip of paper that said to download the required software at the following URL http://www.olimex.com/dev/openocd. the download link takes me to a russian(?) filehosting site that says the file is no longer available. Nevertheless, they do list the toolchain contents (some of it appears out of data): LibUSB version 1.2.2.0/USB serial port driver FTDI 2.08.08, OpenOCD 0.4.0, Eclipse Helios 3.6.1, and YAGARTO. I set about trying to download the latest versions of all this stuff from their respective websites. I ran into some problems:
As for usb drivers for the ARM-USB-TINY, I started with the drivers supplied with openocd 0.5.0 (openocd-0.5.0\drivers\libusb-win32_ft2232_driver-110810\libusb-win32_ft2232_driver-110810\libusb-win32_ft2232_driver.inf). I ended up with 2 devices in my device manager: “Olimex ARM-USB-TINY (Channel A)” and “Olimex ARM-USB-TINY (Channel B)”. I downloaded OpenOCD from http://www.freddiechopin.info/en/downlo … /4-openocd, which just came as a zip with no installer. i just extracted it to 'c:\openocd-0.5.0' . If i understand correctly, I simply need to start OpenOCD by running C:\openocd-0.5.0\bin\openocd-0.5.0 -f C:\openocd-0.5.0\interface\olimex-jtag-tin
y.cfg . Is my understanding of how to setup and run OpenOCD correct?
Here’s the output i get:
C:\openocd-0.5.0\bin>openocd-0.5.0 -f C:\openocd-0.5.0\interface\olimex-jtag-tin
y.cfg
Open On-Chip Debugger 0.5.0 (2011-08-09-23:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect ‘jtag’
Error: An adapter speed is not selected in the init script. Insert a call to ada
pter_khz or jtag_rclk to proceed.
in procedure ‘init’
I googled the error, and arrived here: http://www.tincantools.com/wiki/OpenOCD … t_Selected . I changed my olimex-jtag-tiny.cfg to the following to specify a speed:
Olimex ARM-USB-TINY
http://www.olimex.com/dev/arm-usb-tiny.html
interface ft2232
ft2232_device_desc “Olimex OpenOCD JTAG TINY”
ft2232_layout olimex-jtag
ft2232_vid_pid 0x15ba 0x0004
adapter_khz 300
Was this the correct thing to do? Why would olimex-jtag-tiny.cfg not work out-of-the-box? I set it to 300kHz due to a post i found here (http://www.coocox.org/forum/topic.php?id=668) - does anyone know where he found that the “recommended frequency for JTAG is 300KHz?” I re-ran openocd and go the following output:
C:\openocd-0.5.0\bin>openocd-0.5.0 -f C:\openocd-0.5.0\interface\olimex-jtag-tin
y.cfg
Open On-Chip Debugger 0.5.0 (2011-08-09-23:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect ‘jtag’
300 kHz
Info : clock speed 300 kHz
Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined
Despite all the errors, OpenOCD continues to run instead of dumping me back to the prompt. The JTAG adapter was not plugged into a target at the time. Is this the expected output if I try to start OpenOCD without a target plugged in? if so, why is this? Do you start OpenOCD to initiate a session with a target, then? Would I need to restart it if I cycled power to the target or plugged into a different target? I assumed that OpenOCD acted as a daemon or service that would either start with windows or would get automatically started when I hit debug in my IDE. Is this not the case? if it attempts to connect to the target upon running, wouldn’t I then need to at least tell it what micro is connected? The all seem to implement different pins of the 20 pin standard - the STR731FV2T7, for example, doesn’t use dbgrq or dbgack.
I plugged into a target and powered it up (one of the prototype STR731FV2T7-based ECUs i mentioned earlier). I make a cobbled-together jtag connection, soldering flying leads from a 20 pin header to various test points and vias (according to http://infocenter.arm.com/help/index.js … EIHCE.html and sect 5.1 of http://www.st.com/internet/com/TECHNICA … 056758.pdf) - so something might have gone wrong there but I triple-checked everything to the best of my understanding. In fact here’s a description of what I connected where:
Pin 1 of 20 pin JTAG connector (VTREF) went directly to 5v Rail Vcc on targed board
Pin 2 of 20 pin JTAG connector (NC) was left disconnected
Pin 3 of 20 pin JTAG connector (nTRST) went to JTRST pin 65 on micro (10k pullup to vcc)
Pin 5 of 20 pin JTAG connector (TDI) went to JTDI pin 66 on micro (10k pullup to vcc)
Pin 7 of 20 pin JTAG connector (TMS) went to JTMS pin 67 on micro (10k pullup to vcc)
Pin 9 of 20 pin JTAG connector (TCK) went to JTCK pin 68 on micro (10k pulldown to gnd)
Pin 13 of 20 pin JTAG connector (TDO) went to JTDO pin 69 on micro (no PU/PD)
Pin 15 of 20 pin JTAG connector (nSRST) went to system reset line on target board (inc. pin 34 on micro)
Pins 4, 6, 8, 10, 11, 12, 14, 16, 17, 18, 19, 20 all connected to GND
I stopped the previous session of OpenOCD (ctrl-c) and re-ran it with the ARM-USB-TINY plugged into my target, and the target powered up, and got the following output:
C:\openocd-0.5.0\bin>openocd-0.5.0 -f C:\openocd-0.5.0\interface\olimex-jtag-tin
y.cfg
Open On-Chip Debugger 0.5.0 (2011-08-09-23:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect ‘jtag’
300 kHz
Error: unable to open ftdi device: unable to fetch product description
in procedure ‘init’
I re-ran it again immediately after and got a different error message:
C:\openocd-0.5.0\bin>openocd-0.5.0 -f C:\openocd-0.5.0\interface\olimex-jtag-tin
y.cfg
Open On-Chip Debugger 0.5.0 (2011-08-09-23:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect ‘jtag’
300 kHz
Error: unable to open ftdi device: device not found
in procedure ‘init’
Does anybody know the cause of these errors? i even re-ran from a command prompt in run as administrator mode and got the second error message again.
Googling the second error brought me to (http://www.tincantools.com/wiki/Running … ce_Filters), which told me to run the Libusb device filter installation. I downloaded latest available - 1.2.6.0. I initially ran the x86 version (libusb-win32-bin-1.2.6.0\bin\x86\install-filter-win.exe) (even though i have a 64 bit os/intel cpu). the device came up as a composite device (vid:15ba pid:0004 rev:0500). It then complained that i was using the 32 bit version of the Libusb device filter installation, so I ran the 64 bit (libusb-win32-bin-1.2.6.0\bin\ia64\install-filter-win.exe). The 64 bit version immediately came up wit the following error: “The version of this file is not compatible with the version of Windows you’re running. Check your computer’s system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.” Re-ran as as administrator - same thing.
What am i doing wrong here? The drivers I used from the OpenOCD package had ‘libusb’ in the name. does that mean the Libusb device filter installation is unnecessary/redundant? I also tried the drivers the Olimex page suggests (https://www.olimex.com/dev/openocd/):
-
LibUSB version 1.2.2.0, http://sourceforge.net/projects/libusb-win32/files/
-
USB serial port driver FTDI 2.08.08, 16 November 2010, http://www.ftdichip.com/Drivers/VCP.htm
That didn’t seem to work, either.
Also, I have another question that I could not find a black and white answer for: What version of OpenOCD do I need for STM32F4 support? The latest pre-built binary available from (http://www.freddiechopin.info/en/downlo … /4-openocd) is 0.5. I’ve seen mixed claims that I either need 0.5 or 0.6 (not available pre-built for win) for stm32f4 support.
And Finally, I’ve had some success using CooCox Coide and GCC-ARM-EMBEDDED with my STLINK/V2 on my STM32F4DISCOVERY board. I plan on switching over to YAGARTO though. Will this all jive together (CoIDE, YAGARTO, OpenOCD+ARM-USB-TINY, STLINK/V2, STR731FV2T7, STM32F407VG, STM32F4DISCOVERY)? Does anyone have any thoughts on Eclipse vs CooIDE knowing my tools/targets? Also, where does GDB fit in in all this? I’ve seen the name in a number of posts/guides relating to setting up an ARM environment. It looks like it’s included in Yagarto. CoIDE doesn’t seem to mention GDB at all… there don’t appear to be any settings to tell it where the GDB binaries reside on my HD (or is that in ‘select toolchain path’?)
Sorry for the novel but there are obviously a lot of facets to these open source ARM tools that I don’t understand. I’m obviously new to ARM development as a whole. Any help would be much appreciated. Thanks!
-Liam