TMS320F28335: a very weird issue on 28335 xintf interface

gang liu5,

Can you share your XINTF configuration and a code snippet of how you are reading/writing through XINTF?

When you say that the data is on the high 16 data bus, do you mean that pins XD[31:16] toggle while XD[15:0] remain static?

-Tommy

Tommy, thank

Hi tommy, thanks for your reply.  You are correct.  When dsp write to fpga, pins XD[31:16] toggle while XD[15:0] remain static.  The pic shows one read and one write operation.

the below is gpio and xintf init codes.  And I also tried give a watch dog reset after power up using user_init() function.

void user_init(void)
{
if(! (SysCtrlRegs.WDCR & 0x80)) // if reset is not caused by dog, raise a dog reset
{
EALLOW;
SysCtrlRegs.WDCR = 0;
EDIS;
}

}

void gpio_init(void)
{
EALLOW;

// set gpio mux
GpioCtrlRegs.GPAMUX1.bit.GPIO0 = 0; // nmi
GpioCtrlRegs.GPAMUX1.bit.GPIO1 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO2 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO3 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO4 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO5 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO6 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO7 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO8 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO9 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO10 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO11 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO12 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO13 = 0;
GpioCtrlRegs.GPAMUX1.bit.GPIO14 = 0; // gpio-xhold
GpioCtrlRegs.GPAMUX1.bit.GPIO15 = 0; // gpio-xholda

GpioCtrlRegs.GPAMUX2.bit.GPIO16 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO17 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO18 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO19 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO20 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO21 = 0;
GpioCtrlRegs.GPAMUX2.bit.GPIO22 = 0; // gpio-syn_tx
GpioCtrlRegs.GPAMUX2.bit.GPIO23 = 0; // gpio-syn_ty
GpioCtrlRegs.GPAMUX2.bit.GPIO24 = 0; // gpio-syn_tz
GpioCtrlRegs.GPAMUX2.bit.GPIO25 = 0; // gpio-syn_rx
GpioCtrlRegs.GPAMUX2.bit.GPIO26 = 0; // gpio-syn_ry
GpioCtrlRegs.GPAMUX2.bit.GPIO27 = 0; // gpio-syn_rz
GpioCtrlRegs.GPAMUX2.bit.GPIO28 = 1; // scirx
GpioCtrlRegs.GPAMUX2.bit.GPIO29 = 1; // scitx
GpioCtrlRegs.GPAMUX2.bit.GPIO30 = 1; // xa18
GpioCtrlRegs.GPAMUX2.bit.GPIO31 = 1; // xa17

GpioCtrlRegs.GPBMUX1.bit.GPIO32 = 0; // gpio-xint1
GpioCtrlRegs.GPBMUX1.bit.GPIO33 = 0; // gpio-xint2
GpioCtrlRegs.GPBMUX1.bit.GPIO34 = 0; // gpio-xready
GpioCtrlRegs.GPBMUX1.bit.GPIO35 = 2; // x_rw
GpioCtrlRegs.GPBMUX1.bit.GPIO36 = 2; // xzcs0
GpioCtrlRegs.GPBMUX1.bit.GPIO37 = 2; // xzcs7
GpioCtrlRegs.GPBMUX1.bit.GPIO38 = 2; // xwe0
GpioCtrlRegs.GPBMUX1.bit.GPIO39 = 2; // xa16
GpioCtrlRegs.GPBMUX1.bit.GPIO40 = 2; // xa0
GpioCtrlRegs.GPBMUX1.bit.GPIO41 = 2; // xa1
GpioCtrlRegs.GPBMUX1.bit.GPIO42 = 2; // xa2
GpioCtrlRegs.GPBMUX1.bit.GPIO43 = 2; // xa3
GpioCtrlRegs.GPBMUX1.bit.GPIO44 = 2; // xa4
GpioCtrlRegs.GPBMUX1.bit.GPIO45 = 2; // xa5
GpioCtrlRegs.GPBMUX1.bit.GPIO46 = 2; // xa6
GpioCtrlRegs.GPBMUX1.bit.GPIO47 = 2; // xa7

GpioCtrlRegs.GPBMUX2.bit.GPIO48 = 2; // xd31
GpioCtrlRegs.GPBMUX2.bit.GPIO49 = 2; // xd30
GpioCtrlRegs.GPBMUX2.bit.GPIO50 = 2; // xd29
GpioCtrlRegs.GPBMUX2.bit.GPIO51 = 2; // xd28
GpioCtrlRegs.GPBMUX2.bit.GPIO52 = 2; // xd27
GpioCtrlRegs.GPBMUX2.bit.GPIO53 = 2; // xd26
GpioCtrlRegs.GPBMUX2.bit.GPIO54 = 2; // xd25
GpioCtrlRegs.GPBMUX2.bit.GPIO55 = 2; // xd24
GpioCtrlRegs.GPBMUX2.bit.GPIO56 = 2; // xd23
GpioCtrlRegs.GPBMUX2.bit.GPIO57 = 2; // xd22
GpioCtrlRegs.GPBMUX2.bit.GPIO58 = 2; // xd21
GpioCtrlRegs.GPBMUX2.bit.GPIO59 = 2; // xd20
GpioCtrlRegs.GPBMUX2.bit.GPIO60 = 2; // xd19
GpioCtrlRegs.GPBMUX2.bit.GPIO61 = 2; // xd18
GpioCtrlRegs.GPBMUX2.bit.GPIO62 = 2; // xd17
GpioCtrlRegs.GPBMUX2.bit.GPIO63 = 2; // xd16

GpioCtrlRegs.GPCMUX1.bit.GPIO64 = 2; // xd15
GpioCtrlRegs.GPCMUX1.bit.GPIO65 = 2; // xd14
GpioCtrlRegs.GPCMUX1.bit.GPIO66 = 2; // xd13
GpioCtrlRegs.GPCMUX1.bit.GPIO67 = 2; // xd12
GpioCtrlRegs.GPCMUX1.bit.GPIO68 = 2; // xd11
GpioCtrlRegs.GPCMUX1.bit.GPIO69 = 2; // xd10
GpioCtrlRegs.GPCMUX1.bit.GPIO70 = 2; // xd9
GpioCtrlRegs.GPCMUX1.bit.GPIO71 = 2; // xd8
GpioCtrlRegs.GPCMUX1.bit.GPIO72 = 2; // xd7
GpioCtrlRegs.GPCMUX1.bit.GPIO73 = 2; // xd6
GpioCtrlRegs.GPCMUX1.bit.GPIO74 = 2; // xd5
GpioCtrlRegs.GPCMUX1.bit.GPIO75 = 2; // xd4
GpioCtrlRegs.GPCMUX1.bit.GPIO76 = 2; // xd3
GpioCtrlRegs.GPCMUX1.bit.GPIO77 = 2; // xd2
GpioCtrlRegs.GPCMUX1.bit.GPIO78 = 2; // xd1
GpioCtrlRegs.GPCMUX1.bit.GPIO79 = 2; // xd0

GpioCtrlRegs.GPCMUX2.bit.GPIO80 = 2; // xa8
GpioCtrlRegs.GPCMUX2.bit.GPIO81 = 2; // xa9
GpioCtrlRegs.GPCMUX2.bit.GPIO82 = 2; // xa10
GpioCtrlRegs.GPCMUX2.bit.GPIO83 = 2; // xa11
GpioCtrlRegs.GPCMUX2.bit.GPIO84 = 2; // xa12
GpioCtrlRegs.GPCMUX2.bit.GPIO85 = 2; // xa13
GpioCtrlRegs.GPCMUX2.bit.GPIO86 = 2; // xa14
GpioCtrlRegs.GPCMUX2.bit.GPIO87 = 2; // xa15

// set gpio direction
GpioCtrlRegs.GPADIR.bit.GPIO1 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO2 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO3 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO4 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO5 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO6 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO7 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO8 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO9 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO10 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO11 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO12 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO13 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO14 = 0; // input-xhold
GpioCtrlRegs.GPADIR.bit.GPIO15 = 0; // input-xholda
GpioCtrlRegs.GPADIR.bit.GPIO16 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO17 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO18 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO19 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO20 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO21 = 0; // input
GpioCtrlRegs.GPADIR.bit.GPIO22 = 1; // output-syn_tx
GpioCtrlRegs.GPADIR.bit.GPIO23 = 1; // output-syn_ty
GpioCtrlRegs.GPADIR.bit.GPIO24 = 1; // output-syn_tz

GpioCtrlRegs.GPADIR.bit.GPIO25 = 0; // input-syn_rx
GpioCtrlRegs.GPADIR.bit.GPIO26 = 0; // input-syn_ry
GpioCtrlRegs.GPADIR.bit.GPIO27 = 0; // input-syn_rz
GpioCtrlRegs.GPBDIR.bit.GPIO32 = 0; // input-xint1
GpioCtrlRegs.GPBDIR.bit.GPIO33 = 0; // input-xint2
GpioCtrlRegs.GPBDIR.bit.GPIO34 = 0; // input-xready

EDIS;
}

void xintf_init_zone7(void)
{
// Make sure the XINTF clock is enabled
EALLOW;
SysCtrlRegs.PCLKCR3.bit.XINTFENCLK = 1;
EDIS;

// Configure the GPIO for XINTF with a 16-bit data bus
InitXintf16Gpio();

EALLOW;

////////////////////////////////////////////////////////////////////////////
// configuration for All Zones
// Timing for all zones based on XTIMCLK = SYSCLKOUT/2
XintfRegs.XINTCNF2.bit.XTIMCLK = 1;

// Buffer up to 3 writes
XintfRegs.XINTCNF2.bit.WRBUFF = 0;
XintfRegs.XINTCNF2.bit.WLEVEL = 0;

// XCLKOUT is enabled
XintfRegs.XINTCNF2.bit.CLKOFF = 1;

// XCLKOUT = XTIMCLK
XintfRegs.XINTCNF2.bit.CLKMODE = 0;

// Disable XHOLD to prevent XINTF bus from going into high impedance state whenever TZ3 signal goes low. This occurs because TZ3 on GPIO14 is shared with HOLD of XINTF
XintfRegs.XINTCNF2.bit.HOLD = 1;

////////////////////////////////////////////////////////////////////////////
// configuration for Zone 7
// not double all Zone read/write lead/active/trail timing
XintfRegs.XTIMING7.bit.X2TIMING = 0;

// Zone write timing. When using ready, ACTIVE must be 1 or greater. Lead must always be 1 or greater.
XintfRegs.XTIMING7.bit.XWRLEAD = 1; // 0 xtimclk, 3 is max
XintfRegs.XTIMING7.bit.XWRACTIVE = 4; // 5 xtimclk, 7 is max
XintfRegs.XTIMING7.bit.XWRTRAIL = 1; // 1 xtimclk, 3 is max

// Zone read timing
XintfRegs.XTIMING7.bit.XRDLEAD = 1; // 1 xtimclk, 0 is invalid
XintfRegs.XTIMING7.bit.XRDACTIVE = 6;
XintfRegs.XTIMING7.bit.XRDTRAIL = 2;

// Zone will not sample XREADY signal
XintfRegs.XTIMING7.bit.USEREADY = 0;
XintfRegs.XTIMING7.bit.READYMODE = 0;

// 1,1 = x16 data bus
// 0,1 = x32 data bus
XintfRegs.XTIMING7.bit.XSIZE = 3;

EDIS;

// Force a pipeline flush to ensure that the write to the last register configured occurs before returning.
__asm(" RPT #7 || NOP");
}

gang liu5,

Please check to see if the FPGA is not releasing control over XD[15:0] during XINTF write operations.  It looks like the FPGA is still outputting 0x1234 during the write.

I assume that the XD[31:16] pins are under XINTF control and are alternating between High-Z during reads (internally pulled up to 0xFFF), and to 0s during writes (actively outputting 0 for 16b words).

-Tommy

Hi Tommy, it's a bug that fpga doens't release the lower 16 databus during dsp read.  I correctify it, but the issue is still there that dsp output data to higher 16 databus during dsp write.

Hi Tommy, I understood what you mentioned.  But my problem is I want to write 0x732C to FPGA, dsp outputs the data to xd[31:16].  It should be on xd[15:0] when the xintf is configured to 16b interface.  Am I right?

gang liu5,

I see what you are asking now.  I was only looking at the first set of transactions.

Can you disengage the FPGA as much as possible and write a series of diagnostics words to XINTF with a capture of the logic waveforms?  Let us know what the expected write values are so that we can try to trace the behavior in the waveforms.

-Tommy

hi Tommy, I use the below C codes to write data to FPGA, and the below pic shows dsp bus activities during writes.  You could see all dsp write data exist on xd[31:16].  BTW, my dsp part number is TMS320F28335ZJZQ  (CA-6BA05YW).  Waiting for your help, thank you very much.

for (;;)
{
fram[0] = 0x1234;
fram[1] = 0x5678;
fram[2] = 0xabcd;
fram[3] = 0xef01;}

gang liu5,

I would make the assertion that driving 16b data out to XD[31:16] when accessing a zone configured for 16b access is highly unlikely (if not impossible) based on the XINTF design. Can you double-check the bus definition for your waveforms?

If the bus definition looks right, we will then want to check on the declaration for fram[]. Another thing to try would be to manually write data to Zone 7 through the CCS memory window.

-Tommy

Hi Tommy, this is fram definition in c source file.  I tried output data in CCS memory window, the result is same.

#define FPGA_SIZE_16B 0x40000

#pragma DATA_SECTION(fram, "ZONE7DATA");

typedef unsigned int Uint16;

volatile Uint16 fram[FPGA_SIZE_16B];

and the below is cmd file:

MEMORY
{
PAGE 0 :
/* BEGIN is used for the "boot to SARAM" bootloader mode */

BEGIN : origin = 0x000000, length = 0x000002 /* Boot to M0 will go here */
RAMM0 : origin = 0x000050, length = 0x0003B0
RAML0 : origin = 0x008000, length = 0x001000
RAML1 : origin = 0x009000, length = 0x001000
RAML2 : origin = 0x00A000, length = 0x001000
RAML3 : origin = 0x00B000, length = 0x001000
ZONE7A : origin = 0x240000, length = 0x000400 /* XINTF zone 7 - program space */
CSM_RSVD : origin = 0x33FF80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
CSM_PWL : origin = 0x33FFF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */
ADC_CAL : origin = 0x380080, length = 0x000009
RESET : origin = 0x3FFFC0, length = 0x000002
IQTABLES : origin = 0x3FE000, length = 0x000b50
IQTABLES2 : origin = 0x3FEB50, length = 0x00008c
FPUTABLES : origin = 0x3FEBDC, length = 0x0006A0
BOOTROM : origin = 0x3FF27C, length = 0x000D44

PAGE 1 :
/* BOOT_RSVD is used by the boot ROM for stack. */
/* This section is only reserved to keep the BOOT ROM from */
/* corrupting this area during the debug process */

BOOT_RSVD : origin = 0x000002, length = 0x00004E /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAML4 : origin = 0x00C000, length = 0x001000
RAML5 : origin = 0x00D000, length = 0x001000
RAML6 : origin = 0x00E000, length = 0x001000
RAML7 : origin = 0x00F000, length = 0x001000
ZONE7B : origin = 0x200000, length = 0x040000 /* XINTF zone 7 - data space */
}

SECTIONS
{
/* Setup for "boot to SARAM" mode:
The codestart section (found in DSP28_CodeStartBranch.asm)
re-directs execution to the start of user code. */
codestart : > BEGIN, PAGE = 0
ramfuncs : > RAML0, PAGE = 0
.text : >> RAML1 | RAML2, PAGE = 0
.InitBoot : > RAML1, PAGE = 0
.cinit : > RAML0, PAGE = 0
.pinit : > RAML0, PAGE = 0
.switch : > RAML0, PAGE = 0

.stack : > RAMM1, PAGE = 1
.ebss : > RAML4, PAGE = 1
.econst : > RAML5, PAGE = 1
.esysmem : > RAMM1, PAGE = 1

IQmath : > RAML1, PAGE = 0
IQmathTables : > IQTABLES, PAGE = 0, TYPE = NOLOAD

/* Uncomment the section below if calling the IQNexp() or IQexp()
functions from the IQMath.lib library in order to utilize the
relevant IQ Math table in Boot ROM (This saves space and Boot ROM
is 1 wait-state). If this section is not uncommented, IQmathTables2
will be loaded into other memory (SARAM, Flash, etc.) and will take
up space, but 0 wait-state is possible.
*/
/*
IQmathTables2 : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
{

IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

}
*/

FPUmathTables : > FPUTABLES, PAGE = 0, TYPE = NOLOAD

DMARAML4 : > RAML4, PAGE = 1
DMARAML5 : > RAML5, PAGE = 1
DMARAML6 : > RAML6, PAGE = 1
DMARAML7 : > RAML7, PAGE = 1

ZONE7DATA : > ZONE7B, PAGE = 1

.reset : > RESET, PAGE = 0, TYPE = DSECT /* not used */
csm_rsvd : > CSM_RSVD PAGE = 0, TYPE = DSECT /* not used for SARAM examples */
csmpasswds : > CSM_PWL PAGE = 0, TYPE = DSECT /* not used for SARAM examples */

/* Allocate ADC_cal function (pre-programmed by factory into TI reserved memory) */
.adc_cal : load = ADC_CAL, PAGE = 0, TYPE = NOLOAD

}

gang liu5,

How are you capturing the waveform data?  Is it a logic analyzer monitoring the signals on the board or is it captured through the FPGA?

I would very much like to confirm that dsp_data_h is mapped correctly to the XD[31:16] pins.  This can be done by configuring XD31 to be a GPIO with a static output and confirming its impact on the waveform viewer.

-Tommy

Tommy, I didn't see your reply which is put on the second page.  Actually, I always was waiting for your reply. ^_^

Yes, the wave was captured from FPGA, I just monitor the data bus and didn't drive it at all.  I configured all xd[31:16] to data bus, otherwise I can not write data to FPGA.

right now, even dsp read data from xd[15:0] and write data to xd[31:16], it works for FPGA now.  But I have a another nvram which is also connected to DSP using xd[15:0], such problem stops me to use nvram correctly.

gang liu5,

I don't think that I can effectively debug this remotely.

Would you modify the "xintf_run_from" example from C2000Ware such that you see the same XD[31:16] behavior and attach the modified  Example_2833xCodeRunFromXintf.c file to this thread?

It will be easier to understand the behavior if I can observe it locally.

-Tommy

Tommy, I'll do it and send you result later.  Thank you very much

gang liu5,

Are you still working on an example?

-Tommy