Rowley CrossWorks Debugger Issues

Development Boards MicroMod
1

Has anyone else seen the error message “Error reading from memory” when trying to do even simple things in the CrossWorks debugger?

I get this message very frequently when trying to view CPU registers, watchpoints, stack backtraces, and other things and the error message is not very helpful (e.g. it never says exactly what memory it’s having trouble reading or why.)

Has anyone found any workarounds and/or configuration settings that mitigate this issue? I’m getting to my wit’s end with this–a debugger is supposed to help one debug a system, not contribute to the mystery of what’s going on behind the scenes. After all, this is a debugger, not a toaster–cryptic error messages have no place here.

2

I don’t think I’ve ever seen it. Have you tried Rowley support?

What JTAG interface are you using? You might have the clock set too fast.

Leon

3

How about cryptic help questions?

What hardware are you using? What have you tried?

4

leon_heller:
I don’t think I’ve ever seen it. Have you tried Rowley support?

What JTAG interface are you using? You might have the clock set too fast.

Leon

I've tried Rowley support and they thanked me for the suggestion to add more information, such as the memory address it couldn't read, to the error message.

My target is a Luminary LM3S1968 evaluation board connected to the debugger via the Luminary USB interface. This is an interface supported by Rowley and all of the debugger parameters are set to defaults.

As I mentioned, I see this error often when trying to examine registers, stack back traces, and other things that require the debugger to access the target.

It’s particularly annoying when, for example, I’m tracking done a rerely encountered problem. I set a breakpoint, hit it after 15 hours of running my code, go to look at the CPU registers and BAM! “Error reading from memory”. This makes it difficult to debug things when your debugger doesn’t let you see into the target system.

I also quite often see an issue where the target hits breakpoints, but the debugger gets lost. It knows the breakpoint has been hit, but can’t display the line of code where the BP was hit. Single setting from this point works, but blindly, in that the debugger doesn’t show the code being stepped, although it’s obvious that it is stepping (LEDs sequence correctly, for example, when stepping through code that toggles their state).

As another point of reference, the Luminary eval board came with a trial version of Code Red ARM tools. I tried this with my code and I don’t have any of the problems with the debugger I had with CrossWorks–same code and same hardware. No hickups reading memory and no “blind” breakpoints or single stepping.

I’m just a hobbyist, so Rowley’s $150 personal license is very appealing to me. Code Red is $1000, and they don’t have the equivalent of a personal license (as far as I know) for a lesser price. As a result, I need to stick with CrossWorks and find solutions to the issues that are making it difficult to debug my code.

5

Have you tried modifying the options for the USB JTAG? Try changing the clock divider.

I’ve also found these USB JTAG devices to be pretty sensitive when it comes to actual USB cables and USB hubs. You might want to swap things around and see if that helps.

6

TheDirty:
Have you tried modifying the options for the USB JTAG? Try changing the clock divider.

I’ve also found these USB JTAG devices to be pretty sensitive when it comes to actual USB cables and USB hubs. You might want to swap things around and see if that helps.

Thanks for the suggestions. I tried three different USB cables with the same result, so it doesn’t appear to be cable-related. I’m not using a USB hub.

Here’s CrossWork’s Luminary USB Debug properties and what I’ve changed so far:

Connected LED Inversion Mask: 0x0000 (default value, I haven’t changed it)

Connected LED Mask: 0x0000 (default value, I haven’t changed it)

Debug Interface Type: ADIv5 (default value, I haven’t changed it)

Device Type: Device ID: 0x3BA00477

Erase All: No

Erase All Timeout: 60,000 milliseconds

Fast Memory Accesses: Yes (I also tried No without any useful effect)

Identify Target: Yes

JTAG Clock Divider: 1 (default is 1; I tried 1 through 10 without effect)

Memory Access Timeout: 1,000 milliseconds (I tried 10,000 msec; no effect)

nSRST Inversion Mask: 0x0000 (default; I haven’t tried changing this)

nSRST Mask: 0x0020 (default; I haven’t tried changing this)

nTRST Inversion Mask: 0x0000 (default; I haven’t tried changing this)

nTRST Mask: 0x0000 (default; I haven’t tried changing this)

Output Pins: 0x00AB (default; I haven’t tried changing this)

Output Value: 0x00A8 (default; I haven’t tried changing this)

PID: 0xBCD9 (default; I haven’t tried changing this)

Processor Byte Order: Little

Processor Stop Timeout: 500 milliseconds (default; I haven’t tried changing this)

Running LED Inversion Mask: 0x0000 (default; I haven’t tried changing this)

Running LED Mask: 0x0000 (default; I haven’t tried changing this)

Serial Number: 0700016EA

User Serial Number:

Version: 1.0

VID: 0x0403 (default; I haven’t tried changing this)

I’d appreciate any guidance on what value changes to try.

7

Unfortunately I’m not much more help. Clock Divider is the only thing that I know that really effects reliability.

8

TheDirty:
Unfortunately I’m not much more help. Clock Divider is the only thing that I know that really effects reliability.

Thanks.

If anyone else has any suggestions, I’d greatly appreciate it. Debugging half blind is no fun at all. :cry:

9

I don’t know anything about the IDE/compiler/eval board you are using but is it possible that this is due to the jtag/gpio bug in some Luminary chips?

10

Hi

See the following: http://www.utasker.com/forum/index.php?topic=520.0

We also had problems with Rowley < 1.7.17 versions together with Luminary and this workaround helped. Maybe it is not your case (specifically it was due to the boot up method and the SP being trashed by the debugger, with subsequent memory access errors when it tried to work out the call stack, etc.) but Rowley patched this in the version V1.7.17 after some discussions about the cause. Check also the details about the correct debugger settings too.

Try also Crossworks V2.0 (if you aren’t already using it) since it has various improvements.

Regards

Mark

http://www.uTasker.com

11

Thanks for all the suggestions.

I finally solved all the issues I was having by upgrading to version 2 of CrossWorks. None of the issues with “Error reading memory” have appeared in this version, and as the Brits would say, I’m chuffed. Thanks Rowley.

If anyone reading this is still using CrossWorks 1.7, seriously consider upgrading to 2.0. The improvements are significant, the look of the IDE is much nicer, and it comes in versions for Mac OS X, Linux, and Solaris in addition to Windows.