Adventures with a LM3S811 under Linux

Development Boards MicroMod
1

Hi everyone. I have just received a Luminary Micros LM3S811 evaluation kit, and am trying to get it working under Linux (specifically, Kubuntu 6.06).

So far, I have:

  • Checked out the cortex-m3 branch of the OpenOCD project

  • Installed libftdi (from the Ubuntu repository)

  • Installed autoconf, automake, make and gcc 4.0.3

  • Created a symlink for gcc-4.0 as gcc so it’s detectable by autoconf

  • Successfully (I think) built OpenOCD, with the --enable-ft2232_libftdi option.

  • Created a basic config file (there are bound to be some errors but I’m getting there slowly).

I am, however, stuck at this point: The driver sees the FTDI chip, but cannot properly connect to it. Here’s the output

Info:    openocd.c:82 main(): Open On-Chip Debugger (2006-10-12 18:00 CEST)
Debug:   jtag.c:1210 jtag_init():
Debug:   ft2232.c:992 ft2232_init(): 'ft2232' interface using libftdi with 'evb_lm3s811' layout
Error:   ft2232.c:1097 ft2232_init(): unable to open ftdi device: unable to claim usb device. Make sure ftdi_sio is unloaded!

lsmod reports no module loaded called ftdi_sio, so I don’t think that this is the actual problem (more a guess as to a likely cause).

I’ve had a google around but haven’t found anything substantive. Any pointers would be gratefully appreciated.

Just in case it’s germane to the issue, here’s my config file:

telnet_port 9999
gdb_port 7777

daemon_startup attach

interface ft2232

jtag_speed 0
reset_config none
jtag_device 4 0x1 0xF 0
jtag_nsrst_delay 10
jtag_ntrst_delay 10

ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xBCD9

target cortex_m3 little reset_run 0

run_and_halt_time 0 10
2

Hi

I have tried to reproduce your errors:

Error: ft2232.c:1097 ft2232_init(): unable to open ftdi device: unable to claim usb device. Make sure ftdi_sio is unloaded!

This happens when I already have one instance of OpenOCD running, so some other process has attached to the interface. On my system this is not the ftdi_sio since this combination of vid/pid is not recognised as a serial interface.

Then I must unplug and reconnect the USB to be able to get the ftdi driver to talk to the chip after terminating openocd. After this I can get openocd running, until i terminate, then I must do the disconnect/reconnect again.

You can also try dmesg just after connecting the USB interface.

So the advice is: Use the ftd2xx driver , it is much more stable, runs like clockwork.

Get the driver from http://www.ftdichip.com/Drivers/D2XX.htm

You can also find my config file as “cortex_ft2232.cfg” in the doc/configs directory.

Regards,

Magnus

3

Magnus,

First, a big “thank you” for taking the time to create the Cortex-M3 support inside OpenOCD.

This happens when I already have one instance of OpenOCD running

Since I had been playing with it for some time, it is quite possible that I already had another instance running. I will take a look again when I get back home.

So the advice is: Use the ftd2xx driver

I am using the FTDI open drivers since I want to ensure that I was using all-free software; there are few cases where I will use closed-source drivers, really only where there is no open-source alternative. I will persist with the open drivers for a while to see if I can get them working reliably, but it is good to know that an alternative exists just in case I cannot.

Thanks also for the pointer to the config file - I did look for one but managed to overlook this completely.

4

Hi

I agre with your point

am using the FTDI open drivers since I want to ensure that I was using all-free software; there are few cases where I will use closed-source drivers, really only where there is no open-source alternative. I will persist with the open drivers for a while to see if I can get them working reliably, but it is good to know that an alternative exists just in case I cannot.

unfortunatly the difference in stability and performance is so big that there is almost no choise. Someone has to either ask FTDI nicely to opensource their code or devote some time to work with libftdi.

Regards

Magnus

5

Magnus, using the libftd2xx library fixed the problem straight off, and I can now talk to the board via the telnet port, and also via CodeSourcery’s version of gdb.

It’s pretty late now, so I’m going to call it a day. Tomorrow I will try compiling a “hello world” application and uploading it to the board.

6

Success! I finally got it going - I lost a load of time before I remembered that you explicitly have to erase the flash before programming.

I compiled the “hello world” example from Martin Thomas’s web page here: http://gandalf.arubi.uni-kl.de/avr_proj … ortex.html, and used the telnet interface for flash loading.

I have been keeping a log of everything I did - I will write it up on my website and post a link here, probably tomorrow.

7

As promised, here’s the link: http://www.moteprime.org/article.php?id=27.

Comments, queries, corrections or even just rudeness and abuse welcome…

8

I usually run ddd as a gui for gdb. The following commands sets up the system to use the codesourcery version of gdb. The paths must perhaps be adjusted.

cd ~/cortex/EV-LM3S811/qs_ev-lm3s811
xterm -e openocd -d3 &
ddd --debugger "/usr/local/arm-eabi/bin/arm-none-eabi-gdb -s main.elf -ex 'target remote localhost:3333'"

Form here on its a piece of cake, sometimes you must send command directly to openocd though. This is done in the gdb command window, bottom

(gdb)monitor   flash write  0 main.bin 0

Regards,

Magnus

9

Does it then follow, that one could use OpenOCD and launch gdb under the Zylin Eclipse CDT modules, and have a complete development gui based system?

I have (with much help from LMI Dan) gotten a Yagarto IDE based Eclipse system working with the CodeSourcery arm-none-eabi gcc, but have been using the CodeSourcery arm-swd that came on their cd (proprietary). I want to try OpenOCD, to eliminate the non-open source.

Any ideas/thoughts/experience would be greatly appreciated.

jc

10

Hello all. The sequence graciously posted by seantellis worked for me initially (with a few modifications…). But then I started trying to build and run all the example programs and soon started getting lots of errors in the openocd daemon window. Now when I start I get a bunch of messages like this:

[root@lnxhgates cortex-m3]# ./src/openocd

Info: openocd.c:84 main(): Open On-Chip Debugger (2006-11-22 14:00 CEST)

Error: cortex_swjdp.c:218 swjdp_transaction_endcheck(): SWJ-DP OVERRUN - check clock or reduce jtag speed

Error: cortex_swjdp.c:231 swjdp_transaction_endcheck(): dcb_dhcsr 90001, nvic_shcsr 0, nvic_cfsr 1001, nvic_bfar fffffff4

Error: cortex_swjdp.c:218 swjdp_transaction_endcheck(): SWJ-DP OVERRUN - check clock or reduce jtag speed

Error: cortex_swjdp.c:231 swjdp_transaction_endcheck(): dcb_dhcsr 30003, nvic_shcsr 0, nvic_cfsr 1001, nvic_bfar e000edf8

Error: cortex_m3.c:1095 cortex_m3_load_core_reg_u32(): JTAG failure -107

Error: cortex_swjdp.c:218 swjdp_transaction_endcheck(): SWJ-DP OVERRUN - check clock or reduce jtag speed

Error: cortex_swjdp.c:231 swjdp_transaction_endcheck(): dcb_dhcsr 30003, nvic_shcsr 0, nvic_cfsr 1001, nvic_bfar e000edf8

Error: cortex_m3.c:1095 cortex_m3_load_core_reg_u32(): JTAG failure -107

I tried changing the jtag speed all the way down to 0 in the openocd config file, but with no luck. Also tried commenting out the “working_area…” line, also with no help. Sometimes I can halt, erase, and flash, but often times not and always with lots of errors. Longer programs, like the game, don’t work even if they finish programming.

Maybe I’ve got multiple issues here…

Thanks for any suggestions,

-Holly

11

Hi

For the FTDI JTAG interface, the one on the LM811 evalboard, speed 0 is maximal speed, a slow speed that always works for me is 40. ( jtag speed is actually the clock divisor on the FTDI chip ).

This is a problem with the OpenOCD jtagspeed command that the meaning of the speed value is depenedent on the interface used and has no consistent relation to the actual JTAG clock frequency. Maybe this should, and will be, cleaned up some day.

If the board is running with PLL configured for 20-50 MHz operation then 0 can be used but jtag speed 6 is safer.

If the chip is unprogrammed or running from the dafault 6MHz crystal clock a jtagspeed setting of 10 is recommended and you should try 20 or 40 if problems persists.

For normal debugging and download of short programs to flash the difference is not a problem.

For better performance on unprogrammed chips it is possible to connect with a very slow jtag speed ( 40 ) and then change the processor core speed by programing RCC register (the PLL and clock control register using )

mww 0x400fe060 0x4ce02c0

Then the JTAG speed can be set up to 0 on my board.

Hope this helps and let us know if it works.

Regards,

Magnus

12

Ah, jtag speed is a divisor! Makes sense. I set it to 20 and it works with no errors now.

Thanks for the quick response!

-Holly