ARM Cortex M3 debugging

[ac.verbeck]

All,

Attached is a DLL + instructions that can be used in conjunction with CodeLite to do embedded development with a ARM Cortex M3 using a Segger J-Link JTAG/SWD adapter. I have tested it with the MicroBuilder LPC1343 Reference Design and my own NXP LPC1313 design. It seems to work fine. It should work with any Cortex M3 device supported by Segger. I invite you all to try it. Feel free to comment on any aspect of this package: installation, documentation, operation, etc.

CM3.zip

Cortex M3 DLL + instructions

(851.89 KiB) Downloaded 310 times

Thanks for giving this a try,

ACV

[ktownsend]

In case anyone wants to use this with the canned LPC1343 CodeBase ... this is what I put for the "intermediate folder" under Common Settings "../../" (instead of I think "./Debug"), and I also changed the path for the GDB commands as follows:

Code: Select all

# Make sure that we are using SWD
monitor interface SWD

# Set monitor to little endian
monitor endian little

# Set monitor speed
monitor speed 1000

# Reset device
monitor reset

# Set device ID to LPC1343
monitor flash device = LPC1343

# Enable flash download
monitor flash download = 1

# Transfer the firmware to the device
load "../../firmware.elf"

# Initializing PC and stack pointer
monitor reg r13 = (0x00000000)
monitor reg pc = (0x00000004)

monitor reset

Other than that ... it looks great, though, and I'm extremely grateful you took the time to contribute this addition so that there's a real OSHW alternative for an IDE with embedded devices like the LPC1343.

I also modified the default makefile to compile with and without debug information:

Code: Select all

##########################################################################
# Debug settings
##########################################################################

# Set DEBUGBUILD to 'TRUE' for full debugging (larger, slower binaries),
# or to 'FALSE' for release builds (smallest, fastest binaries)
DEBUGBUILD = FALSE

I haven't published a new .zip file on the website yet, but I have pushed these updates to the GIT repository here: https://github.com/microbuilder/LPC1343CodeBase

Thanks again for taking the time to add this.

[ac.verbeck]

Update:
Generally, the DLL is working. I am able to do embedded debugging on the NXP LPC1313 and NXP LPC1343. CodeLite as a debugger is responsive and intuative. An example is the start up time. It takes about 6 seconds to load the code and run to main in CodeLite. In Keil MicroVision it takes 20seconds (roughly). Eclipse based environments are even slower but I do not have good metrics on this.

So far, three defects have been identified:

Defect #1:
ARM code restart: The DLL does not support program restarts. This was not addressed in the first release. I will fix this and post a new DLL.

Defect #2:
Adding breakpoints while running: If a breakpoint is added while the ARM code is running, the following happens:
a) the ARM CPU is halted
b) a breakpoint is added to the code at the desired line
The following does NOT happen:
a) A CodeLite breakpoint indicator is *not* placed on the line
b) The ARM CPU is not restarted
I believe this has to do with the mechanism used to break the ARM CPU. I need to revise this to get this function working properly.

Defect #3:
The GDB server can be come de-synchronised with CodeLite and the ARM CPU. This can lead to a number of different but similar artifacts, including:
a) Breakpoints that are visible in CodeLite not working
b) ARM CPU halts at a lines that do not have breakpoints
Workaround: be sure to delete all breakpoints between sessions and between different projects. I found a few crufty breakpoints from a defunct project can exacerbate this artifact. Starting with a "clean slate" -- so to speak -- seems to help.

Untested:
I have not attempted to set watch points or conditional breakpoints. I will test and report results.

Miscellaneous:
So far, no CodeLite crashes have been reported in using the DLL.

Resolution:
I believe all of these defects are in the DLL. I am going to dedicate some time over the next week or two fix these artifacts.

I believe that GDB through the CodeLite interface can display registers and machine code. I am going to write an application note to show how to access the vast power of GDB through CodeLite.

Take care all,

ACV

[rakesh.safir]

Hi ac.verbeck,

I'm very impressed by your work for the debugger and want to do the same using the FTDI's FT2232H chip, OpenOCD and GDB. Can you please guide me how to proceed.
Even though a I'm a newbie to GDB i would like to make the plugin for Remote Debugging using FTDI2232H chip.

Any help will be appreciated.

Rakesh