Odd Behavior - Crossworks and JTAG USB OCD Tiny

Hi There,

I’ve used Rowley Crossworks in the past with good success on an Olimex ADuC7026 board to make my own IMU.

I’ve recently dusted off my old OKI Olimex boards, and despite lack of flash programming guides for any of the Olimex code examples (huge point of contention in my view) I decided to start working with it again. I was happy to see that the copy of Crossworks I already own (1.6/1.7 personal) support the CPU/Board package, as well as the two JTAG devices I own.

1x Wiggler style olimex parallel port JTAG (1.6/1.7 - used with ADuC project)

1x JTAG USB OCD Tiny (1.7 - trying to use this now but running into problems).

I’ve found that the use of the JTAG Tiny causes random memory corruption even with the JTAG divider all the way up to 12 (I saw someone recommend 10), and while I can program/verify, debugging even the included examples eventually causes the program to vector to a seemingly random address, show me an assembly listing and get stuck there constantly calling the same instruction - sometimes this is a branch instruction, sometimes it seems to be an arithmetic instruction.

Switching over to the wiggler these problems go away. My first question is should the cable be shorter? I’ve seen another post with someone shortening their cable to get reliable performance, and wonder if I should do the same?

My next set of problems comes when I try to modify the example code which for example just blinks an LED (a crossworks included board example). It’s as happy as can be to run blinking that LED forever, but when I try to modify the code to loop through a large array doing write/read/compare to test the external SRAM (where variables are put by default according to the Crossworks memory map) I get the code vectoring off into the pABORT interrupt stub Before it reaches the point where the large variable should even exist!

When I see behavior that seems magical my first thought is that this is just another little detail of the hardware I’m not taking into account, but at the same time this is so darn simple it shouldn’t be doing this…

Thanks in advance for any input.

P.S. I’ve already looked up and disabled the watchdog timer (something the examples don’t handle, and while it doesn’t seem to interefere with them, I don’t want any nasty surprises later)

I use CrossWorks 1.7 with the JTAG TINY and it’s working great with a divider of 8 on my SAM7-H256 board. I just tried last night on my own board I made up and got verify errors. I haven’t tried anything to fix it yet.

I had problems running the JTAG TINY off of a USB HUB. You might want to try connecting it directly to your computer if it’s on a splitter, or it might just be finicky about the USB ports it uses. Also try changing the USB cable to a shorter one. If all else fails, reduce the length of the actual JTAG flat cable.

Thanks for the reply Thedirty,

I’m already running it from a direct USB port on the front panel, but I will try a shorter USB cable.

If I get this working it should solve the ‘magical behavior’ when programming the target, but this doesn’t really help me understand the interesting behavior of crossworks when I try to declare a few big variables.

Have you seen that problem crop up before with external SRAM?

-Cannibal

I have not used external ram with this, so I’m no help to you there. My experience is limited to SAM7S series.