OpenOCD arm-elf-insight and FreeRTOS (LPC2148)

Development Boards MicroMod
1

I have had only minimal success thus far debugging with arm-elf-insight and OpenOCD.

I was able to debug in ram using sw-breakpoints and my elf file.

I could download to the target and hit my breakpoint in main() but as soon as I start the vTaskStartScheduler() at the end of main(), I never hit another breakpoint.

This is my environment:

  • Board: Olimex LPC2148, BSL is grounded.

    Software: FreeRTOS ported to lpc2148 plus test code

    JTAG Interface: Olimex Wiggler, LPT1 is using EPP, not ECP.

    OpenOCD: Using parallel port and lpc2148_pp.cfg (below, in the code section)

    Compiler Toolchain: GNUARM 4.1.1

    arm-elf-insight: 6.5.0.20060626-cvs, with the “monitor arm7_9 sw_bkpts enable”



    • lpc2148_pp.cfg

    #daemon configuration
telnet_port 4444
gdb_port 3333
 

#interface
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 0
 

# reset_config <signals> [combination] [trst_type] [srst_type]
reset_config trst_and_srst

#jtag scan chain
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 333
jtag_ntrst_delay 333
 

#target configuration, what to do on a target reset
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
daemon_startup reset
#target_script 0 reset openocd.script
working_area 0 0x40000000 0x4000 nobackup

 
# flash bank lpc2000 <base> <size> 0 0 <variant> <target#> <clock> ['calc_checksum']
# mthomas: LPC2138 @ 12MHz 0x7D000 from 500*1024 (not 512!)
flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum

    I have had a number of problems:

  • 1. Can’t debug from flash: I would bet that this is not having the correct cfg file for openocd.

    1. Can’t get insight to recognize my “.bin” files: I am using “arm-elf-objcopy file.elf -O binary file.bin” and file.bin is not recognized

    2. Once the FreeRTOS scheduler runs, RAM debugging goes out the window.



      3. I have 2 questions:

    3. Has anyone debugged past the FreeRTOS vTaskStartScheduler() method (i.e. into one of the scheduledTasks?)

    4. Can anyone provide me a better config for openOCD and LPC2148?

    Any help/suggestions would be greatly appreciated.

    • 2

    Hi,

    please make sure you’re using the latest version of OpenOCD. You can get precompiled binaries from www.yagarto.de.

    Regarding your individual problems:

    1. You have to use the “arm7_9 force_hw_bkpts enable” command. You can use it on the telnet command interface, put it in a .gdbinit file, or you can issue it via Insight, but you have to prepend it with “monitor” if it’s not used via telnet.

    2. Insight isn’t meant to use .bin files, these lack all the debug information. The .bin files are only necessary when using the OpenOCD to write to the target, either to RAM (load_binary command) or flash (flash write command). For Insight, use the ELF output file.

    3. Not sure what you mean.

    Best regards,

    Dominic

    3

    Thanks for your quick reply Dominic.

    I ran the following steps and I got the resulting Debug and Warning messages from openocd (–debug 3)

  • 1. Start openocd with these options: -f lpc2148_pp.cfg (see previous post) -d3 -lopenocd.log

    1. Started arm-elf-insight

    2. Loaded lpc2148_freertos.elf (this was built with -O0 and -g options and uses a linker script that targets flash, not ram)

    3. Issued ‘monitor arm7_9 force_hw_bkpts enable’ command in the insight console

    4. File->Target Settings and configured: Target->Remote/TCP, Hostname->localhost, Port->3333

    5. Run->Connect to Target (this succeeds)

    6. Run->Download (this fails)



      7. This produced the following error in insight:

    DOWNLOAD FAILED: Memory access error while loading the section startup

    This is the part of the openocd log output that was logged during the download

    Debug:   gdb_server.c:994 gdb_write_memory_binary_packet(): addr: 0x00000000, len: 0x00000044
Debug:   target.c:623 target_write_buffer(): writing buffer of 68 byte at 0x00000000
Debug:   arm7_9_common.c:1822 arm7_9_write_memory(): address: 0x00000000, size: 0x00000004, count: 0x00000011
Debug:   embeddedice.c:253 embeddedice_write_reg(): 0: 0x00000004
Debug:   embeddedice.c:157 embeddedice_read_reg_w_check(): 1
Debug:   embeddedice.c:157 embeddedice_read_reg_w_check(): 1
Debug:   embeddedice.c:253 embeddedice_write_reg(): 0: 0x00000005
Warning: arm7_9_common.c:1963 arm7_9_write_memory(): memory write caused data abort (address: 0x00000000, size: 0x4, count: 0x11)
Debug:   arm7tdmi.c:506 arm7tdmi_write_xpsr_im8(): xpsr_im: d3, rot: 0, spsr: 0
Debug:   gdb_server.c:177 gdb_put_packet(): sending packet '$E05#aa'
Debug:   gdb_server.c:124 gdb_get_char(): received '+'

    Also, for clarity:

    • The version of openocd I have is “snapshot r115 from SVN tree + giveio, no official release, compiled by mifi”

    • My third point might not make sense unless you have used FreeRTOS.

    In the main() routine, you start one or more tasks and then you call the scheduler.

    This scheduler will wake up once every 1ms and give the CPU to the next prioritized task in line.

    When this scheduler starts to run, I never hit one of my breakpoints that I set in one of my started tasks.

    Once again, thanks for the help,

    Grant

    • 4

    Hello Grant,

    I suppose lpc2148_freertos.elf was built to be run from flash. That’s why Insight/GDB tried to write to address 0x0, which (of course) failed, as there’s only flash at that address.

    If you want to debug code running in flash, you have to manually write the target flash. This can be done either from a telnet session, or from within Insight/GDB (For Insight/GDB use the ‘monitor’ keyword):

    flash probe 0

    flash erase 0 0

    flash write 0 /path/to/binary 0x0

    After that, don’t use the “Download” command. Use a “monitor soft_reset_halt” to initialize the ARM core, and continue execution from there, or reset the target, and attach later. It is not possible to debug a LPC2000 uC “out of reset”, as the content read protection (CRP) prevents that (even if CRP is not enabled).

    You could work around this problem by placing a loop that does many iterations at the beginning of your main() for example. Flash the target, reset it, and attach the debugger. The OpenOCD should have caught your target before it was able to complete the loop. You can then manually advance the loop counter so that the loop is quit.

    • Mifi’s versions are the most official binary releases available, so that’s fine.

    • Keep in mind that you can only have two breakpoints when debugging code in flash. This is a limitation of the ARM debug system. If you want to single-step your code, delete or disable your breakpoints, and enable them again before you’re ready to 'c’ontinue.

    Best regards,

    Dominic

    5

    I tried what you suggested and I still have issues.

    I followed these steps:

    1. Start openocd

    2. Open insight

    3. Load lpc2148_freertos.elf (built for debugging in flash with a beginning loop)

    4. Connect insight to target

    5. Downloaded lpc2148_freertos.bin to the target (using your method)

    6. Reset the target

    7. Clicked “run” icon

    Output from the insight console:

    (gdb) monitor flash probe 0
flash 'lpc2000' found at 0x00000000

(gdb) monitor flash erase 0 0 26
erased sectors 0 through 26 on flash bank 0 in 0s 531250us

(gdb) monitor flash write 0 
F:\EclipseWorkspace\FreeRTOS_LPC2148\lpc2148_freertos.bin 0x0
wrote file F:\EclipseWorkspace\FreeRTOS_LPC2148\lpc2148_freertos.bin to flash bank 0 at offset 0x00000000 in 2s 250000us
wrote file F:\EclipseWorkspace\FreeRTOS_LPC2148\lpc2148_freertos.bin to flash bank 0 at offset 0x00000000 in 2s 250000us

(gdb) monitor arm7_9 force_hw_bkpts enable
force hardware breakpoints enabled

(gdb) monitor soft_reset_halt
requesting target halt and executing a soft reset

(gdb)

    Output from the insight debugger window:

    Screen is blank (where the source code should be)

    On the bottom text bar there is "Program stopped at 0x7fffd2c0.

    The only icon that is active now is the “stop” icon.

    When I click it, it takes a few seconds for insight to respond and I get a warning pop-up that says: “Program received signal SIGINT, Interrupt”

    Is there something I have to do in my code to “enable” debugging?

    Are there some IO settings I need?

    Does the chip need a certain config in the pin connect block?

    Does the PLL need to be disabled?

    I think I am very close to having this working… any more hints would be very helpful and much appreciated.

    6

    Hi

    I am old fashioned (and old) and think that the first ting to do is to debug the HelloWorld.bin/elf program or the simple Blinky using the telnet interface. Without using any long scripts but writing the command in the telnet window, reading the result, checking the debug output in the openocd window, before entering the next command.

    YES This is slow, silly and oldfashioned (copy/paste from a text editor into the command window is allowed) but will teach us some good things:

    • does the basic communication work

    • we will learn the openocd commands, and understand the error messages

    • is the setup OK

    • is it a problem writing to flash or is my code buggy

    • can we halt/resume/reset, display memeory etc. directly before asking insight/gdb to do it for us

    Programming Power is knowing more than your tools !!!

    Regards,

    Magnus

    7

    I am getting the same king of problem here.

    please let me know how have you resolved this issue.

    Thanks,

    Mihir