Author Topic: Codeblocks MCU / OpenOCD plugin (Read 96784 times)

martind · « **on:** January 12, 2009, 02:45:47 am »

Hi All,

Although still very much a work in progress, I have placed my microcontroller / OpenOCD plugin code at:

http://developer.berlios.de/projects/cbmcu/

The plugin supports OpenOCD, but hopefully in the future will support the likes of Qemu etc...
I work mainly with ST and Microchip MCU's, so have been using it for STR7 and STM32 development.
I have placed a couple of screenshots also.

I am about to release a patch to enable cbEVT_DEBUGGER_STARTED, cbEVT_DEBUGGER_PAUSED and cbEVT_DEBUGGER_FINISHED which are needed for the plugin to work.

I welcome and comments, suggestions, fixes etc...

Thanks,

Martin.

stahta01 · « **Reply #1 on:** January 12, 2009, 03:31:45 am »

Directions to build workspace you need to set global variable "zip" to the folder that holds the zip executable.

Good work; I have only compiled it; but, it compiled well.

Tim S

mmkider · « **Reply #2 on:** January 12, 2009, 06:31:58 am »

Quote from: martind on January 12, 2009, 02:45:47 am

Hi All,

Although still very much a work in progress, I have placed my microcontroller / OpenOCD plugin code at:

http://developer.berlios.de/projects/cbmcu/

The plugin supports OpenOCD, but hopefully in the future will support the likes of Qemu etc...
I work mainly with ST and Microchip MCU's, so have been using it for STR7 and STM32 development.
I have placed a couple of screenshots also.

I am about to release a patch to enable cbEVT_DEBUGGER_STARTED, cbEVT_DEBUGGER_PAUSED and cbEVT_DEBUGGER_FINISHED which are needed for the plugin to work.

I welcome and comments, suggestions, fixes etc...

Thanks,

Martin.

I am very interested in this cbmcu.
Thank you for your cbmcu.

Joerg · « **Reply #3 on:** January 12, 2009, 11:00:29 am »

Hi Martin,

is this plugin just for starting OpenOCD,
or is it addressing the odd break problem too?
Do I need to download your sourcefiles via
SVN and then compile C::B ?

martind · « **Reply #4 on:** January 12, 2009, 11:35:59 am »

Hi,

Thanks for you comments.

Hi Tim. I have set the zip global but it stores it in my global conf file which you don't have... should have put a note sorry.

BTW I strongly recommend a seperate mcu.conf for your microcontroller version of CB so it does not get mixed up with your windows version. You can change this on the command line, but I have hard-coded my CB version.

Hi Rekisum. Yes it does address that old break problem that has given us grief. When the cbEVT_DEBUGGER_PAUSED event is received it establishes a telnet interface and executes halt. Need to create a proper queue for OpenOCD but I will in the future.

I have submitted a patch btw for the above events. I will post the patch here and on the cbmcu website.

Cheers,

Martin.

martind · « **Reply #5 on:** January 13, 2009, 11:14:00 pm »

Hi All,

Patch for debuggergdb.cpp to dispatch cbEVT_DEBUGGER_x messages.

Martin.

[attachment deleted by admin]

Joerg · « **Reply #6 on:** January 19, 2009, 10:43:28 am »

Hi martind,

some dump questions:
On the berlios project site I only found the sources via svn.
Does that mean I have to checkout these and copy them over
my codeblocks sources?

Just came to my mind:
If the break command does not work for us embedded remote
debugging freaks, does that mean it doesn't work for codeblocks
user debugging under windows either?
This can't be, right?
But whats the difference between sending a CTRL+C event to gdb
when debugging remotely and debugging erm.... 'not' remotely?

mmkider · « **Reply #7 on:** January 19, 2009, 12:45:22 pm »

Quote from: rekisum on January 19, 2009, 10:43:28 am

Hi martind,

some dump questions:
On the berlios project site I only found the sources via svn.
Does that mean I have to checkout these and copy them over
my codeblocks sources?

Just came to my mind:
If the break command does not work for us embedded remote
debugging freaks, does that mean it doesn't work for codeblocks
user debugging under windows either?
This can't be, right?
But whats the difference between sending a CTRL+C event to gdb
when debugging remotely and debugging erm.... 'not' remotely?

hi, rekisum：
I have a question.
how to send CTRL+C to gdb without console windows?
Thank you for your reply.

martind · « **Reply #8 on:** January 19, 2009, 03:05:38 pm »

Hi Reksium,

Sorry I need to write some docs... am working them...

You can check-out the SVN sources to anywhere you want.
Load the mcu workspace file in CodeBlocks. Ensure that the $(#cb) global variable is set to c:\...(wherever your codeblocks source is)..\src, and $(#zip) is set to point to zip.exe etc..

(BTW need to do some tweaks for Linux, I've been a bit windozy of recent)

Then build...and run your devel version.

The trouble I had with GDB is that to pause or break it, you would have to send a CTRL-C under windows, or SIGxx something or other under Linux. I could not do this programmatically under windows, and I don't think CodeBlocks can do it either.

So the work-around when debugging windows programs is to "prod" the program being debugged (Kernel break). This causes GDB to halt.
However, when debugging an embedded application, GDB is making a remote TCP/IP connnection (OpenOCD), therefore this is not possible. We have to tell OpenOCD to tell GDB to halt. And the simplest way I could think of was to telnet to OpenOCD and issue a "halt" command. Then it sends a command interrupt back to GDB.

Of course I bet there is some way of doing it, I just went for the easy "halt" option... perhaps somebody will come up with a solution.
However, if you run GDB in MI mode (change the interpreter), I believe GDB still has the command line available, even though it's debugging in the background. This might allow to queue a "stop" command on the fly.

Cheers,

Martin.

Joerg · « **Reply #9 on:** January 21, 2009, 03:39:58 pm »

Hi Martin,

after some wiki and forums reading I got so far that
I could load your mcuplugin.workspace and compile.
After compiling the linker complains:

Compiling: telnetclient.cpp
Linking dynamic library: D:\Dateien\VStudio\Codeblocks\trunk\src\devel\mcumgr.dll
C:\Programme\CodeBlocks\MinGW\bin\ld.exe: cannot find -lcodeblock

I did compile wx and c::b successfully but there is no codeblocks.a around?

c::b: svn 5394
cbmcu: svn 10

Joerg · « **Reply #10 on:** January 22, 2009, 10:17:21 am »

Hi, its me again ;-)

I got further, and could build all the project in your workspace.
I did compile cb earlier with the project files therein.
I didn't know I have to build them in your workspace in the right order.
Anyway, after building and running update.bat I got my own version own CodeBlocks :-)

Starting my STR7 project a screen shows up telling me to select a MCU.
Under Project/Properties there is a MCU tab.
But there is nothing to select there.
Probably I have to copy some plugin files to somewhere ?

Joerg · « **Reply #11 on:** January 22, 2009, 02:45:22 pm »

I copied the mcudrv directory to
\output\share\ CodeBlocks\plugins
Now I'm able to select MCU and settings.
A quick test lets me break the program.
After that the controller resets, maybe because
the active Watchdog of my STR7.

I'm missing the Envars and Library tabs in the project settings!

Joerg · « **Reply #12 on:** January 22, 2009, 02:59:48 pm »

I'm not able to set breakpoints
the breakpoint gets listed in the breakpoints tab
and the red circle appears
but nothing gets send to the debugger not directly
or over the openocd plugin

martind · « **Reply #13 on:** January 24, 2009, 01:43:04 am »

Hi Joerg,

I need to create the mcudrv directory if it does not exist... thanks for that...
I have an example project I will commit to SVN, these are the extra debug commands I send to the debugger:

In Project/targets options, debugger, additional commands after connection:

monitor soft_reset_halt
monitor mww 0xFFFFFF00 0x01
monitor reg pc 0x20000000
monitor ARM7_9 sw_bkpts enable
set remote memory-write-packet-size 1024
set remote memory-write-packet-size fixed
set remote memory-read-packet-size 1024
set remote memory-read-packet-size fixed
set remote hardware-watchpoint-limit 2
set remote hardware-breakpoint-limit 2
load
b main
continue

For an STR7 project.

Martin.

Joerg · « **Reply #14 on:** January 26, 2009, 10:55:05 am »

Hi martin,

I can't find your example project in svn yet.

I'm able to set a breakpoint once or twice
and the program stops as expected.
After that, setting of breakpoints doesn't work any more.
I don't know if gdb usually counts up the breakpoints every time,
but if i delete and set a breakpoint on the same line
I get the following output:

> delete breakpoints 3
>>>>>>cb_gdb:
> break "D:/Projekte/test-sw/src/MainTask.c:808"
Breakpoint 4 at 0x16c8c: file D:/Projekte/test-sw/src/MainTask.c, line 808.
>>>>>>cb_gdb:
> delete breakpoints 4
>>>>>>cb_gdb:
> break "D:/Projekte/test-sw/src/MainTask.c:808"
Breakpoint 5 at 0x16c8c: file D:/Projekte/test-sw/src/MainTask.c, line 808.
>>>>>>cb_gdb:
> delete breakpoints 5
>>>>>>cb_gdb:
> break "D:/Projekte/test-sw/src/MainTask.c:808"
Breakpoint 6 at 0x16c8c: file D:/Projekte/test-sw/src/MainTask.c, line 808.
>>>>>>cb_gdb:
> delete breakpoints 6

As only 2 breakpoints are available when debugging a program in FLASH
maybe the problem lies here?
I use 'monitor arm7_9 force_hw_bkpts enable' after connection.

Did you have a look for the missing tabs in the project/properties window?

I use an older OpenOCD version svn r520 and GDB 6.8.5.

martind · « **Reply #15 on:** January 26, 2009, 10:57:25 pm »

Hi Joerg,

There is no mechanism for counting breakpoints at the moment, and as you are using hardware breakpoints that is most likely the problem.
From memory there are 2 on the ARM7TDMI. I have done all my testing so far debugging from RAM, which has unlimited breakpoints. We do need a mechanism for limiting and I will add it to the list.

The missing tab sounds like the plugin is not being loaded. When you build the plugin, the plugin files (should) be automatically copied to the codeblocks plugin directory.

After compiling, in the $(#cb)\devel directory there should be libmcumgr.a. This is the mcu manager singleton shared between the mcu.dll plugin and the mcu sub-plugins.
In the $(#cb)\devel\share\CodeBlocks\plugins directory there should be mcu.dll
In $(#cb)\devel\share\CodeBlocks\plugins\mcudrv directory there should be the mcu sub-plugins libSTM32.a, STM32.xml, libSTR7.a, STR7.xml (and soon a generic driver but it's not on SVN yet).

Are you using windows or linux?

Martin.

Joerg · « **Reply #16 on:** January 27, 2009, 10:47:31 am »

Hi Martin,

Quote

There is no mechanism for counting breakpoints at the moment, and as you are using hardware breakpoints that is most likely the problem.

Setting and deleting breakpoints the normal way (without your plugin) worked for me.
(I heard gdb always counts up on every breakpoints, so that's not the problem
as I first thought.)

If I set the first breakpoint it doesn't get hit.
If I set the second one the first one gets hit but
gdb points to the code of the second one ! :shock:

Quote

The missing tab sounds like the plugin is not being loaded.

I was talking about the tabs 'Envars Options' and 'Library', expected to show directly after your new tab.
At least, I need Envars Options to compile.
Maybe a clean/build of c::b will put everything in place again?

martind · « **Reply #17 on:** January 28, 2009, 01:09:49 am »

Hi Joerg,

Not sure why your tabs are not displaying correctly.
I have comitted an STR7 demo project to SVN, you should be able to get that now. Do you want to give that a try?
Also, I have made a slight change to the patch I issued earler. I originally had cbEVT_DEBUGGER_FINISHED dispatched from here:

Code

void DebuggerGDB::Stop()

Which is OK, except when GDB fails to run because of an error. If an error occurrs, it does not stop OpenOCD. So it's better here:

Code

void DebuggerGDB::OnGDBTerminated(wxCommandEvent& event)
{
    m_PidToAttach = 0;

    m_TimerPollDebugger.Stop();
    m_LastExitCode = event.GetInt();
    //the process deletes itself
//    m_pProcess = 0L;

    ClearActiveMarkFromAllEditors();
    m_State.StopDriver();
    Manager::Get()->GetLogManager()->Log(F(_("Debugger finished with status %d"), m_LastExitCode), m_PageIndex);

    if (m_NoDebugInfo)
    {
        cbMessageBox(_("This project/target has no debugging info."
                        "Please change this in the project's build options and retry..."),
                        _("Error"),
                        wxICON_STOP);
    }

    // Notify debugger plugins for end of debug session
    PluginManager *plm = Manager::Get()->GetPluginManager();
    CodeBlocksEvent evt(cbEVT_DEBUGGER_FINISHED);
    plm->NotifyPlugins(evt);

    // switch to the user-defined layout when finished debugging
    DoSwitchToPreviousLayout();

    #ifdef __WXGTK__
    // kill any linux console
    if ( m_bIsConsole && (m_nConsolePid > 0) )
    {
        ::wxKill(m_nConsolePid);
        m_nConsolePid = 0;
        m_bIsConsole = false;
    }
    #endif
}

Martin.

Joerg · « **Reply #18 on:** January 30, 2009, 10:46:52 am »

I have updated and compiled your plugin project and codeblocks.
I've loaded the STR7 demo but it doesn't compile because the linker script is missing 'ram71x.ld'.

I had to change the openocd.cfg because I use the olimex tiny adapter:
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"

I didn't apply your new patch. Can you post a patch file?

I'm still missing the Envars/Options and Libraries tabs, here is a screenshot:

[attachment deleted by admin]

martind · « **Reply #19 on:** February 09, 2009, 01:53:50 am »

Hi Jeorg,

Ok sorry I use the SARM gnu toolchain we use at work, this already contains the ram71x.ld/rom71x.ld file.
I have attached my patch.

Martin.

[attachment deleted by admin]

woehlb · « **Reply #20 on:** January 29, 2010, 09:23:38 pm »

What license is subject to the plugin Codeblocks MCU?

If it is the GPL, it would be possible, you offer a Codeblocks with integrated Codeblocks MCU plugin.

anandamu16 · « **Reply #21 on:** February 02, 2017, 08:05:07 am »

I am looking for openOCD plugin that i can use with codeblocks. can u help?

BlueHazzard · « **Reply #22 on:** February 02, 2017, 11:20:06 am »

You can use the gdb plugin to work with OpenOCD. Start openocd and connect to it with gdb

You have to set up this settings:
Project->Properties->Debugger->Remote debugging support

For more information:
http://openocd.org/doc/html/GDB-and-OpenOCD.html
http://wiki.micromint.com/index.php/Using_OpenOCD/2

anandamu16 · « **Reply #23 on:** February 05, 2017, 08:30:49 am »

Hi,

I am looking for OpenOCD plugin to link it directly with my codeblocks. I have tried the link mentioned in above replies, but I guess those links had been expired.
Help me to get the plugin.

Thanks
Anand A.

BlueHazzard · « **Reply #24 on:** February 05, 2017, 01:36:25 pm »

As i told you, you can use OpenOCD without the plugin...
berlios is dead since a lot years i don't think you will find any code from there sry...

oBFusCATed · « **Reply #25 on:** January 06, 2019, 12:26:16 pm »

In fact the code for this plugin seems to be moved in https://github.com/martind574/cbmcu

@martind: Do you still use this plugin?

martind · « **Reply #26 on:** January 17, 2019, 04:13:02 pm »

Hello All,

Apologies - I have not used (or worked on this) for a few years now. I did put the code up on GitHub a while back, however over the next few days I will see if it still builds.

Martin.

RRomano001 · « **Reply #27 on:** November 23, 2019, 03:49:21 pm »

Hi just a question about embedded OCD:
I browsed source code, I seen at least support STM32, this is well supported on ST IDE and lack of STM32CUBE can be slowing development so I am not really interested port code to C::B nor fiddle with shades of STM devices.

Is this also supporting 8 bit ATMEL AVR I see integrated on C::B?

Again can be feasible to integrate an ICE Z80 and/or MC68HC11 Hardware debugger (FPGA IP Core + Old ICE) ?

Regards
Roberto

oBFusCATed · « **Reply #28 on:** November 23, 2019, 03:56:20 pm »

I'm not really sure what you're asking.
Can you please try to clarify?
Are you talking about debugger support or compiler support?

You're talking about three/four totally different architectures.
Which exactly does interest you the most?
Again compiler or debugger support doesn't fulfil your needs.

RRomano001 · « **Reply #29 on:** November 24, 2019, 11:39:45 am »

Hi Obfuscated, yes it need be more specific, sorry is not a simple task but as you can read on and suggested by you I decided avoid this way:

Actual project I am working in from a long time is a simulator and emulator of machine from the past (near 40 Yr old).
This work is related to legacy mcu and Z80 processors.
HC11 mcu code was written in assembly then I ported my code to C and compiled on modern MCU, this process never suffered problem of the past.
Z80 code was written by original manufacturer actually closed activity.

So I am working two way:

CodeBlock hosted supported simulator (my own source) both emulated processor with debugger (also in source). This is fine and deeply integrated to a mechanical software simulator running atop. This part is shared over a lot of module spreading across real hardware too.

Compiler from switches select if code has to be run by simulator (Linux) or real hardware machinery as is on multiple MCU.
When run as software all is on control, no hardware machinery was present and software can stop anywhere and restart pain free. Not same for motor and timing on real one so mus be driven by hardware CPU, this return a lot of feedback to simulator.

When run on FPGA legacy processor both processor are free running out of control and sometimes I feel the desire to analyze what happen on HW processor. (I don't own legacy source code)

When legacy processor run on IPCore FPGA feel integrate some sort of debugger.

Here is the plot of question:

-- Can be a good idea integrate some core of the past into C::B to debug external processor to get benefit of profiling and code analyzer tools?
vs
-- extend software debugger I wrote more than 10 Yr ago. It was not designed with hardware in mind do support real mechanical machinery.

After reading low level part of project opted to extend my old simulator code to integrate some sort of Hardware+Sw break point into IPCore and peripheral MCU firmware.

Actual implementation has original emergency stop integrated by new software layer security supervisor. It is not a big challenge to integrate a "break when is safe" but this is not really necessary when I evaluated all is around.

Actual Hardware can run much faster but need respect timing, this was done by Hardware synced single stepping reducing processor duty to near 2-5%. Core implementation leave a lot of time to collect trace code on fabric (cpu register and MCU's flags too) then transmit back by Ethernet leaving system running real time avoid crashing nor introduce error on mechanics.

Actual software debugger can easily be tailored to process stream data instead of software emulated processor.

From this and your writing too, discourage integrate these on C::B. Both processor still are used as teaching platform but my time is too much limited and I no more use C::B as teaching platform nowadays.

Thank a lot for hint and support.
Roberto

jjingwer · « **Reply #30 on:** October 12, 2020, 04:34:18 am »

I get code in https://github.com/martind574/cbmcu .
But I can not find configtargetdriver.cpp and and configtargetdriver.h in mcumgr
@martind: Does the plugins still work ?

News:

Author Topic: Codeblocks MCU / OpenOCD plugin (Read 96784 times)