Forums

General newb help request(s)

Posted by rwentz

on Jan 01 2009 09:33 AM

I changed the title, as I think I figured my original problem out, but I've run into something else, and I don't want to just keep creating threads. This will now be my general newb help thread.

-----------------------------

I'm a software developer by trade, but haven't really done any embedded development since college, so I thought I'd jump back in with an LM3S6965 eval board as a hobby and to maybe expand my career options a bit. My first goal is to get the DriverLib built, and I've decided to use CodeSourcery Lite on Linux x86-64 as my toolchain (I don't really want to pay for a compiler, as this is a hobby right now).

I've tweaked the Makefiles in DriveLib a bit, and can get everything to build, except the final linking step for the examples. When I try to build the "hello" example, I get the following output:

Code:



 arm-none-linux-gnueabi-gcc -T -mthumb -mcpu=cortex-m3 -Wl,--gc-sections sourcerygxx/hello.o sourcerygxx/osram128x64x4.o sourcerygxx/startup.o ../../../src/sourcerygxx/libdriver.a -o sourcerygxx/hello.axf
/home/rwentz/opt/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/../../../../arm-none-linux-gnueabi/bin/ld: unrecognised emulation mode: thumb
Supported emulations: armelf_linux_eabi armelfb_linux_eabi
collect2: ld returned 1 exit status
make: *** [sourcerygxx/hello.axf] Error 1

arm-none-linux-gnueabi-ld indicates that it supports two emulation modes: armelf_linux_eabi armelfb_linux_eabi, but if I try to use these instead of "thumb", it says it can't find a linker script for them.

Here's some of the makefile tweaks I've made, in case they might be an issue:
-Changed dependency on hello_sourcerygxx.ld to just hello.ld
-Removed "-Dsourcerygxx" from linker command
-Defined the assembler specifically as arm-none-linux-gnueabi-as, rather than using arm-none-linux-gnueabi-gcc

Hopefully that's enough info, but I'll be happy to provide more. Thanks for any help.

Post edited by: rwentz, at: 2009/01/02 10:26

Post edited by: rwentz, at: 2009/01/02 10:37

Posted by rwentz

on Jan 02 2009 08:15 AM

Prodigy120 points

So I found a few issues with what I was doing, and I have what I think is a burnable image for hello now. For anyone else who runs into this in the future, here were my mistakes (that I know of):

1. I was using the arm-none-linux-gnueabi toolchain, when I should have been using arm-none-eabi instead.
2. I overlooked that the makefile was specifying the -T option, but not also specifying a linker script.
3. I had to remove the "-mthumb" and "-mcpu=cortex-m3" from the linker command line.

I now get an output "hello.axf" which "file" reports as "sourcerygxx/hello.axf: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped".

I'm a bit concerned about a couple things, and I have a feeling this may still not work, so I may be reporting back. First, I'm assuming "-mthumb" and "-mcpu=cortex-m3" were specified for a reason, but I'm not familiar enough with the gnu linker to know what including them or omitting them will change. Second, the original makefile from Luminary wanted a different linker script specifically for sourcerygxx, which wasn't included, so I just used the one that was. I'm not sure if I need a linker script at all though.

I'll see what happens...

Posted by rwentz

on Jan 02 2009 10:34 AM

Prodigy120 points

Onto a new problem now. I have my hello.axf, which I made a .bin out of using arm-none-eabi-objcopy. However, when I try to flash it, I get some issues, and the board just sort of sits there all lifeless-like.

Here's what I'm doing-
1. Start openocd with the following script:

Code:



 telnet_port 4444
gdb_port 3333
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board"
ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xbcd9
jtag_speed 10
reset_config srst_only
jtag_device 4 0x1 0xf 0xe
daemon_startup reset
target cortex_m3 little reset_halt 0
working_area 0 0x20000000 0x1000 nobackup
flash bank stellaris 0 0 0 0 0

This appears to proceed correctly, except that openocd always times-out waiting for halt after reset.

2. Connect to openocd via telnet.
3. Run "reset"
4. Run "halt"
5. Run "flash write_bank 0 /home/rwentz/projects/LuminaryArmExamples/DriverLib/boards/ek-lm3s6965/hello/sourcerygxx/hello.bin 0"

The last step gives the following errors:

not enough working area available(requested 8192, free 4056)
not enough working area available(requested 4096, free 4056)
Algorithm flash write 512 words to 0x0, 912 remaining
timeout waiting for algorithm to complete, trying to halt target
error executing stellaris flash write algorithm
flash writing failed with CRIS: 0x0
error writing to flash at address 0x00000000 at offset 0x00000000 (-902)
wrote 3648 byte from file /home/rwentz/projects/LuminaryArmExamples/DriverLib/boards/ek-lm3s6965/hello/sourcerygxx/hello.bin to flash bank 0 at offset 0x00000000 in 14.293038s (0.249247 kb/s)

My OpenOCD is the version from Ubuntu's repository:
rwentz@ultimate-badass:~$ openocd -v
Open On-Chip Debugger 1.0 (2008-06-22-10:54) svn:unknown
$URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $

Posted by spacewrench

on Jan 02 2009 13:38 PM

Intellectual530 points

Hi, I don't use CodeSourcery, but I am developing for LM3Sxxxx on Linux-64. (I use a self-built GCC toolchain, configured as TARGET=arm-elf.) For JTAG, I have a Wiggler-clone parallel port dongle, and I've also used both Ubuntu's openocd and a self-built version of openocd from the SVN repository. (Careful: they've made incompatible changes in the openocd code, so the config file for Ubuntu-openocd may not work with SVN-openocd.)

I've found that openocd is tricky to get working correctly, and it's sensitive to many factors (e.g., did you do a power-cycle of the target board, or just press the reset button? Did you unsuccessfully connect with JTAG, then restart openocd? Did you start openocd successfully, then stop it, then restart it again? Did you do a hard JTAG halt, or use the soft_reset_halt command?)

Anyway, the very first thing I've done with all the Luminary eval boards I have (I've played with 4-5 different ones) and an LM3S5732 board I designed myself, is to use JTAG only enough to get a serial bootloader installed. For all subsequent development, I load code using sflash, and I only get out the JTAG stuff if I absolutely can't figure out what's wrong with printf() debugging.

At some point early on, I couldn't find the right StellarisWare code for the serial loader (I think it was for the LM3S918 Intelligent Display Module board, which has the serial port on UART1 instead of UART0) so I wrote my own version. I also wrote my own sflash utility. If you'd like to look at or try them, let me know.

Here's my openocd.cfg file, which I use (when absolutely necessary) for talking to the FTDI chip on the 2965 CAN eval board (this is for SVN-openocd):

Code:



 
#daemon configuration
telnet_port 4444
gdb_port 3333
tcl_port 6666

#interface
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board"
ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xbcd9
ft2232_latency 3
jtag_speed 6

reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 10
jtag_ntrst_delay 10

# target configuration
target cortex_m3 little 0 0
#daemon_startup reset
#target  
#target arm7tdmi    
# 12k working area near base of ram
working_area 0 0x20000400 0x3800 nobackup
#target_script 0 reset ../doc/scripts/evb_lm3s811_test.script 

#flash configuration
flash bank stellaris 0 0 0 0 0

init
reset

Posted by rbarris

on Jan 02 2009 13:49 PM

Prodigy220 points

Don't forget to erase the flash first.

halt
stellaris mass_erase 0
flash (write whatever file)

Posted by rwentz

on Jan 02 2009 18:43 PM

Prodigy120 points

Between modifying my config file to match spacewrench's and erasing the flash (using "flash erase_sector 0 0 63") as rbarris suggested, I've managed to flash without any errors. But it still doesn't seem to do anything, so at this point, I assume I'm either linking the image wrong, or not "starting" it correctly.

As far as linking, I'm using the hello.ld linker script that is included with DriveLib, but here it is:

Code:



 
MEMORY
{
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
    SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00010000
}

SECTIONS
{
    .text :
    {
        _text = .;
        KEEP(*(.isr_vector))
        *(.text*)
        *(.rodata*)
        _etext = .;
    } > FLASH
    .data : AT(ADDR(.text) + SIZEOF(.text))
    {
        _data = .;
        *(vtable)
        *(.data*)
        _edata = .;
    } > SRAM
    .bss :
    {
        _bss = .;
        *(.bss*)
        *(COMMON)
        _ebss = .;
    } > SRAM
}

Then I'm just doing "arm-none-eabi-objcopy hello.axf hello.bin" to make the flash image. I also have to do "echo "" >> hello.bin" to word-align it. I've also tried making a binary copy with "-O binary". In both cases, the program doesn't seem to do anything.

I'm not sure if I need to do anything to "start" it besides hitting the reset switch, or using "resume" in openocd.

Thanks for your help.

Post edited by: rwentz, at: 2009/01/02 18:44

Posted by rbarris

on Jan 03 2009 03:33 AM

Prodigy220 points

I just hit the reset switch. CPU fetches the code start address from the vector table and away it goes.

Perhaps someone on the forum with a 6965 board could send you a hello.bin that is known to work, so we could home in on whether this is a build problem, a flash-writing problem, or some other kind of problem.

Posted by rwentz

on Jan 03 2009 18:02 PM

Prodigy120 points

I think I've gotten to the bottom of my current issue. I didn't realize that there was a "revc" version of the code for the 6965, which must be what I have, because building that version of hello works perfectly.

I figured this out by poking around in the DriveLib that gets installed by the Windows installer and flashing the prebuilt hello.bin that is included with that. However, I also noticed that the linker scripts are much more complex in that version, but it won't build with sourcery lite because it lacks some sort of "cs3" libraries.

Posted by rwentz

on Jan 03 2009 18:36 PM

Prodigy120 points

Here's another one - Trying to build the uart_echo demo. I get an undefined reference in interrupt.c to "CPUcpsie()". Anyone know where this function is defined?

Posted by rwentz

on Jan 04 2009 10:22 AM

Prodigy120 points

I figured that one out too - I started using "gcc" as my compiler type (instead of sourcerygxx) and got the latest update for the StellarisWare.

I've now written and successfully flashed a few programs, so I guess I'm all set up. Thanks for the help.

Posted by cb148787

on Jan 04 2009 16:34 PM

Genius4770 points

Forgive me - fog of battle - many changes/details...

Can you list your final configuration - which tools, which LMI version and have you some means to "debug?" Thanks in advance...

Posted by rwentz

on Jan 04 2009 21:32 PM

Prodigy120 points

No problem - I've confused myself a few times throughout figuring this out.

I haven't tried using a debugger yet with my configuration, so I can't comment on that (I've been using the UARTprintf() from the StellarisWare utils to "debug").

My environment is Ubuntu Linux x86-64.

My OpenOCD is from the Ubuntu repository. I got the FTDI driver from http://www.ftdichip.com/Drivers/D2XX.htm.

My OpenOCD config is as follows:

Code:



 
#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Stellaris Evaluation Board"
ft2232_layout evb_lm3s811
ft2232_vid_pid 0x0403 0xbcd9
ft2232_latency 3
jtag_speed 6
jtag_nsrst_delay 100
jtag_ntrst_delay 100

#use combined on interfaces or targets that can't set TRST/SRST separately
#reset_config srst_only
reset_config trst_and_srst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset

#target  
target cortex_m3 little reset_halt 0

#4k working area at base of ram
#working_area 0 0x20000000 0x1000 nobackup
working_area 0 0x20000400 0x3800 nobackup

#flash configuration
flash bank stellaris 0 0 0 0 0

I downloaded the latest StellarisWare for my board (lm3s6965_revc) from Luminary. This includes prebuilt images that you can use to test your OpenOCD config as far as flashing goes.

I'm using the free CodeSourcery Lite toolchain, which is basically a plain old gcc cross-compiler.

Once I verified that I could flash successfully, I built DriverLib and a few of the examples. You can, but don't really have to, set the COMPILER variable to "gcc" (gcc is the default, from what I can tell). I had initially tried changing it to "sourcerygxx", but had some linker issues.

I'm starting to run into some issues with flashing as my test image gets bigger (it usually fails once, then succeeds the second time), but by and large this is working well for me.

Let me know if you have any more questions.

Posted by cb148787

on Jan 05 2009 07:44 AM

Genius4770 points

Thank you - your details should be helpful to other Unix users...

Posted by DavidBrownell9026

on Aug 15 2009 09:43 AM

Intellectual870 points

Just for the record: you should be using much more current OpenOCD code; the release version is 0.2.0 today, and I think it was 0.1.0 when you asked, but you were using oldish code even then.

I've used the CodeSourcery compiler and current OpenOCD code with no particular issues ... though necessarily I avoid the nasty licensing of DriverLib.