SEGGER Forum

Faessle,

I experience the same issue with the NXP fast IO ports when using the IAR 4.42 EWARM tools and the JLINK. Basically, I have found that you cannot observe these ports either with the register view or memory view - else the debugger becomes corrupted. (I'm using the LPC2364) I do not know if this is a chip, JTAG, or debugger issue, but it is definitely a problem! I have also seen this issue with the LPC2148 device. There is no mention of this as an errata for the above NXP devices.

My workaround: Don't look at the fast IO registers. Or, copy then to a static variable if you can predict where you need to observe their contents!

Gary

Hello Gary,
Hello Faessle,

this is a problem in the NXP chips.
When the fast I/O ports are read in debug mode (using LDMIA instructions),
a write access to occurs to the address right after the last read.
J-Link reads up to 13 words at a time, so if you read an area of 0x100 bytes
at once, you will see problems at offset 13 * 4 = 52 = 0x34, 0x68, 0x9c and 0xd0.

Again, this is a problem in the chips, but there is a way to avoid this:

The problem does not occur if the fast I/O area is read by the chip in non-debug mode.
The J-Link software allows reading memory indirectly, basically downloading a piece
of code to RAM, which then performs the read operations to the fast I/O area.

There are 2 ways to activate use of indirect memory read for the fast I/O area:
a) You can use J-Link RDI and select the NXP device.
b) You can pass a string to the jlinkarm.dll (when using EWARM).

This is explained in the J-Link manual in section 5.3.1., Fast GPIO bug.

Can you please let me know if this solves the problem ? (it should)

Thanks,
Rolf

Manual says:
Select Use command line options in the Extra Options tap and enter in the
textfield --jlink_exec_command "map ram 0x40000000-0x40003fff; map indirec-tread
0x3fffc000-0x3fffcfff"

Hello Rolf,

I work with IAR 5.10 EWARM and JLINK on an LPC2148 chip. Faessle says that his fast I/O problem is lack of sync between the chip and the debugger, though the hardware works fine. According to my experience, this is not merely a reporting problem, but rather an actual corruption of the fast I/O port.

I have been using the workaround suggested in the JLINK manual, and this certainly solved the problem, but still, from time to time, the fast I/O registers become corrupted, under the following conditions: 1. Running the code from RAM, and 2. Stopping at a breakpoint.

Using a scope, I noticed that the IO register changes state AFTER the breakpoint has been reached, and while the debugger collected information from the target. Some further testing led me to the following assumptions/conclusions:

a) The ARM bug workaround is implemented for GPIO watch window display.

b) When breaking at some point in the code, the disassembler window collects target code bytes from an area located before and after the breakpoint address.

c) When running from RAM, the code starting area (~0x40000000) comes in close proximity with the fast IO SFRs.

d) If breaking at around 0x40000000+, the disassembler collects target data from below 0x40000000 without applying the workaround, corrupting the fast IO registers.

e) If the disassembler window is closed - the problem disappears.



Thanks

Gaby

Hello Gaby,

if the disassembly window shows (and therefor reads) memory before 0x40000000,
similar corruption can occur.

You should be able to get rid of this by enlarging the indirect read area as follows:

> map indirectread 0x3fffc000-0x3fffffff
instead of
> map indirectread 0x3fffc000-0x3fffcfff

Can you confirm that this solves the problem ?

Thanks,
Rolf

Hello Rolf,

No, I couldn't remap up to 0x3fffffff, but only up to 0x3ffffdff which is not enough. When remapping all the way, I get the exception "Indirect memory access timeout, core does not stop".

However, I found another workaround which works OK. I've added an exclude command to the remap command:

map exclude 0x3fffd000-0x3fffffff;

Now, neither the disassembly window nor the memory window interferes with my GPIO. It is evident that the NXP JTAG bug isn't limited to fast GPIO addresses, but is harming all the way up to the RAM area.

Thanks

Gaby

Hi Gaby,

thanks for the feedback.

map exclude 0x3fffd000-0x3fffffff;
is indeed the best solution since memory accesses to this area should be ignored.

We'll add this to the manual.

Best regards,
Rolf

Hello

I am using IAR EWARM 5.11 with a NXP 2468 CPU. This thread has been very helpful in understanding this problem. I have managed to use the map commands given to get around this problem using J-Link commander. However, I am still having problems within EWARM. I'm hoping someone can point out what I am doing wrong.

I am running the code from RAM and am stopping the CPU just using the halt button. The PC almost always ends up ~0x400037E0 since this is my idle loop. I ended the following into the textfield for the command line options. I used the higher RAM area since I am not currently using that region of RAM.

--jlink_exec_command "map ram 0x4000D000-0x4000Dfff; map indirectread 0x3fffc000-0x3fffcfff;map exclude 0x3fffd000-0x3fffffff;"

The most obvious sign of trouble is that the FIO1DIR - FIO4DIR registers are all showing the same value. This is not what they are suppose to be. Also all of the SET registers do not match what they are suppose to be.

Thanks

Chris

Hello Chris,

The NXP 2468 you're using is not on the NXP list of the "Fast GPIO bug" section in the JLinkArm manual. But let's suppose it is. There are two possibilities for wrong GPIO register values: a) the damned GPIO bug. b) faulty code. I think you should first convince yourself that your code is ok, by preventing the GPIO bug from occuring: If your register-display window is NOT set to GPIO, AND the disassembler window is off, AND no memory-display window is on (or at least not showing addresses below 0x40000000), then the GPIO bug cannot ruin your GPIO registers. You should be able to tell if your GPIO is configured properly by monitoring some output pins (LED, scope etc.) while your code is running.

I also suggest that in your idle loop you would copy FIOxDIR registers into some variables, so that when you stop the CPU, you'd be able to see the FIODIR values WITHOUT using the debugger GPIO window.

If and when you're certain that this is a Fast GPIO bug problem, we'll try to figure out why your workaround doesn't work.

Gaby

Gaby,

The 2468 needs to be added to the list for the GPIO bug. I can recreate this problem using only the JLink and the JLink Commander software. No code running on the target. I have LEDs and relays attached to some of the I/O and you can see and hear them change state with a simple read via the JLink Commander interface. When I enable the map indirect via this interface, I can read the registers without corrupting the contents.

The problem with EWARM appears to have been an extra character in the command string. I copied the string right out of the JLink PDF manual and pasted it into the EWARM dialog. I'm guessing that I picked up an extra control character somewhere in that process. I cleared the dialog and manually typed the command into the dialog window and now everything works fine.

Thanks.

-Chris