TMS320C28346: Wrong data written on XINTF - TMS320C28346

Tool/software:

I have a problem with data writes to the external interface of a TMS320C28x device. The setup is as follows:

• The TMS320C has the external memory interface activated and connected to an external CPLD. It is in 16 bit mode, only 8 address lines are used + CS, WR and RD.
• In the CPLD a memory interface is implemented. On top, the reveal analyzer (logic analyzer offered by Lattice running on the device) is used to probe data, address and CS, WR and RD signals.
• The interface should exchange data with the CPU. This works roughly, i.e., I read correct data and the data written to the CPLD is "usually" what I expect.
• The problem is, that on occasions that seem rather random, the data written to the CPLD is corruped (all zeros instead of specific values).

Initially I assumed that the problem is caused by failing timing constraints or signal integrity issues. However, when I analyze the logic analzer traces from the signals arriving in the CPLD it looks like the data written out by the CPU is indeed zero. See attached screenshots.

The code on the TMS was originally involving several ISRs and DMA transfers. It was not possible to predict whether the issue would show up or not. There was several occasions where it showed up ca. once a day to once every 5 min. However, in order to track down the error I removed everything possible. There is only a main loop left which writes data to the memory addresses of the CPLD. All interrupts, watchdog, timers and DMA are disabled (I also verified this by checking the according peripherial control registers in Code Composer Studio when executing the code). The board is known to work for years.

With this code the system now seems to work fine, at least while monitoring for 1 h there was no corrupted data showing up in the CPLD. However, once the memory browser in Code Composer Studio is used to observe the memory around address, where the CPLD is mapped (address 0x4000) with continuous refresh the issue is occuring at a very high rate (compared to what was observed witht the original code), i.e., few times every 10 ms. I was unable to identify a pattern or any peripherial improving/worsening the behaviour.

Disabling the continuous refresh of the memory monitor has two outcomes. In most of the cases it immediately stops the wrong writes, i.e., the data is correctly output on the bus. However, in some other cases just nothing happens and the TMS continues to write zeros to addresses which should be nonzero.

Any ideas on what possible reasons for the XINTF to output wrong data could be? Is this an issue related to the debugger? In earlier versions of the code removing the debugger didn't change anything. The board was also known to work for several years and I tried with an identical one, leading to the same results. I also attached the code defining the settings for the XTINF.

#include "XINTF.h"

// Initialize XINTF
void Init_XINTF()
{
	EALLOW;
	XintfRegs.XRESET.all = 1;
	EDIS;

	DELAY_US(50L);

	EALLOW;
	// XTIMCLK = SYSCLKOUT / 2
	XintfRegs.XINTCNF2.bit.XTIMCLK = 1;

	// Disable XCLKOUT
	XintfRegs.XINTCNF2.bit.CLKOFF = 1;

    // Zone 0 read timing
	XintfRegs.XTIMING0.bit.XRDLEAD = 3;
	XintfRegs.XTIMING0.bit.XRDACTIVE = 6;
	XintfRegs.XTIMING0.bit.XRDTRAIL = 3;

	 // Zone 0 write timing
	XintfRegs.XTIMING0.bit.XWRLEAD = 3;
	XintfRegs.XTIMING0.bit.XWRACTIVE = 6;
	XintfRegs.XTIMING0.bit.XWRTRAIL = 3;

	 // Double Zone 0 read and write lead/active/trail timings
	XintfRegs.XTIMING0.bit.X2TIMING = 1;

	// Zone will not sample READY
	XintfRegs.XTIMING0.bit.USEREADY = 0;
	XintfRegs.XTIMING0.bit.READYMODE = 0;

	// Size set to 16-bits in Zone 0
	XintfRegs.XTIMING0.bit.XSIZE = 3;

	 // Enable XTIMCLK
	SysCtrlRegs.PCLKCR3.bit.XINTFENCLK = 1;

	EDIS;
}