This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

XINTF works sporadically: TMS320F28334

Other Parts Discussed in Thread: TMS320F28334

Hi E2E-ers,

I'm having two custom PCB boards (one development board and one final board) and on both I'm using TMS320F28334 XINTF0 interface for reading out a 32bit external peripheral.

The strange thing is:

On the development board I'm able to read out XINTF0 data and I see xRD pin and address pins changing while read. But with the same project on the 'final' board it's not working!? Meaning I don't read data, pins are not changing. When I read with DMA, them DMA stalls (not counting DST and SRC registers).

I'm not using the "READY" option..

My XINTF configuration is:

void XintfInit(void)
{	/*Check for configurations conflicts using XINTFENCLK*/
 	if(	SysCtrlRegs.PCLKCR3.bit.XINTFENCLK == TRUE )  asm(" ESTOP0");
	EALLOW;
	SysCtrlRegs.PCLKCR3.bit.XINTFENCLK = TRUE;
    // All Zones---------------------------------
    // Timing for all zones based on XTIMCLK = 1x SYSCLKOUT
 
	asm(" RPT #7 || NOP; ");
    XintfRegs.XINTCNF2.bit.XTIMCLK = 0;
    // No write buffering
    XintfRegs.XINTCNF2.bit.WRBUFF = 0;
    // XCLKOUT is enabled
    XintfRegs.XINTCNF2.bit.CLKOFF = 0;
    // XCLKOUT = XTIMCLK
    XintfRegs.XINTCNF2.bit.CLKMODE = 0;

// Zone 0------------------------------------
     /* Source clock is 1/2 systemclock, so 75MHz (13,33ns CLK cycle)
     * 1 Xintf Read = 1Lead + (1+1)Active = 2CLK cycles = 40ns.
     * 1DMA period = 4 DMA reads = 4x40ns + 1DMAQ 'reset' = 173.33ns
     * 1 period = 33.333uS, so 1 period = 192 reads max, or 48 DMA periods each containing 4 reads.
     */
    XintfRegs.XTIMING0.bit.XWRLEAD = 1; 	//keep idle for n clockcycles
    XintfRegs.XTIMING0.bit.XWRACTIVE = 1;	//active for n clockcycles
    XintfRegs.XTIMING0.bit.XWRTRAIL = 0;	//keep idle for n clockcycles
    // Zone read timing
    XintfRegs.XTIMING0.bit.XRDLEAD = 1;
    XintfRegs.XTIMING0.bit.XRDACTIVE = 1;	//might  be two to get lower clock duty cycle.
    XintfRegs.XTIMING0.bit.XRDTRAIL = 0;

    // NOT double all Zone read/write lead/active/trail timing
    XintfRegs.XTIMING0.bit.X2TIMING = 0;

    // Zone will NOT sample XREADY signal
    XintfRegs.XTIMING0.bit.USEREADY = 0;
    XintfRegs.XTIMING0.bit.READYMODE = 0;  //

    // Size must be either 0,1 or 3:
    XintfRegs.XTIMING0.bit.XSIZE = 1;	// 0,1 = x32 or

// Zone 6------------------------------------
  // Zone write timing
  XintfRegs.XTIMING6.bit.XWRLEAD = 3;
  XintfRegs.XTIMING6.bit.XWRACTIVE = 7;
  XintfRegs.XTIMING6.bit.XWRTRAIL = 3;
  // Zone read timing
  XintfRegs.XTIMING6.bit.XRDLEAD = 3;
  XintfRegs.XTIMING6.bit.XRDACTIVE = 7;
  XintfRegs.XTIMING6.bit.XRDTRAIL = 3;

  // NOT double all Zone read/write lead/active/trail timing
  XintfRegs.XTIMING6.bit.X2TIMING = 0;

  // Zone will NOT sample XREADY signal
  XintfRegs.XTIMING6.bit.USEREADY = 0;
  XintfRegs.XTIMING6.bit.READYMODE = 0;  // sample asynchronous
  // Size must be either 0,1 or 3:
  XintfRegs.XTIMING6.bit.XSIZE = 1;	// 0,1 = x32 or

// Zone 7------------------------------------
  // Zone write timing
  XintfRegs.XTIMING7.bit.XWRLEAD = 3;
  XintfRegs.XTIMING7.bit.XWRACTIVE = 7;
  XintfRegs.XTIMING7.bit.XWRTRAIL = 3;
  // Zone read timing
  XintfRegs.XTIMING7.bit.XRDLEAD = 3;
  XintfRegs.XTIMING7.bit.XRDACTIVE = 7;
  XintfRegs.XTIMING7.bit.XRDTRAIL = 3;

  // double all Zone read/write lead/active/trail timing
  XintfRegs.XTIMING7.bit.X2TIMING = 1;

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

  // Size must be either 0,1 or 3:
  XintfRegs.XTIMING7.bit.XSIZE = 1;	// 0,1 = x32 or

  // Bank switching
  XintfRegs.XBANK.bit.BANK = 7;
  XintfRegs.XBANK.bit.BCYC = 7;

  EDIS;

  InitXintf16Gpio();
  InitXintf32Gpio();

   asm(" RPT #7 || NOP");
}

Best regards,

Tjar

  • Hi Tjar,

    We have following advisory in Errata document of this device.

    -----

    Advisory Memory: Possible Incorrect Operation of XINTF Module After Power Up

    Revision(s) Affected 0, A

    Details The XINTF module may not get reset properly upon power up. When this happens,

    accesses to XINTF addresses may cause the CPU to hang. This issue occurs only upon

    power up. It does not happen for other resets such as a reset initiated by the watchdog

    or an external (warm) reset using the XRS pin.

    Workaround(s) After coming out of reset, software should force a watchdog (WD) reset if WDFLAG = 0

    in the WDCR register. WDFLAG = 0 implies that an external reset occurred, for example,

    a power-on reset. After exiting the WD reset, WDFLAG will be 1. In this case, software

    should clear the WDFLAG bit before continuing normal code execution. This issue

    affects only the XINTF module.

    ----------

    Please check if this is taken care in your sytem.

    Regards,

    Vivek Singh

  • Hi Vivek,


    Wow great, this could explain it. But what's causing this "hangup" and how comes the XINTF in this "undefined state"? Has this to do with powering up sequence on different VDD pins? Because my other PCB, with different layout etc, is not failing.

    It's not sufficient to use XINTF HW-RESET?

    What about a debugger reset? That should in this case also reinitialize the XINTF, but it doesn't. After flashing and debugger reset the XINTF still hangs...

    Also if I power up my device, followed by an external (manual) reset, then connect CSS5 to the target and load my code then the XINTF is still locking up the DMA interface.

    Best regards,


    Tjarco

  • Hi,

    If I power up my device, followed by an external (manual) reset, then connect CSS5 to the target and load my code then the XINTF is still locking up the DMA interface.

    If I XHARDRESET the XINTF in debugger then I see that the DMA makes some steps, but then it stops again..

    Could the XINTF reads be hold up by other conditions? Like external pins?

    Best regards,

    Tjarco

  • Tjarco Boerkoel said:
    Wow great, this could explain it. But what's causing this "hangup" and how comes the XINTF in this "undefined state"?

    Tjarco,

    This is an marginality in the device. The workaround in the errata is the fix.  There is no board fix.   It seems that one of your devices is more susceptible to coming up in this condition.

    Regards

    Lori

  • Hi Lori,


    Thank you for your reply. So it's device specific, not board specific.

    I'm still having difficulties with XINTF. If I power up my device, followed by an external (manual) reset, then connect CSS5 to the target and load my code then the XINTF is still locking up the DMA interface. If I XHARDRESET the XINTF in debugger watchwindow and re-enable RUN then I see that the DMA making some steps, but then it just locks up again.. I don't get a grip on this issue, a bit frustrating. Why does it, even after HW reset, still failing on one board and working flawless on the other board with some code project?

    -Manually trigger PERINTFRC doesn't help.

    -Lower XINTF clock (XTIMCLK=1) doesn't help.

    -Skipping XINTF GPIO MUX configuration doesn't help.

    -Supply voltages on my board are good.

    -Direct reads from XINTF, instead of DMA read, doesn not help (locksup).

    -Pages are configured correctly, DMA and SW-based read all from ZONE0 0x00004000.

    -First configuration of XINTF, then configuration of DMA.

    Best regards,

    Tjarco

     

  • As addition on previous post:

    I've got 3 boards on which XINTF is NOT working. On one of the three boards I've replaced the CPU and again XINTF on this one is not working (DMA not running etc).

    Reset of XINTF does something, but again XINTF locks-up as described before. Stamp "CA-31AK2JW G4".

    I've got one three boards with a CPU from the same batch on which the XINTF IS working (DMA is running) without any problem.

    TI-ers What is going on!?

    Best regards,

    Tjarco

  • Hi TI-ers,

    I've been thinking: what could be the cause of the lockup of the XINTF module? I'm not sure how the CPU is routed internally, but is it the case that every (or some) module(s) have its own 1.8V VDD supply voltage? Or are they all tied together internally? Could a lockup of the XINTF core be cause by missing supply voltage, but still being able to configure the XINTF registers?

    Could the XINTF being blocked by state of external IO, even when USEREADY is set to zero (ignored) and READYMODE is zero? Or the state of some other IO pin like XWE1?

    XHOLD, XHOLDS and XHOLDAS register is not active (zero), WRBUF is set to 3 just being able to monitor any writes (which should not occur) and WLEVEL stays zero.

    I've also tried to run the XINTF module without MUX configuration, so just configured as normal GPIO. No difference.

    The XINTF registers of a locked XINTF:

    XintfRegs	struct _XINTF_REGS	{...}	0x00000B20@Data	
    	XTIMING0	union _XTIMING_REG	{...}	0x00000B20@Data	
    		all	unsigned long	70180	0x00000B20@Data	
    		bit	struct _XTIMING_BITS	{...}	0x00000B20@Data	
    			XWRTRAIL	0	0x00000B20@Data bit 0-1	
    			XWRACTIVE	1	0x00000B20@Data bit 2-4	
    			XWRLEAD	    1	0x00000B20@Data bit 5-6	
    			XRDTRAIL	0	0x00000B20@Data bit 7-8	
    			XRDACTIVE	1	0x00000B20@Data bit 9-11	
    			XRDLEAD	    1	0x00000B20@Data bit 12-13	
    			USEREADY	0	0x00000B20@Data bit 14	
    			READYMODE	0	0x00000B20@Data bit 15	
    			XSIZE	    1	0x00000B21@Data bit 0-1	
    			rsvd1	    0	0x00000B21@Data bit 2-5	
    			X2TIMING	0	0x00000B21@Data bit 6	
    			rsvd3	    0	0x00000B21@Data bit 7-15	
    	rsvd1	unsigned long[5]	0x00000B22@Data	0x00000B22@Data	
    	XTIMING6	union _XTIMING_REG	{...}	0x00000B2C@Data	
    		all	unsigned long	81919	0x00000B2C@Data	
    		bit	struct _XTIMING_BITS	{...}	0x00000B2C@Data	
    			XWRTRAIL	3	0x00000B2C@Data bit 0-1	
    			XWRACTIVE	7	0x00000B2C@Data bit 2-4	
    			XWRLEAD	    3	0x00000B2C@Data bit 5-6	
    			XRDTRAIL	3	0x00000B2C@Data bit 7-8	
    			XRDACTIVE	7	0x00000B2C@Data bit 9-11	
    			XRDLEAD	    3	0x00000B2C@Data bit 12-13	
    			USEREADY	0	0x00000B2C@Data bit 14	
    			READYMODE	0	0x00000B2C@Data bit 15	
    			XSIZE	    1	0x00000B2D@Data bit 0-1	
    			rsvd1	    0	0x00000B2D@Data bit 2-5	
    			X2TIMING	0	0x00000B2D@Data bit 6	
    			rsvd3	    0	0x00000B2D@Data bit 7-15	
    	XTIMING7	union _XTIMING_REG	{...}	0x00000B2E@Data	
    		all	unsigned long	4276223	0x00000B2E@Data	
    		bit	struct _XTIMING_BITS	{...}	0x00000B2E@Data	
    			XWRTRAIL	3	0x00000B2E@Data bit 0-1	
    			XWRACTIVE	7	0x00000B2E@Data bit 2-4	
    			XWRLEAD	    3	0x00000B2E@Data bit 5-6	
    			XRDTRAIL	3	0x00000B2E@Data bit 7-8	
    			XRDACTIVE	7	0x00000B2E@Data bit 9-11	
    			XRDLEAD	    3	0x00000B2E@Data bit 12-13	
    			USEREADY	0	0x00000B2E@Data bit 14	
    			READYMODE	0	0x00000B2E@Data bit 15	
    			XSIZE	    1	0x00000B2F@Data bit 0-1	
    			rsvd1	    0	0x00000B2F@Data bit 2-5	
    			X2TIMING	1	0x00000B2F@Data bit 6	
    			rsvd3	    0	0x00000B2F@Data bit 7-15	
    	rsvd2	unsigned long[2]	0x00000B30@Data	0x00000B30@Data	

  • Tjarco,

    Do I understand correctly that even with the errata workaround in place the XINTF module is not working correctly on the three boards? 

    The HOLD and the XREADY pins can stall the XINTF.  If you are ignoring XREADY in your timing then I don't see an issue there. 

    The voltage rails are connected internally to the device so if there is a current starvation issue it could impact one part of the device. 


    -Lori

  • Hi Lori,

    Thank you for your reply. I was afraid that this thread was going to die silently. Indeed, I'm still having the issue even with the workaround. I'll PM you some more bundled info about this. <edit> oh, It seems I'm not able to send personal messages?

    Well, The core voltage is 1V9 and the XINTF is neither operating as expected on sysclk of 75MHz.
    I'll copy some of the things I tried form the bundel info:

    Suggested solutions
    The issue is discussed on TI E2E community, but the only proposed solution was to reset the CPU once
    after power-up. This reset was needed because the XINTF could get in an undefined state when
    powering up stated in the Errata. This work around is not sufficient for board “B”. Powering up the
    board, HW-reset followed by JTAG debugger reset doesn’t solve this issue.

    Other
    - Several things are tried to narrow down the issue:
    - If I power up my device, followed by an external (manual) reset, then connect CSS5 to
      the target and load my code then the XINTF is still locking up the DMA interface.
    - If I XHARDRESET the XINTF in debugger watch window then I see that the DMA making
      some steps, but then it just locks up again.
    - Manually trigger PERINTFRC doesn't trigger DMA, still hangs on something.
    - Lower XINTF clock (XTIMCLK=1) doesn't help.
    - Lower SYSCLK (150MHZ to 75MHz) doesn't help.
    - Skipping XINTF GPIO MUX configuration doesn't help.
    - Supply voltages are good (1V9, 3V3).
    - Direct reads from XINTF, instead of DMA read, does not help (CPU hangs itself up).
    - Direct reads of memory 0x00004000 in debugger watch window hangs-up CPU.
    - Pages are setup correctly, DMA and SW-based read all from ZONE0 (0x00004000).
    - Configuration order: First configuration of XINTF, then configuration of DMA.
    - Check USEREADY to be zero (is zero)
    - Set WRBUF to 3 to verify the XINTF is not hanging in some “Write state”
    - Run the XINTF module without MUX configuration, so just configured as normal GPIO.

    Best regards,

    Tjar

  • Tjar,

    When the XINTF hangs do you see any activity on the bus/pins before it does?

    If you increase the timing of zone 0 is there any change? 

    It seems that the device config is working for all but board B.  So I'm suspecting something with this board.  I will ask a hardware person to take a look at this thread.  I'm running out of ideas from the silicon side. 

    -Lori

  • Hi Lori,

    Thank you for your reply. No the pins aren't doing anything (xRD, XA0,XA1) and I've increased timing with the "doubler" option but this didn't work either.

    And yes, it is strange that it is working on board 'A'. I'm already out of ideas ;)

    Best regards,

    Tjarco

  • Hi Lori,

    Well.. If I skip the EPwm GPIO outputs somehow the XINTF IS working..

        EALLOW;
    //    enable pwm pins after the pwm modules are configured !!!!!!!
        // EPWM modules 1-6
        //-----------------------------------
        GpioCtrlRegs.GPAMUX1.bit.GPIO0     = 1;        // EPWM1A
        GpioCtrlRegs.GPAMUX1.bit.GPIO1     = 1;        // EPWM1B
        GpioCtrlRegs.GPAMUX1.bit.GPIO2     = 1;        // EPWM2A
        GpioCtrlRegs.GPAMUX1.bit.GPIO3     = 1;        // EPWM2B
        GpioCtrlRegs.GPAMUX1.bit.GPIO4     = 1;        // EPWM3A
        GpioCtrlRegs.GPAMUX1.bit.GPIO5     = 1;        // EPWM3B
        GpioCtrlRegs.GPAMUX1.bit.GPIO6     = 1;        // EPWM4A
        GpioCtrlRegs.GPAMUX1.bit.GPIO7     = 1;        // EPWM4B
        GpioCtrlRegs.GPAMUX1.bit.GPIO8     = 1;        // EPWM5A
        GpioCtrlRegs.GPAMUX1.bit.GPIO9     = 1;        // EPWM5B
        GpioCtrlRegs.GPAMUX1.bit.GPIO10     = 1;        // EPWM6A
        GpioCtrlRegs.GPAMUX1.bit.GPIO11     = 1;        // EPWM6B


        // Trip Zones (TZ)
        //-----------------------------------
    //    GpioCtrlRegs.GPAMUX1.bit.GPIO12 = 1;    // TZ1
        GpioCtrlRegs.GPAMUX1.bit.GPIO12 = 0;    // function detection of PWM2B (=gpio3): input low = pwm2B (inv of 2A). High = enable
        GpioCtrlRegs.GPAPUD.bit.GPIO12 = 1;        // 0 = disable pull-up, generates trip when not connected.
        GpioCtrlRegs.GPADIR.bit.GPIO12    = 0;    //

        GpioCtrlRegs.GPAMUX1.bit.GPIO13 = 1;    // TZ2
        GpioCtrlRegs.GPAPUD.bit.GPIO13 = 1;
        GpioCtrlRegs.GPADIR.bit.GPIO13    = 0;    //

        GpioCtrlRegs.GPAMUX1.bit.GPIO14 = 1;    // TZ3
        GpioCtrlRegs.GPAPUD.bit.GPIO14    = 1;    //
        GpioCtrlRegs.GPADIR.bit.GPIO14    = 0;    //

        GpioCtrlRegs.GPAMUX1.bit.GPIO15 = 1;    // TZ4
        GpioCtrlRegs.GPAPUD.bit.GPIO15     = 1;
        GpioCtrlRegs.GPADIR.bit.GPIO15    = 0;    //
        EDIS;

    So I have a direction.. Maybe some trigger source icm TZ or maybe voltage issue after all... To be continue..


    Best regards,

    Tjarco

  • Hi All,

    Well I've got my finger on the issue. The XINTF/DMA blocks because of the state of TZ3 (GPIO14).

    If TZ3 IO is pulled low, the xRD goes also low and the DMA halts. If I release TZ3 DMA continuous and xRD strobes again. The strange thing is that TZ1 - TZ 4 are configured as TZ, but ONLY TZ3 results in halting DMA/XINTF.

    The trigger for DMA is TINT0, without sync option:

    DMACH1ModeConfig(DMA_TINT0,PERINT_ENABLE,ONESHOT_ENABLE,CONT_ENABLE,SYNC_DISABLE,SYNC_SRC,OVRFLOW_DISABLE,THIRTYTWO_BIT,CHINT_END,CHINT_DISABLE);

    <edit>

    I've placed a while loop just after main with inside the line        j=*(int32*)0x0004000;

    I ran my code, with DMA disabled, and it runs. But when I pull TZ3 low it hangs up my CPU!!! It continuous when I release TZ3. Just like a "power down, or pause feature".

    </edit>

    I'm able to reproduce all above on board "A", the board on which it seemed to work flawless.

    Is this the real reason for the power-up failure of the XINTF? Or is this another undocumented feature (or did I miss it) or is this abnormal behavior c.q. fault in design.

    Best regards,

    Tjarco

  • Tjarco,

    TZ3 on GPIO14 is muxed with the HOLD of the XINTF.  Have you turned of HOLD as described in the MUX for this pin?   I'm not sure why this wouldn't occur on the other rev of the board though.  hmm.

     

     

     

  • Hi Lori,

    I've set the XHOLD to TRUE to disable it and it's all fine now. You've mentioned the HOLD before. It's confusing when migrating from other C280x having TZ3 enabled and not "enabled" XHOLD and XREADY IO. Also that XHOLD is on by default (value 0).

    On the board "A" the TZ IO was unconnected and weak pulled up, so always high. On board "B" the TZ3 is low (trip state) because of the logic on the board resulting in disabled XINTF.

    Well, could the XHOLD be added to the example code for XINTF being disabled by default?

    Thanks for the support.

    Best regards,

    Tjarco

  • Tjarco Boerkoel said:

    Well, could the XHOLD be added to the example code for XINTF being disabled by default?

    Great suggestion, Tjarco.  I will file this request for our examples.

    I hope everything is still running well on your side!

    Lori