Codeblocks MCU / OpenOCD plugin

[martind]

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]

Hi Martin,

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:

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]

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]

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]

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]

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]

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

[BlueHazzard]

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]

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]

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]

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]

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]

 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]

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]

 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