I have seen a lot of work on mpis platform in svn over the last weeks. Are there plans to create a mips-embedded target or is this strictly mips-linux?

I am asking because modern PIC32MX Controllers from Microchip are mips based, I somehow prefer arm-microcontrollers but when you want to build something small and cheap the Microchip controllers still have an advantage because they are still available in DIL-28 or other (more or less)low pin count casings. For arm I only know of Cortex-M0 chips with low pin count, but as far as I understand fpc cannot target Cortex-M0 because there is no armv6m support in the compiler.

Michael

The PIC32 is on my list, I am busy with the AVR32 for now.

Michel

Michel Catudal wrote

I am asking because modern PIC32MX Controllers from Microchip are mips based, I somehow prefer arm-microcontrollers but when you want to build something small and cheap the Microchip controllers still have an advantage...

Same here.

AFAIK Microchip is planning PIC32 variants with even more internal RAM and ROM. Same would be very handy for our (and others) embedded controllers.

On the long ruin I am sure that we will see ARM controllers with a GByte internal RAM and a serial Flash interface and thus enable hardware designers to build a - cheap and easy to do - PCB with only a few connections that can run Linux. But up to that point the PIC32 is extremely viable.

-Michael

In our previous episode, Michael Schnell said:

Pity that they have a five stage pipeline though. Though the 16-bit lines now have more stalls too (the "e" series is further away from the 1 clock one 1 instruction principle than the "f" was).

I btw also have a pic32mx, but I don't use it. I ordered as an extra to play with for a 16/32-bits combined development board (explorer16) once, but we decided to stick with 16-bit instead.

Marco van de Voort wrote

Pity that they have a five stage pipeline though. Though the 16-bit lines now have more stalls too (the "e" series is further away from the 1 clock one 1 instruction principle than the "f" was).

I suppose the design goal was using as little hardware as possible (for price and power consumption) rather than providing better speed. Otherwise they should have been going for ARM instead of MIPS.

but we decided to stick with 16-bit instead.

Same here for the moment, as we are not yet actively planning a "high memory" controller based on PIC.

-Michael

Michael Ring wrote

I have seen a lot of work on mpis platform in svn over the last weeks. Are there plans to create a mips-embedded target or is this strictly mips-linux?

It shouldn't be too hard, hardest task is probably to create appropriate controller specific units.

This all sounds promising, I can contribute definitions for PIC32MX1/MX2 series of controllers.

Michael

I have a lot done on my AVR32 port, still got to figure out the compiler crash, in a few months I should be done and the PIC32 is high on my list. If you start a port before me let me know and I will contribute instead of starting my own.

Michel Catudal

Your timeline sounds fine to me, I am currently quite busy to get the openocd based debugging with lazarus right and, even more important, to write some _real_ code on arm systems. (I am currently porting my PIC based qlocktwo-clone to arm)

In case I get so bored in the next one or two months that I feel the urge to start before you I will definitely let you know, with some guidance I should be able to get at least something basic working... ;-)

Michael

Michel Catudal wrote

the PIC32 is high on my list.

GREAT !

fpc really is a model of a vivid community project.

Thanks,
-Michael

OK, I got kind of bored last weekend and started to implement mips-embedded target. The crosscompiler builds fine and already shows the list of (not yet implemented) pic32mx controllers, I am now searching through the code for places that I need to change.

One thing that makes me wonder is how mips and mipsel defines are related and when to use the 'mips' and when to use 'mipsel'.

Should I use 'mips' wherever posible or are those two really different architectures? (Well, OK, one is big and one is little endian, quite a difference)

There's one big favour I would like to ask, Florian, could you please enable mipsel-embedded in fpcmake and then re-generate the makefiles?

I have done this in my local copy but now a svn diff looks like a big mess because all those makefile changes make it hard for me to spot my code changes.

I have also had a look at the changeset for avr-embedded, there were a lot of changes in the codegen and other places, do you expect that the same will need to be done for mips or was avr a special case?

Michael

mips: mipsel and mipseb

Yes, I can do so.

I have done this in my local copy but now a svn diff looks like a big mess because all those makefile changes make it hard for me to spot my code changes.

Look at svn st -q to identify the changed files.

No.

or was avr a special case?

You must always distinguish between port to a new OS (like linux, "embedded", *BSD, ...) and port a to a new CPU (avr, arm, mips, ...).

BTW: Any news on Cortex-M0?

Perhaps I was not clear enough, when doing defines for embedded in the code should I use:

{$if defined(arm) or defined(avr) or defined(mips)}

or

{$if defined(arm) or defined(avr) or defined(mipsel)}

On Cortex-M0:

I received a J-Link Edu Probe today, it did not arrive in time before the weekend, so that was the reason why I was bored and started with mipsel-embedded ;-)

My guess is that the problems I had in debugging the Cortex-M0 Code were caused by the (somehow braindead) LPC-Link Probe, I will test this week if debugging works better with the J-Link probe.

Michael

It seems that Florian was not clear enough either:
- use mipsel if it applies to MIPS Little Endian only
- use mipseb if it applies to MIPS Big Endian only
- use mips if it applies to both MIPS Little and Big endian

Regards,
Sven

Michael Ring wrote

... pic32mx controllers ...

G R E A T !!!

unfortunately I don't currently do development on PIC32 yet, but I plan to upgrade our PIC24 based products to PIC32 some day.

I might be able to do some testing once you have a Beta version.

-Michael

Michael Ring wrote

... pic32mx controllers ...

BTW.:
AFAIK, the PIC controllers (16 and 32 Bit) use a propriety debug interface to be accessed by "PICKit" an "ICD-3" adapters. They do use a gnu based (though propriety made, and payed) C-compiler and linker . AFAI understand they use gdb under the hood and as there is the ("NETBeans" based "MPLab-X" IDE that runs as well on Windows as on Linux, it should be possible to use the Lazarus to debug a PIC32 device, if you can set up the Lazarus-gdb-interface appropriately.

Do you plan for allowing PIC32 development using Lazarus ? I suppose for that you not only need the gdb interface, but also a way to integrate MPLab-X originated library files to be integrated in the RTL to have the processor even start running.

And/or do you plan to allow for MPLab-X projects to integrate fpc generated units ?

Thanks,
-Michael

I did not yet invest much time in finding out if PICKit supports a GDBServer, but pic32mx chips do support jtag based debugging/flashing and openocd has pic32mx support. (see
http://www.microchip.com/forums/tm.aspx?m=346142, implementation started in 2008)

For me my gdb-interface to lazarus still has some rough edges, at the moment I mainly use gdb --tui or ddd for debugging low level (for cortex-m0) until I have figured out in more detail which rough edges I still have to cover in the lazarus interface.
When this is done you can use Lazarus for development, I do my coding already in Lazarus, and the debugging if I am on a cortex-m3 chip and do not need to go too deep into the implementation.

About MPlab Libs: I like to do things low-level so I prefer to implement my own objects for gpio and spi,.. as I need them.

Using the pre-build libs might be a lot easier but I am doing this for fun, my personal goal is not complete coverage of all aspects of a microcontroller but instead I want to be able to use a pic32, a cortex-m0 or cortex-m3 based on my hobby project restrictions, for example lqfp chips are hard to solder (at least for me, I am getting old ;-) ) and you need to take a lot of care when creating PCB's so I prefer either LPC-81x for very small projects that need only few lines of code and in future I would like to use pic32mx chips in soic or tqfp packages, they have roughly the same features as the cortex-m0/3 chips but are available in a lot of different packages.

For Cortex-M3 (which I currently use for main development) I use the excellent easy-mx pro v7 board from micro-e, but the translation to self-etched boards is difficult because those both nxp and stm only have lqfp for their cortex-m3 chips.

And/or do you plan to allow for MPLab-X projects to integrate fpc generated units ?

Definitely no, sorry ;-)

Michael Ring wrote

my personal goal is not complete coverage of all aspects of a microcontroller ...

Hmmm.

Regarding PIC, Microchip provides hundreds of variants of PIC32. They differ in the available I/O elements. The library that comes with MPLab X provides the basic defines, macros and functions for theses elements (not all do make sense, though) in a way that fits with the chip in question.

I don't see how this decently can be covered in pure Microchip - independent Pascal code.

-Michael

...
That is why my goal would be to be able to call fpc-generated functions (which should be rather independent of the chip-variant ) from a running MPLab-X projects, and be able to debug them using Lazarus.

-Michael

In our previous episode, Michael Ring said:

Afaik the 16-bit too, but it carries some additional remarks that seem to indicate it is only partially integrated and mainly used for boundery scan.

(I'm mostly dspicF and recently -E user but when I bought my explorer16 I also got a 32MX PMU)

I found the interface to open ocd to be very slow for flashing, basically useless. It might have improved since my last test. Check it on a regular basis.

I did communicate with Microchip about the debugger and they provided me with documentation on programming using the PE. As for debugging I didn't get a straight answer but will look into adding mips debugging to my debugger. JTAG MIPS debugging should be simple.

Take note that this is work in progress, it could be a while as right now I spend my spare time on the AVR32 Pascal Compiler and getting my funtoo and Ubuntu lazarus up and running on the Odroid U2. PIC32 is my next target. I will use the Raspberry Pi, Odroid U2 or Odroid X2 as the debugger platform. Rasphberry pi might need a command line debugger, graphic is a bit slow. Odroid U2 doesn't have GPIO access, perhaps the USB port might work fine.

Michel

Hi Michel!

You are talking about integrating mips into your debugger, what does this mean? Are you talking about Setedit or something else?

Michael

Michel Catudal wrote

I found the interface to open ocd to be very slow for flashing, basically useless.

Regarding PIC, I don't see any advantage for open ocd vs the Microchip adapters. PICKit is cheap and decently fast, ICD3 is really fast not too expensive either.

I understand that both are used via gdb when accessed by MPLabX, thus gdb --tui or ddd should work and making Lazarus work should be possible.

-Michael

If you find the time to find out how to actually start up & use their gdbserver I will be more than happy to integrate it into lazarus, right now I take what I can get and that seems to be openocd.

I have wasted quite some time in trying to make LPC-Link for the LPCExpresso Boards work and I do not want to duplicate this effort with another, also more or less undocumented tool unless I see no other choice (because flasing is dog slow, for example)

Michael

Mips to debug PIC32. I was looking at first at the Rasphberry pi, I may do that or use an Odroid U2 with the little remote IO thru USB that uses a PIC. For the AVR32 I will probably need to use the debugger JTAGICE thru Scientific Linux. Raspberry pi is nice that it has gpios but its graphic speed sucks. Odroid U2 might be great with the little remote IOs, don't know yet, I may end up using the Odroid X2 which has direct access to GPIOs. If I could get setedit working on the console without X that would be good enough on the Raspberry pi, I haven't been able to do that yet. It wants X. It actually works nicely with ssh as it uses the host X.

I work mostly with AVR32 UC3C because of my work in the automotive industry, but the PIC32 is looking more and more interesting. As you can see on my web page I have a C Compiler for the PIC32 with no limitation on optimization, it is basically done with a released source code from Microchip with the code that limits it removed. It lacks library but you can easily use the ones that Microchip has.

Personnally I usually prefer to do my own. What I plan to do on the PIC32 is basically what I am doing on the AVR32, is doing the modules outside of the compiler. There are too many parts so it will be easier to have the compiler being somewhat generic and have the startup code on the side of the application. The libraries would not be the same package as the compiler but an addon.

Right now there is a serious bug on the pascal compiler development that keeps my AVR32 implementation from compiling and that kind of stalls my progress. It crashes when it is time to compile the RTL. That is using the development tree. It compiled OK with the 2.6.0 release.

I have found a very interesting thing as I was trying to get fpc to compile for hard float on odroid U2. That is done on funtoo. I have created my own Linux installation on my odroid U2, it is funtoo hard float. I have even installed the mali 3D driver for X. I have created the Mate Desktop, actually running smootly. I got lazarus to work nicely this past sunday, hardware float. I installed funtoo on a 32G MicroSD card. I have yet to get the mali EGL to work with my funtoo. When using Ubuntu I can play movies from an external 200G hard disk connected on the USB port.

When I used the fpcbuild.zip snapshot it would crash when starting to compile the RTL, much like it does for my AVR32 pascal compiler. On the other hand when I use the fpc.zip snapshot it compiles beautifully and lazarus works great. I did have to copy the source to where lazarus wanted it. Something in the full package breaks the compiling for RTL.

Michel

Some people do not like the closed source of the debugger. OpenOCD is an option for them. I consider it in its infancy, I am sure that in time it will be much better.

If you need an option on an ARM or MIPS machine then you have few choices. For that MPLABX is not even an option.

Michel

As I mentioned earlier, I have enough information from Microchip to make a fast programmer. What I will need to add is debugging. Since I cannot get detailed debugging information from Microchip what can be used is the MIPS debugger. I read that some people are successfull with it. I would have to either use open ocd for the debugging or do my own. Since I want to do this on an ARM board, the debugger from Microchip is not an option. Their debugger is closed source.

Michel

Michael Ring wrote

If you find the time to find out how to actually start up & use their gdbserver I will be more than happy to integrate it into lazarus, right now I take what I can get and that seems to be openocd.

Maybe this helps....

http://olimex.wordpress.com/2012/07/23/ejtagproxy-opwn-source-gdb-interface-for-pic32-and-mips/

"EJTAGproxy open source GDB interface for PIC32 and MIPS"

They say "PIC-KIT3 <https://www.olimex.com/dev/pic-kit3.html> (ICSP) andARM-USB-TINY <https://www.olimex.com/dev/arm-usb-tiny.html>(JTAG) interfaces are supported."

-Michael

Michel Catudal wrote

As I mentioned earlier, I have enough information from Microchip to make a fast programmer. What I will need to add is debugging.

I would rather use PickIT or ICD3 than build my own hardware (in fact this would help those PIC users that can't do hardware themselves).

Here, EJTAGproxy looks interesting, but of course I don't know whether it is decently fast.

Maybe it really does not use use the debug interface built in the PIC chip (and supported by PICKit), but some kind of JTAG communication. This could be slow, because, AFAIK, PICKit out of the box does not internally do JTAG, but it can be made to do JTAG, as you can toggle each single communication pin via USB. OTOH, PICKit hardware is simple and it contains a PIC chip, so you can create and load your own JTAG enabled firmware, if you dare.

-Michael

Nice find, question is why did I not find this link ;-)

I etched some testboards yesterday and connected them to my ARM-USB-TINY, openocd detects the chip just fine but Michel was right, flash read performance is a mess, it took two minutes to read out the 32k flash of my pic32mx220 chip, that's pretty slow. I will check if a j-link or st-link work better, but I do not have high hopes.

But perhaps the ejtagproxy or pic32prog can solve this problem, will keep you posted.

Michael

I read some threads a frew days ago that openocd already works on Raspberry Pi over gpio, this might be just what you need if I understand you correctly. Fortunately I have still one Pi left @home to also try this......

http://code.google.com/p/picnc/wiki/OpenOCD_PIC32_Programmer

and

https://github.com/synthetos/PiOCD/wiki/Using-a-Raspberry-Pi-as-a-JTAG-Dongle

Michael

Michel Catudal wrote

When I used the fpcbuild.zip snapshot it would crash when starting to compile the RTL, much like it does for my AVR32 pascal compiler. On the other hand when I use the fpc.zip snapshot it compiles beautifully and lazarus works great. I did have to copy the source to where lazarus wanted it. Something in the full package breaks the compiling for RTL.

Could you (at best in a new thread) report the errors you got so that either your way of building or the bug in the AVR port can be corrected?

Regards,
Sven

That work was on fpc on Odroid for Odroid. I just mentioned that the bug looks a lot like the one I had with my AVR32 compiler. I will do as you ask but one about the ARM port and one on my AVR32 port if it turns out that I was right on my theory about the similarity. I checked last night the difference between the two and there are difference with regard to the RTL, I have not looked into details yet as I work during the day. My next task is to see if I can get a fully functional lazarus with hard float on Ubuntu on the Odroid U2. The one that comes with the Ubuntu I installed crashes often. The one I have on funtoo does not.

Michel

I finished first tests on memory read performance fot jtag probes/pic32, all on my Mac except the raspberry test:

Olimex TINY-H with openocd: 120 Seconds for 32k of data Olimex TINY-H with ejtagproxy: 10 Seconds for 1k of data, I did not have the patience to wait for the transfer of 32k ;-)

Raspberry PI with openocd in gpiomode: 50 Seconds for 32k of data

J-Link Edu with openocd: 30 Seconds for 32k of data

mikroProg from Mikro-E: approx. 8 Seconds for 32k (but no gdbserver and ICD Protocol on windows, only for reference)

ST-Link2: not yet tested.

pickit3 on ejtagproxy: not yet tested

I had high hopes for the Raspberry Pi solution because there's no USB transfer involved, sniff.....

J-Link performance is not stellar, but will be good enough for me right now.

If anybody has better results, please feel free to share on how you were able to get better performance.

Michael

You might want to try the new BeagleBone Black as it might be better for real-time machine control (and boots up in a more standard way) than the Raspberry Pi? A friend of mine put together a lot of this page: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Debian_Wheezy_Linux-Rt_Compile_LinuxCNC

The raphberry pi could be made into a nice device for programming and debugging. The graphic sucks so a headless device would be more usefull. OpenOcd is too generic, cannot be fast. My approach is a dedicated programmer for the PIC32 using the PE from Microchip. For debugging I would use openocd until I get my gdbproxy working. Rasphberry pi is only $35 which is cheaper than JTAG programmers. Rasphberry Pi is actually very fast if you don't have the X environment to slow it down. Once I manage to get setedit to work on the command line I will no longer need the X interface. The latest development on turbo vision seems to have locked it into using X. I am digging into this to uncripple it. What I would like to have is something just like we use to have on Dos.

My more interesting project is to have a full development system on an Odroid U2 or Odroid X2. The odroid is actually so fast that it rivals with some computers. It costs a little more, an Odroid U2 is $85, still cheaper than most JTAG programmers.

Michel

Michel Catudal wrote

using the PE from Microchip.

What is "PE" ?

If you intend to use a PIC as an interface chip why not just use a PICKit as the hardware and implement your software on same ?

In fact Microchip themselves sell the PICKit hardware with multiple firmware variants loaded (e.g. as an adapter to attach asynchronous and SPI data steams to USB.

-Michael

I did not do anything on PIC32, yet, but using the non-JTAG native PIC interface with PIC24 and PICKit performance is (AFAIRemenber) something like one second for 32 K and a fraction of a second using ICD3.

So JTAG with PIC is really disappointing.

-Michael

PE is a programming software that is uploaded to the PIC32. It increases the download speed quite a bit. What I am looking at is a very fast program by using GPIO instead of sending bit bang command thru USB. I do that stuff for fun, it distracts me from my automotive and military software I have to do day after day. Microchip provides this PE for free. I think that they use it with the PICKIT.

With the odroid they have a small interface ($15) that connects to the USB, I got two of those. I think that I should be able to upload some custom software to the PIC that is on board. The PIC is PIC18F45K5O-QFN. The only catch is that the compiler is $200, need to convince the finance minister (wife) unless I can find a cheaper one. If I can access enough GPIO on the Mele A2000G I might use that one for that. Hacking the Mele was kind of interesting as I had to be able to read a few Chinese words to change the language to French from the default Chinese. I have created a Gentoo with Mate desktop on that one. It is about half the speed of the Odroid but it has a connector for a sata hard disk, The odroid runs at 2Ghz and has a nice heatsink and a fan.

Michel

That is why the challenge is so interesting. My goal is to do something just as fast or faster with JTAG.

Michel

If you install some software on the target for self-programming, you of course can use any (serial) interface to transfer the user software and burn it into the Chip's Flash. That way an USB-to-serial Adapter providing async, SPI and/or I²C offers perfect speed. (As the serial USB Adapter you can use the PICKit hardware which is rather cheap and comes from Microchip pre-programmed with the appropriate firmware as "Serial Dongle" or similar.

Of course you can't (easily) do debugging via such a serial interface. here using the debug hardware built in the chip seems much more appropriate.

The debugging (and "hardware" Flash programming) pins of the PIC chips are not necessary handled in a "bit-banging via USB" mode. The ICD-3 Adapter (but supposedly not the PICKit) uses internal intelligence here and the image to be programmed is transferred in blocks of bytes via USB.

-Michael

Michael Ring wrote

If you find the time to find out how to actually start up & use their gdbserver I will be more than happy to integrate it into lazarus, right now I take what I can get and that seems to be openocd.

I don't think the term "gdbserver" is correct here (in a traditional way).

An IDE (such as DDD, Eclipse, Lazarus, ...) is supposed to access the "normal" gdb via the normal line interface (pipe), while gdbserver (aka the "gdb stub") is supposed to be accessed via the gdb (main) program itself via a dedicated gdb-internal pipe.

That is why there are two ways to make Lazarus do remote (and potentially cross-arch) debugging:

(A) Use gdb (compiled for the PC arch, maybe with respect to the target arch in order to allow disassembling etc) on the development PC and have it access gdbserver (compiled for the target arch) on the remote machine e.g. via a TCP/IP socket pipe.

(B) Have Lazarus via ssh start and access the command line of the normal gdb main program on the remote machine compiled for the target arch.

-Michael

I am talking about the connection to the processor. If you use JTAG this would be faster because you have more pins to bit bang with. With the Microchip specific hardware they use less pins so you have to do some multiplexing. If you have to wait for data to be done then the time saving with faster bit banging wouldn't help you.

With the PE you download that into the processor and then you just fill a buffer and tell the PE to copy into flash. Without the PE you need to program a word at a time. There is no way that you can compete in speed with Microchip's PICKit or ICD without this. I saw the source for the PICKit and it uploads the PE for reflashing. As for the emulator it is likely to use either the JTAG or Microchip's own hardware. The USB port is on the emulator and not the processor being debugged. There is some intelligence as in the Atmel and NEC debuggers for debugging but not for programming. For programming the PE is used. Since Microchip will not release information on their proprietary debugging we need to use debugger that support MIPS debug mode. I don't recall seeing debugging in the source code released for the PICKit. Correct me if I am wrong.

Michel

Not true. When debugging an AVR32 gdb is called avr32-gdb, a pic32 gdb would be called pic32mx-gdb. avr32-gdb talks to avr32gdbproxy for debugging and avr32program for programming. You could have a gdb version that talks directly thru jtag if you would spend the time writing it. You cannot use the on board gdb to debugger a foreign processor.

That is why there are two ways to make Lazarus do remote (and potentially cross-arch) debugging: (A) Use gdb (compiled for the PC arch, maybe with respect to the target arch in order to allow disassembling etc) on the development PC and have it access gdbserver (compiled for the target arch) on the remote machine e.g. via a TCP/IP socket pipe.

gdb has to be compiled for the target otherwise it will only support local opcodes.

The remote PIC32 or AVR32 do not have an operating system so it is illogical to think that there would be a gdb on that end.

Michel

Michel Catudal wrote

Without the PE you need to program a word at a time. There is no way that you can compete in speed with Microchip's PICKit or ICD without this.

... unless you recreate what the PICKit (rather the ICD3) does with a homebrew device (e.g. using PICKit hardware) and "driver" that communicates with the PC in a way you define (receiving blocks of data to be programmed) and handles the chip's interface appropriately.

Since Microchip will not release information on their proprietary debugging we need to use debugger that support MIPS debug mode.

Does this not help ?

http://ww1.microchip.com/downloads/en/DeviceDoc/51242a.pdf

Another way (without creating hardware) would be to find out how MPLABX interfaces PICKit or ICD3. I am convinced that they do use gdb in some way, but I did not easily find out more on this.

-Michael

Michel Catudal wrote

I don't recall seeing debugging in the source code released for the PICKit. Correct me if I am wrong.

In fact I did not take a look there, but I understand that with PICKit the lines are toggles vie USB and thus no such intelligence is necessary in the adapter. OTOH, I understand that ICD3 has built-in Intelligence to provide better performance with debugging and Flash programming.

-Michael

Michel Catudal wrote

Not true. When debugging an AVR32 gdb is called avr32-gdb, a pic32 gdb would be called pic32mx-gdb. avr32-gdb talks to avr32gdbproxy for debugging and avr32program for programming. You could have a gdb version that talks directly thru jtag if you would spend the time writing it. You cannot use the on board gdb to debugger a foreign processor.

That in fact is exactly what I meant to say. AFAI understand, these are "cross-gdbs", running on the PC, but compiled for supporting a "foreign" arch via some kind of interface (e.g. a programming adapter). But they are full gdb's being accessed by a command line interface. OTOH a "gdb-server" (or "stub") runs on the target device (that might be a different arch) and is to be accessed via a pipe interface by a "full" gdb program on a PC that - again - provides the command line interface that can be accessed by a Terminal or by Eclipse and friends.

gdb has to be compiled for the target otherwise it will only support local opcodes .

Yep.

-Michael

Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the "AVR ONE!" debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board.

Martin

I see.

I did not expect that someone would be inclined to go this way, as you need to implement the (published but rather "internal") gdb<->gdbserver pipe protocol, and additionally you need to do the arch-dependent interpretation in your own software rather than have gdb do this and provide the results via it's well-understood command line pipe interface.

But obviously you did have good reasons to do so. (Can you provide a short explanation, why ?)

What kind of interface does "AVR ONE!" provide ? Does it come with a gdbserver type of "driver" on the PC ?

BTW.: can you say anything regarding the PIC32 debugging issue ?

Thanks,
-Michael

You misunderstood. The chain is
MSEide->gdb->gdbserver->debughardware->target.

What kind of interface does "AVR ONE!" provide ?

AFAIK debugWIRE, PDI, aWire, JTAG, Nexus.

Does it come with a gdbserver type of "driver" on the PC ?

Yes.

BTW.: can you say anything regarding the PIC32 debugging issue ?

I don't use PIC32, sorry.

Martin

Not a PIC32, debugging is bound to be different. Most likely they have some similarity though.

Some USB message trapping!

To use ICD, an external system that supports ICD must load a debugger executive program into the microcontroller. This is automatically handled by many debugger tools, such as the MPLAB IDE. For PIC32MX devices, the program is loaded into the last page of the Boot Flash memory space. When not debugging, the application is free to use the last page of Boot Flash Memory.

The document in question has some information on the debug registers. There is no very much but that could be a start.

The part that is installed into the processor for programming is called Programming Executive (PE) You can find the document about programming on Microchip's web site.

pic32prog does use the PE

https://code.google.com/p/pic32prog/

Michel

Michel Catudal wrote

Some USB message trapping!

Nope. What I would try to do (if having some spare time) would by try to find out what file might do the gdb functionality (including the dwarf handling), hoping that same could be accessed by Eclipse as "gdb".

-Michael

Michel Catudal wrote

To use ICD, an external system that supports ICD must load a debugger executive program into the microcontroller...

I see. This obviously is different from, the way PIC24 is handled. This the debugging interface is just a communication pipe.

Now _hopefully_ they did use standards, and the "debugger executive program" is compatible with gdbserver (which makes sense as they do use the gnu compiler suite).

With that, it could be doable to use the cross gdb (for MIPS, running on PC) to access the PIC32 via the debug interface.

Maybe this is what EJTAGproxy does.

-Michael