freeRTOS, LPC2000: is it that complex?

Hi, I really really really want to run freeRTOS on NXP’s ARM7s. I have been working with ARM7s for a while now, with a commercial tool at work. At home however I do not have a commercial solution and I can’t afford to get one (not even the hobbyist license from Rowley, yes it that sad). For the past month or so I have been trying to get freeRTOS, Eclipse, Yagarto and Olimex openOCD/USB JTAG to work together and I’ve reached a point of despair never seen before… I’ve read several tutorials including Yagarto’s, Jim Lynch’s and others I found online. I don’t seem to get openOCD, and my JTAG to work together. It’s just too much between the configuration of GDB, the config files for openOCD, the reset scripts etc. Could someone help me setting up my system, I just can’t wait to get freeRTOS running. It would be greatly appreciated. Thanks, ARMinator

freeRTOS, LPC2000: is it that complex?

It’s pretty simple with Linux, GCC and OpenOCD.  It sounds like you could benefit from an in-person visit.  If you’re near Portland, Oregon and can bring your setup over with a six-pack of Steelhead Double IPA, I’d be happy to sort it out for you.  Maybe others around the world would do the same. (Bring two six-packs and a bottle of ibuprofen if you want me to figure out how to set up a toolchain under Windows.) d.

freeRTOS, LPC2000: is it that complex?

Thanks for the proposal… I’m in Canada though :(. I’m open to switch to Linux if you guarantee it will work. I can easily create a virtual machine on my mac. I can also meet with people over IRC if thats easier, we can certainly arrange something for the 6 pack too :).

freeRTOS, LPC2000: is it that complex?

Ah, I’d need the ibuprofen to work on a Mac, too.  Most of the toolchain should be no problem — I think MacOS is close enough to ordinary Unix that you can compile binutils and gcc easily enough.  But OpenOCD is Fscking Magic to me.  I’ve gotten various versions of it working with various Linuxes, but it’s always a little trial & error.  A virtual machine probably won’t help much, unless you install a version of Linux (like Ubuntu) which has OpenOCD available as an installable package, _and_ that version of OpenOCD happens to be able to see your JTAG hardware through whatever Fscking Magic the virtual machine imposes between OpenOCD and the parallel (or USB) port. Which part of the toolchain is giving you grief?  Everything before JTAG should work OK on MacOS.  You should even be able to use lpc2k_pgm to interact with the LPC2K serial bootloader, because the Mac serial port probably isn’t totally stupid-wonky (if it is, you could always get a USB-serial adapter for $10 or so). Just take it a step at a time: can you compile C to ARM assembly language?  Can you assemble to ARM object code?  Can you link?  Can you disassemble your linked binary and get something that looks like your original assembly?  Can you send the binary to the microcontroller? BTW, what CPU are you using?  And what board?

freeRTOS, LPC2000: is it that complex?

I tried to get the tool chain to work with Mac OS (got the compiler and other tools from darwin-ports). I am able to compile tough there is no of arm-elf-gdb readily available for it yet… If if could use the debugger straight from mac os, without using a virtual machine that would be great. As for the USB interface with the virtual machine, so far I’ve been using several USB devices with Windows and they seem to work. I could install Ubuntu if you think it would be easier than trying to get the Yagarto toolchain to work. I’m working with a custom made LPC2129 based board. I know the board and the JTAG interface work for having tested them with a commercial JTAG/debugger. What is giving me grief is the debugger. Using Yagarto, I am able to compile for sure and maybe link. The reason why I’m not sure with the debugger is because I couldn’t find a readily available cmd file for the LPC2129. I’ve modified cmd files I’ve found for the LPC2148 and I think it’s ok. So far when debugging, at best openOCD succeeds in flashing the board, but seems to timeout waiting for the processor to halt or something. This happens while the board seems to be flashed… Eventually stepping through the code is enabled, but the debugger(?) crashes after a few lines of code are executed. I had other errors including failure to write to flash, unknown flash bank… So far I haven’t found a cfg and gdb commands specific to the LPC2129, so I’ve been modifying what I’ve found here and there. Since the behavior has been so erratic, I am interested in reinstalling yagarto from scratch and following somebody’s advices to setup everything. Thanks!

freeRTOS, LPC2000: is it that complex?

I’ve moved forward, and I’ve updated openOCD to the latest version available (0.1.0), as it seems like the one recommended by Yagarto was a bit outdated. I read the openOCD documentation and followed the recommended way of configuring the target. I come up with the following cfg file: debug_level 3 source [find interface/olimex-arm-usb-ocd.cfg] # Change the default telnet port… telnet_port 4444 # GDB connects here gdb_port 3333 # GDB can also flash my flash! gdb_memory_map enable gdb_flash_program enable source [find target/lpc2129.cfg] Even after I run this, neither the telnet nor the gdb ports are open… I’ve confirmed this with netstat and by trying to telnet to openOCD. Here is the output I get in debug 3 mode, note that there is no warning: C:projectsEclipseWorkspaceLPC2129_Test>openocd.exe Open On-Chip Debugger 0.1.0 (2009-01-21-21:15) Release BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS $URL: https://kc8apf@svn.berlios.de/svnroot/repos/openocd/tags/openocd-0.1.0/src /openocd.c $ Debug: 5 0 configuration.c:88 find_file(): found C:Program FilesOpenOCD.1.0 bin\../interface/olimex-arm-usb-ocd.cfg Debug: 7 0 command.c:91 script_command(): script_command – interface Debug: 8 0 command.c:108 script_command(): script_command – interface, argv[0]=o cd_interface Debug: 9 0 command.c:108 script_command(): script_command – interface, argv[1]=f t2232 Debug: 11 0 command.c:91 script_command(): script_command – ft2232_device_desc Debug: 12 0 command.c:108 script_command(): script_command – ft2232_device_desc, argv[0]=ocd_ft2232_device_desc Debug: 13 0 command.c:108 script_command(): script_command – ft2232_device_desc, argv[1]=Olimex OpenOCD JTAG Debug: 15 0 command.c:91 script_command(): script_command – ft2232_layout Debug: 16 0 command.c:108 script_command(): script_command – ft2232_layout, argv [0]=ocd_ft2232_layout Debug: 17 0 command.c:108 script_command(): script_command – ft2232_layout, argv [1]=olimex-jtag Debug: 19 0 command.c:91 script_command(): script_command – ft2232_vid_pid Debug: 20 0 command.c:108 script_command(): script_command – ft2232_vid_pid, arg v[0]=ocd_ft2232_vid_pid Debug: 21 15 command.c:108 script_command(): script_command – ft2232_vid_pid, ar gv[1]=0x15ba Debug: 22 15 command.c:108 script_command(): script_command – ft2232_vid_pid, ar gv[2]=0x0003 Debug: 24 15 command.c:91 script_command(): script_command – telnet_port Debug: 25 15 command.c:108 script_command(): script_command – telnet_port, argv[ 0]=ocd_telnet_port Debug: 26 15 command.c:108 script_command(): script_command – telnet_port, argv[ 1]=4444 Debug: 28 15 command.c:91 script_command(): script_command – gdb_port Debug: 29 15 command.c:108 script_command(): script_command – gdb_port, argv[0]= ocd_gdb_port Debug: 30 15 command.c:108 script_command(): script_command – gdb_port, argv[1]= 3333 Debug: 32 15 command.c:91 script_command(): script_command – gdb_memory_map Debug: 33 15 command.c:108 script_command(): script_command – gdb_memory_map, ar gv[0]=ocd_gdb_memory_map Debug: 34 15 command.c:108 script_command(): script_command – gdb_memory_map, ar gv[1]=enable Debug: 36 15 command.c:91 script_command(): script_command – gdb_flash_program Debug: 37 15 command.c:108 script_command(): script_command – gdb_flash_program, argv[0]=ocd_gdb_flash_program Debug: 38 15 command.c:108 script_command(): script_command – gdb_flash_program, argv[1]=enable Debug: 39 15 configuration.c:88 find_file(): found C:Program FilesOpenOCD.1. 0bin\../target/lpc2129.cfg Debug: 41 15 command.c:91 script_command(): script_command – reset_config Debug: 42 15 command.c:108 script_command(): script_command – reset_config, argv [0]=ocd_reset_config Debug: 43 15 command.c:108 script_command(): script_command – reset_config, argv [1]=trst_and_srst Debug: 44 15 command.c:108 script_command(): script_command – reset_config, argv [2]=srst_pulls_trst Debug: 45 15 jtag.c:1892 jim_newtap_cmd(): Creating New Tap, Chip: lpc2129, Tap: cpu, Dotted: lpc2129.cpu, 8 params Debug: 46 15 jtag.c:1911 jim_newtap_cmd(): Processing option: -irlen Debug: 47 15 jtag.c:1911 jim_newtap_cmd(): Processing option: -ircapture Debug: 48 15 jtag.c:1911 jim_newtap_cmd(): Processing option: -irmask Debug: 49 15 jtag.c:1911 jim_newtap_cmd(): Processing option: -expected-id Debug: 50 31 jtag.c:2024 jim_newtap_cmd(): Created Tap: lpc2129.cpu @ abs positi on 0, irlen 4, capture: 0x1 mask: 0xf Debug: 51 31 target.c:3911 jim_target(): Target command params: Debug: 52 31 target.c:3912 jim_target(): target create lpc2129.cpu arm7tdmi -end ian little -chain-position lpc2129.cpu -variant arm7tdmi-s_r4 Debug: 54 31 command.c:91 script_command(): script_command – bank Debug: 55 31 command.c:108 script_command(): script_command – bank, argv[0]=ocd_ flash_bank Debug: 56 31 command.c:108 script_command(): script_command – bank, argv[1]=lpc2 000 Debug: 57 31 command.c:108 script_command(): script_command – bank, argv[2]=0x0 Debug: 58 31 command.c:108 script_command(): script_command – bank, argv[3]=0x40 000 Debug: 59 31 command.c:108 script_command(): script_command – bank, argv[4]=0 Debug: 60 31 command.c:108 script_command(): script_command – bank, argv[5]=0 Debug: 61 31 command.c:108 script_command(): script_command – bank, argv[6]=0 Debug: 62 31 command.c:108 script_command(): script_command – bank, argv[7]=lpc2 000_v1 Debug: 63 31 command.c:108 script_command(): script_command – bank, argv[8]=1476 5 Debug: 64 31 command.c:108 script_command(): script_command – bank, argv[9]=calc _checksum User : 65 31 command.c:494 command_run_line(): Debug: 67 31 command.c:91 script_command(): script_command – init Debug: 68 31 command.c:108 script_command(): script_command – init, argv[0]=ocd_ init Debug: 69 31 openocd.c:144 handle_init_command(): target init complete Debug: 70 31 ft2232.c:1463 ft2232_init_ftd2xx(): ‘ft2232’ interface using FTD2XX with ‘olimex-jtag’ layout (15ba:0003) Any idea what’s wrong? Thanks!

freeRTOS, LPC2000: is it that complex?

> What is giving me grief is the debugger. Debugging a micro with GDB is actually a two-part process.  GDB itself is a pretty well-behaved program, and you should be able to compile a version for arm-elf from source without much trouble.  (Or maybe you can find a pre-compiled version in ports.) The second part is much trickier.  GDB interacts with the target by talking to a "target remote program" over a TCP connection.  It’s the responsibility of target remote program to start, stop and reset the micro, and to report any information that GDB asks for. The only target remote program I know of is OpenOCD.  Configuration files for OpenOCD usually set it up to talk to GDB on port 3333, and you can also talk to OpenOCD directly by telnetting to port 4444.  OpenOCD knows how to operate a few different JTAG interface dongles, and also knows some of the things you can do with the JTAG protocol. > Using Yagarto, I am able to compile for sure and maybe link. The reason why I’m not sure with > the debugger is because I couldn’t find a readily available cmd file for the LPC2129. I’ve modified > cmd files I’ve found for the LPC2148 and I think it’s ok. That’s what I did at first, and it worked out OK.  IIRC, most of the differences between the LPC2k procs are in the peripherals and the _end_ addresses of ROM and RAM.  So, if your linker command file correctly identifies the amount of RAM in your 2129, then you probably won’t have the problem of the start-up code setting the stack pointer in the wrong place, or "initializing" non-existent memory.  Still, if something _is_ trying to read or write non-existent RAM, you’ll get a Data Fault, which may make your CPU crash. When having problems with a new setup, I like to write a little spaghetti-code assembly language routine that does the bare minimum necessary to wiggle a pin or blink an LED or something.  Check the assembled code and binary file pretty carefully, then turn your attention to getting that code flashed into the CPU and running.  The crt0 startup for most systems does WAY more than you need, and if you’re not intimately familiar with it (and have trustworthy debugger support!) then it’ll waste way more of your time than writing a simple routine. > So far when debugging, at best openOCD succeeds in flashing the board, but seems to timeout > waiting for the processor to halt or something. Have you gotten an LED-blinker program running?  If so, you’re golden!  (Or at least silver!) Try telnetting to port 4444 on the machine where OpenOCD is running.  Some commands that may be useful are: "halt", "soft_reset_halt", "resume", and "flash info 0".  (You can get lists of other commands with "help".  The interactive interface is a little wonky, though, particularly for the flash commands.) Also, start OpenOCD from a terminal window; you may see warning or error messages there. Typically, when GDB hangs, it’s because OpenOCD is confused about the JTAG state.  One thing I’ve found helpful is to start OpenOCD first, then telnet to it and do "halt" followed by "soft_reset_halt", and only after that, start GDB and have it connect to the target.  I think it’s because OpenOCD is a little shaky at stopping and resetting the target. So, the next-smallest step for you is to figure out how to get OpenOCD to work.   If you can get it to dump Flash contents ("mdw 0 32") that’s a good sign.  If it recognizes the flash device, even better.  Erase flash?  Almost there.  Program a binary file?  Done. Here’s the OpenOCD config file I use for a Wiggler parallel-port JTAG and LPC2148.  I also have a board with an FTDI 2232 USB interface, but that was a LOT harder to figure out. [BTW, I see you’ve just posted another message about OpenOCD…sounds like you’re on the right track.] #daemon configuration telnet_port 4444 gdb_port 3333 #interface interface parport parport_port 0 parport_cable wiggler jtag_speed 4 #reset_config trst_and_srst reset_config trst_only #reset_config trst_and_srst|trst_only|srst_only srst_pulls_trst|trst_pulls_srst|combined #jtag scan chain #format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE) jtag_device 4 0x1 0xf 0xe #target configuration #target <type> <endianness> <startup mode> <chainpos> <variant> target arm7tdmi little reset_halt 0 arm7tdmi-s_r4 flash bank lpc2000 0x0 0x7d000 0 0 lpc2000_v2 0 12000 calc_checksum

freeRTOS, LPC2000: is it that complex?

> Any idea what’s wrong? Ah, it looks like you’re using an FTDI2232 JTAG.  Well, the first thing I’d do is find the file included by the last line of your OpenOCD config file: target/lpc2129.cfg.  Then put all the OpenOCD config stuff into one text file, and tell OpenOCD to use that. You’re fairly likely to have to fiddle with the "jtag_speed" and "reset_config" lines.  Warning: OpenOCD changes the syntax and meaning of commands between versions, and not always in a backward-compatible way.  (Cue pulling-out-hair sound here.)  So, pick a fairly recent version of OpenOCD (compile one yourself if you want) and be careful not to switch versions as you fiddle with the configuration file. d.

freeRTOS, LPC2000: is it that complex?

…Are you running OpenOCD in a DOS box on the Mac or something (guessing based on the command prompt and ".exe" at the end of the command)?  The 3333 and 4444 ports should be open on that box, not on the Mac.  (I know the Mac has that magic "Unity" thing.  More power to you, Mac fanboys, but for this project, do yourself a favor: run a native version of OpenOCD on a Linux box.) d.

freeRTOS, LPC2000: is it that complex?

Hi, Thanks for the detailed answer. The board I’m running does not have an LED I can toggle… Shame. I have an LCD, a CAN bus port, serial port, but no LED… But rev 2 will for have one for sure! I tried to telnet openOCD on localhost but it does not look like any port (neither 3333 or 4444) are open. I double checked this running netstat -abov. No port open at 4444 or 3333. This is with the latest msi version I got from the openOCD website (v 0.1.0). I upgraded after I read a bunch of posts esplaining how r7xx (the one that comes with Yagarto) was so outdated. What’s bizarre is that the previous version would open the ports… Thanks for the cfg file. I am using a USB model though. openOCD 0.1.0 comes with target and interface files ready to roll for the Olimex openOCD arm USB, and the LPC2129. I used the prefered method for configuring openOCD (as described in the manual), which sources these files and specifies ports 3333 and 4444 for GDB and 3333. Even after I feed this to openOCD no port seems to be open… This is where I stand now. It looks like compared to yesterday I’m getting close as now I do have proper config files for the JTAG interface and the processor. However it seems like openOCD is not responding now… Compiling my own version of gdb and setting up the arm toolchain on Mac OS seems like 5 steps back at this point. If anybody has any advice on how to get my windows setup going, that would be greatly appreciated! Thanks!

freeRTOS, LPC2000: is it that complex?

Here is the config, once all the files are sourced. While there is a reference to reset_config, there is no reference to jtag_speed… debug_level 3 interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG" ft2232_layout olimex-jtag ft2232_vid_pid 0x15ba 0x0003 # Change the default telnet port… telnet_port 4444 # GDB connects here gdb_port 3333 # GDB can also flash my flash! gdb_memory_map enable gdb_flash_program enable #LPC-2129 CPU if { [info exists CHIPNAME] } {       set  _CHIPNAME $CHIPNAME    } else {        set  _CHIPNAME lpc2129 } if { [info exists ENDIAN] } {       set  _ENDIAN $ENDIAN    } else {        set  _ENDIAN little } if { [info exists CPUTAPID ] } {    set _CPUTAPID $CPUTAPID } else {   # force an error till we get a good number    set _CPUTAPID 0xffffffff } #use combined on interfaces or targets that can’t set TRST/SRST separately reset_config trst_and_srst srst_pulls_trst #jtag scan chain jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID set _TARGETNAME [format "%s.cpu" $_CHIPNAME] target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4 $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-size 0x4000 -work-area-backup 0 #flash bank <driver> <base> <size> <chip_width> <bus_width> flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum

freeRTOS, LPC2000: is it that complex?

Yes, everything (openOCD, eclipse, GDB…) is running on the windows host.

freeRTOS, LPC2000: is it that complex?

> Compiling my own version of gdb and setting up the arm toolchain on Mac OS seems like 5 steps > back at this point. If anybody has any advice on how to get my windows setup going, that would > be greatly appreciated! Can’t help with Windows, but you’re right: I wouldn’t bother recompiling the whole toolchain.  I probably would do for OpenOCD, though, and then run it natively on whatever box actually has the JTAG USB connected to it. Good luck!

freeRTOS, LPC2000: is it that complex?

Yepee! got it! OpenOCD 0.1.0 works right of the install, after the lpc2129 target cfg file is converted to the Windows format… I’m now ready to run freeRTOS!