Debugging Arm Cortex M3

[ndivner]

Hi all

I am running Codelite V3.0.5156 WinXP SP3.

I have an embedded Cortex M3 project which I can debug using Eclipse Helios + Zylin plugin and also by using msys mintty.exe command line successfully.

When I try to use Codelite it almost works.
I can connect to the target, do a symbol load, set breakpoints but it does not break properly and show the breakpoint line.
Step and next do not work.

I am attaching a log of the various outputs.

Any suggestions and help appreciated.

Best regards,

Noel

[ndivner]

Hi,

I have got loading and stepping through source code working.
Your suggestions to the other "Debugging Post" gave me the answers to my problem (thanks)

My setup is as follows

Menu->Settings->Debugger Settings->GNU gdb debugger->General

Debugger Path = H:\Ayrenet-dev\CodeLite\MinGW\opt\arm-2011.03-42\bin\arm-none-eabi-gdb.exe

Options "Apply breakpoints after main function is hit" disabled
so that only box now checked is "Raise Codelite when breakpoint is hit"

Debugger Tooltip both boxes checked

Display no boxes checked and "number of elements to display" is left at "200"

Menu->Settings->Debugger Settings->GNU gdb debugger->Misc

"Enable full debugger logging " checked
"Show debugger terminal" checked
all others clear

Menu->Settings->Debugger Settings->GNU gdb debugger->Startup Commands
leave empty.

Setup project settings (debug configuration)
right click->project->settings->Debugger
"Select debugger path" = arm-none-eabi-gdb.exe
"Debugging remote target" checked
"Host/tty:" localhost "Port" 3333
"Enter here any commands that should be passed to debugger on startup" is left blank
"Enter here any commands that should be passed to debugger after attaching the remote target"
load
break main

That completes the configuration
To start debugging
1. Program the flash. I use a Olimex "arm-usb-ocd" jtag dongle
2. Start up openocd as a gdb server using the Olimex dongle
3. Press the "Start or Continue Debugger" button on the toolbar

Stepping and most other debug activities work but of course because it is an embedded ARM processor
some things will not work. Registers and Memory come to mind.

Questions for Eran.
I have taken a look at the Code and it appears that a plugin could be developed to complete the job.
So I am wondering if you have any suggestions etc on the best way of going about this which would
save me some time and in keeping with the way you like to do things.

I must say I was quite excited when I saw this working and I would like to say that you have done
an awesome job in getting CodeLite to where it is.

Best regards,

Noel Diviney.

[eranif]

So I am wondering if you have any suggestions etc on the best way of going about this which would
save me some time and in keeping with the way you like to do things.

the debugger is developed as a dll but it is not like other plugins (it does not comply to the same rules of the other plugins nor it shares the same interface)
However, since gdb is pretty much core part of the IDE (when it comes to C++), I am willing to change codelite to support any other functionality you think are missing (for example, as a C++ programmer, I don't see the dissembly as a must feature, but you might think otherwise)

Let me know what you think should be added

Eran

[ndivner]

Hi Eran,

Thank you for the prompt response. It is appreciated.

However, since gdb is pretty much core part of the IDE (when it comes to C++), I am willing to change codelite to support any other functionality you think are missing (for example, as a C++ programmer, I don't see the dissembly as a must feature, but you might think otherwise)

Ok
My view is that CodeLite is a great IDE for Embedded development and debugging capability is mandatory.
When it comes to evaluating code efficiency one has to resort to Assembly Code so being able to display the assembly code
is a most desireable objective.

I would like to discuss all of this with my colleagues and then continue this discussion. I appreciate your willingness to explore the idea.

I will report back with the results of our discussions.

Best regards,

Noel

[ndivner]

Hi Eran,

I have had discussions with my colleagues and it has been agreed that we would like to have a bash at extending CodeLite for Embedded Arm debugging.

I have already added a project template for the Stm32 Cortex M3 which I have attached for your perusal. In it you will notice that the "Debugger type" is still the "GNU gdb debugger" as it is quite useable for embedded debugging but lacks the essential functionality of "Core registers" tab, "SFR (Peripheral Registers)" tab and of course a disassembly code window.

My thinking is to have a new DLL which uses the existing functionality and includes the inhancements. It would be invoked by means of the "Debugger type" when creating a new executable "Project" in the workspace. I am using a StMicro evaluation board for testing and a Olimex USB jtag dongle for programming the flash and debugging. The Olimex dongle is used in conjunction with openocd with the combination able to do both the flash programming and a gdb remote server. These operations are invoked by having 2 "External Tool" configurations which can be clicked as required.

There are a number of different arm chips in the Cortex family, namely, M0, M1, M3, M4, A5, A7, A8, A9 and A15. which means a largish number of DLLs. As a great part of each DLL's functionality is the same I am thinking that it should be possible to organsise things along the lines of "Base Class" and a "Derived Class".

I would appreciate your comments on the above.

I will able to supply patches for review.

Thank you and best regards,

Noel Diviney.

[ndivner]

I have already added a project template for the Stm32 Cortex M3 which I have attached for your perusal.

Oops!! I forgot to attach the project xml file

Cheers Noel.

[ndivner]

Hi,

As this topic is more of a development and "work in progress" topic I am moving to "Development/Patches" section

See "CodeLite Embedded Extensions"

Noel.