Hi There,

I want to debug my LPC2129 from olimex with the wiggler (also from olimex) so I installed al the tools from macraigor, but I get a code 43 error? I believe it's the most recent version (released a couple of days ago). It looks like a bug to me.

regards.

Hi,

Can you give more information please.

Latest version of OCDLibRemote or FreeRTOS?
What gives the error, OCDLibRemote?
When does the error occur - when you try to connect?
What host OS are you using?

Thanks.

ocdremote 2.08
freertos 2.54

commandline:
ocdremote.exe -c ARM7TDMI-S -p 2345 -d WIGGLER -a 2 -s 5

error: messagebox: "OCDemon ERROR: internal error 43"
OCDemon InitializeTarget Error : Cable Disconnected

board is configured like you discribed, os is windows xp, with macraigor cygwin envoirement

OCDRemote: 2.08
FreeRTOS: 2.5.4

OCDRemote: Messagebox "OCDemon Error, internal error 43".

command:
ocdremote.exe -c ARM7TDMI-S -p 2345 -d WIGGLER -a 2 -s 5

Windows XP SP1

I have version 2.01 of OCDLibRemote. The command line I use is:

OCDLibRemote --cpu ARM7 --device WIGGLER 1 --speed 1

on a Win2K host.

I have found in the past that several attempts are required to connect - with the OCDemon "InitializeTarget Error : Cable Disconnected" error given when the connection fails.

Try just repeating the command a few times when it fails to see if it ever succeeds.

If you want to give the OCDLibRemote version I use a go then send me an email (address on WEB site) - and I will send it to you.

OCDRemote is working now, I can debug on my evaluation board with 64k. But my target board has only 16k, is it possible to debug in flash? I already tried to build, then to flash with the philips tool, and then run the debugger, but that doesn't seems to work.

mmm, it seems that I get an error when I am debugging; when I enter the macro: "portRESTORE_CONTEXT", I get stuck on to:
0x4000003C <__dabt>: b 0x4000003C <__dabt>

Not sure that I have ever tried that - not with the Wiggler anyway. It works fine from flash using a USB JTAG tool so physically it must be possible (breakpoints within Flash that is). I would have to check how the breakpoints work within the microcontroller architecture.

Attaching to an executing application and the reset sequence would need looking at also.

Are you using the demo application as it was downloaded?

If not, is this the first call to portRESTORE_CONTEXT() - the one that starts the scheduler running. If it is then it is likely that the operating mode is not correct. You must be in system mode to start the first task.

it's indeed the first one, but I am in system mode. To be shure I wil test the demo app, sinds I was running my own application (one task).

I did something wrong in the sheduler, so that problem is solved. But still have to figger out how flash debug works, and is there a way to "map" registers in insight/gdb/ddd, so I can see some registers like spi/i2c more easely?

I'm not a GDB expert, but:

I know there is a way of getting a memory area to be displayed upon every break (or step, etc.). You could setup to display the i2c registers in the console everytime you break.

I think (from memory) this is done in two stages, first the command to display the memory, then the command to make this action occur on every break.

You can add these commands to the .gdbinit or gdb.ini file, so you don't have to enter them each debug session.

If you cannot find info on this in the GDB manual then try the gnu.gcc.help news group. If they cannot help they will surely be able to tell you where you can get the information.

You can also use the Keil and the Rowley tools with GCC. This give a much easier interface and I know operation from flash is easy. It comes at a cost of course with the Rowley tools being much less expensive. I have only tried with the USB debugger, but I think the Rowley tools also support Wiggler. Why not give it a try. There are FreeRTOS projects for both to get you going.

I too am having trouble with the latest OCDRemote, and same problem with OCDCommander. Both return an Internal Error 43, tried on 4 different PCs, different cables, all possible jumper settings.

Seems like the latest from Macraigor either doesn't like the Wiggler clones or just plain has a bug in it. If someone with a real Macgraigor Wiggler could check out the latest OCDCommander, that would be helpful.

I'll volunteer to figure out what needs to change in the Wiggler clones if OCDCommander works on a MacGraigor wiggler.

I think it's just a bug, I already emailed them, but they say there is no problem in the software; they want to sell me first a raven, which I don't want to buy.

I use the interface on www.amontec.com.
It can emulate wiggler, raven and other.
But with GDB and OCDRemote is very slow and buggy.
With IAR is perfect.
Wiggler emulation don't work, only Raven.

Regards.

I think you can use a wiggler with the Rowley interface. This might be an alternative.

Apparently now the ocdremote checks for a connection between pins 8 and 15 of the parallel port. Make sure they are connected.

Had the same problem with the Olimex part, but after the correction it seems fixed.

LA

Thanks for the follow up - this is very good information!