#20 Newcdb displays invalid RAM data sometimes

[Julian Lamb]

Ricky,
I'm working with the F132 chip again, and am regularly seeing this bug again (I also saw it previously with a F120 board). In newcdb, after loading a file and running it for some time (using stepping, breakpoints, etc), the RAM memory eventially starts to be displayed incorrectly. Even the register banks are incorrect. When examining the data in newcdb, it either displays 0'x or incorrect data. However the ACC, DPTR, XRAM, and everything else still shows the correct data. The only way to correct this problem is to do a disconnect and reconnect with the board.
What's the best way to troubleshoot this? Is there a way to output all communication debug data to a file to examine later? I'm guessing there must be some issue with the way ec2drv examines RAM, and that some JTAG register is getting set incorrectly after some particular breakpoint action. I only see this with JTAG chips, BTW. Any insight on tracking this down would be helpful.

Thanks for your great work on ec2drv, BTW.

Cheers-
Julian

[Julian Lamb]

Logged In: YES
user_id=1709675
Originator: YES

I found the problem Ricky. I happened to finally trace the problem back to XDATA reads. After reading any XDATA from newcdb, the RAM data would forever be wrong. I ran some traces on the Silabs code and found there is a "close" sequence needed for JTAG XDATA reads. I've attached a patch which adds this sequence and fixes the problem.

Cheers--
File Added: patch.jtag_mode.c

[Julian Lamb]

Logged In: YES
user_id=1709675
Originator: YES

File Added: usbsnoop.log

[Julian Lamb]

Trace showing a read sequence

[Julian Lamb]

Logged In: YES
user_id=1709675
Originator: YES

I've been working on implementing data writing/changing through newcdb, and noticed a problem caused by my last patch. When writing to odd length XDATA portions, the jtag write code actually reads the last odd byte so it can write a 2-byte pair. However, I think adding the correct postamble to the read_xdata code actually kicked the write routine out of xdata mode. So, the solution is to read the odd data before even starting the xdata write. It should all work now.

Cheers--
File Added: patch.v2.jtag_mode.c

[Julian Lamb]

New version of patch to fix problems caused by last one