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.

TMS320F28335: XINTF issue during high frequency reading

Part Number: TMS320F28335

Hi,

Customer is using F28335 XINTF to connect FPGA for their application, to simulate external RAM. 

Now they find one issue about XINTF reading. The data bit 3 (only bit 3) is wrong in this situation. What could be the issue?

1) First execute InitI2cForGpio(), then InitXintf();

2) Set/Clear the GPIO in this way: GpioDataRegs.GPBDAT.bit.GPIO32 = 0;

3) Increase the reading frequency to 20ms, the issue will happen frequently.

But, if we do in this way, there's no issue:

1) First execute InitXintf(), then InitI2cForGpio();

2) Set/Clear the GPIO in this way: GpioDataRegs.GPBCLEAR.bit.GPIO32 = 1;

3) Do NOT call InitI2cForGpio();

4) Increase the reading frequency to 20ms, the issue will NOT happen.

During the reading, we checked the registers of GPIO and XINTF, all were correct. After the wrong reading, F28335 can still write the right value to external RAM, and then can read the right value back. But, several times later, wrong bit 3 will be read again. 

And the XINTF init code is as:

static void InitXintfGpio(void)

{

    EALLOW;   

    GPIO_2_OFF;   

    GpioCtrlRegs.GPCMUX1.bit.GPIO64 = 3;  // XD15

    GpioCtrlRegs.GPCMUX1.bit.GPIO65 = 3;  // XD14

    GpioCtrlRegs.GPCMUX1.bit.GPIO66 = 3;  // XD13

    GpioCtrlRegs.GPCMUX1.bit.GPIO67 = 3;  // XD12

    GpioCtrlRegs.GPCMUX1.bit.GPIO68 = 3;  // XD11

    GpioCtrlRegs.GPCMUX1.bit.GPIO69 = 3;  // XD10

    GpioCtrlRegs.GPCMUX1.bit.GPIO70 = 3;  // XD19

    GpioCtrlRegs.GPCMUX1.bit.GPIO71 = 3;  // XD8

    GpioCtrlRegs.GPCMUX1.bit.GPIO72 = 3;  // XD7

    GpioCtrlRegs.GPCMUX1.bit.GPIO73 = 3;  // XD6

    GpioCtrlRegs.GPCMUX1.bit.GPIO74 = 3;  // XD5

    GpioCtrlRegs.GPCMUX1.bit.GPIO75 = 3;  // XD4

    GpioCtrlRegs.GPCMUX1.bit.GPIO76 = 3;  // XD3

    GpioCtrlRegs.GPCMUX1.bit.GPIO77 = 3;  // XD2

    GpioCtrlRegs.GPCMUX1.bit.GPIO78 = 3;  // XD1

    GpioCtrlRegs.GPCMUX1.bit.GPIO79 = 3;  // XD0

 

    GpioCtrlRegs.GPBMUX1.bit.GPIO40 = 3;  // XA0/XWE1n

    GpioCtrlRegs.GPBMUX1.bit.GPIO41 = 3;  // XA1

    GpioCtrlRegs.GPBMUX1.bit.GPIO42 = 3;  // XA2

    GpioCtrlRegs.GPBMUX1.bit.GPIO43 = 3;  // XA3

    GpioCtrlRegs.GPBMUX1.bit.GPIO44 = 3;  // XA4

    GpioCtrlRegs.GPBMUX1.bit.GPIO45 = 3;  // XA5

    GpioCtrlRegs.GPBMUX1.bit.GPIO46 = 3;  // XA6

    GpioCtrlRegs.GPBMUX1.bit.GPIO47 = 3;  // XA7

   

    GpioCtrlRegs.GPCMUX2.bit.GPIO80 = 3;  // XA8

    GpioCtrlRegs.GPCMUX2.bit.GPIO81 = 3;  // XA9

    GpioCtrlRegs.GPCMUX2.bit.GPIO82 = 3;  // XA10

    GpioCtrlRegs.GPCMUX2.bit.GPIO83 = 3;  // XA11

    GpioCtrlRegs.GPCMUX2.bit.GPIO84 = 3;  // XA12

    GpioCtrlRegs.GPCMUX2.bit.GPIO85 = 3;  // XA13

    GpioCtrlRegs.GPCMUX2.bit.GPIO86 = 3;  // XA14

    GpioCtrlRegs.GPCMUX2.bit.GPIO87 = 3;  // XA15

    GpioCtrlRegs.GPBMUX1.bit.GPIO39 = 3;  // XA16

   

    GpioCtrlRegs.GPAMUX2.bit.GPIO31 = 3;  // XA17

    GpioCtrlRegs.GPAMUX2.bit.GPIO30 = 3;  // XA18

   

    //GpioCtrlRegs.GPAMUX2.bit.GPIO29 = 3;  // XA19

    GpioCtrlRegs.GPBMUX1.bit.GPIO34 = 3;  // XREADY

    GpioCtrlRegs.GPBMUX1.bit.GPIO35 = 3;  // XRNW 

    GpioCtrlRegs.GPBMUX1.bit.GPIO38 = 3;  // XWE0

   

    //GpioCtrlRegs.GPBMUX1.bit.GPIO36 = 3;  // XZCS0

    GpioCtrlRegs.GPBMUX1.bit.GPIO37 = 3;  // XZCS7 

         GpioCtrlRegs.GPAMUX2.bit.GPIO28 = 3;  // XZCS6

    GPIO_2_ON;

    EDIS;

}

Thanks a lot.

Br, Jordan

  • Jordan,

    I think the customer will need to perform some more experiments to reduce the number of variables at play. I also do not have enough information to understand how I2C is affecting XINTF.

    Can you clarify if the corrupt data bit 3 is GPIO76_XD3 or GPIO77_XD2 or other? Is QSEL=3 (Asynch) for the XINTF pins?

    Is there any pattern to the failure? For example, is it usually reading 0 when it should be 1 or vice versa? Do you know if this is a read or write failure? For example, if the wrong data is read back, will repeated reads report the same value?

    Are the I2C signals routed near data bit 3 on the PCB?

    -Tommy
  • Tommy,

    Besides bit 3, other bits also met the same issue, like bit 1 and bit 15.

       GpioCtrlRegs.GPCMUX1.bit.GPIO76 = 3;  // XD3

       GpioCtrlRegs.GPCMUX1.bit.GPIO64 = 3;  // XD15

       GpioCtrlRegs.GPCMUX1.bit.GPIO78 = 3;  // XD1

    GPIO qualification config as below. GPIO33 as I2C is configured as asyn. Others XINTF GPIOs are synchronized to SYSCLKOUT.

    The issue is totally about reading. It is correct at the first beginning. But after several times readying, one bit is changed from 1 to o. Then XINTF write back the right value 1, and read several times with the correct value 1. And then it fails again with reading a wrong value 0. 

    Thanks a lot.

    Br, Jordan

  • Did you face some similar issues before?
    Currently, we are not sure if it comes from F28335 or FPGA.
    Br, Jordan
  • Jordan,

    All known XINTF issues are documented in the Errata.

    Try configuring the qualification of XINTF pins to be Asynch in the GPIO QSEL registers.

    -Tommy

  • Jordan,

    Is this still an open issue?

    -Tommy

  • Tommy,
    We are still working on it. Currently we found some issues from FPGA. We are not sure if it is exactly its failure.
    Can we wait for few weeks to close it?
    Br, Jordan
  • Jordan,

    If it will take more than a week, we are being asked to mark the thread as closed internally.  You can initiate a new post or create a related thread when there are updates to discuss.

    -Tommy