• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 83 subscribers
  • Views 636 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28377D: I2C SDA interference with ADC EOC interrupt

Brice Plavonil
Prodigy 25 points
Part Number: TMS320F28377D
Other Parts Discussed in Thread: SYSCONFIG

Hello, 

I have EPWM peripherals (3, 4, 6 and 4) set with a common counter period to achieve 50us. Once the Counter reaches 0, the EPWM3 is configured so that ADC will be triggered to start conversion. Once conversion is finished, the end of conversion (EOC)  interrupt is triggered. This give me an interrupt every 50 us. My interrupt routine [interrupt void ADCC1_ISR(void)] would clear the INT1 flag and acknowledge the interrupt [PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;]

This worked well until I added some code to perform I2C communication with an external EEPROM.

I2C A is used with  SDAA connected on GPIO 0 and SCLA connected on GPIO 1. both are set has output, open drain, GPIO_ASYNC.

When I2C comms is initiated, on SDA set high, the interrupt routine is entered before the 50us interrupt. (which should mean an End of Conversion of the ADC has occurred.).

On the reference manual GPIO 0 and GPIO 1 are sharing muxing with EPWM1A and EPWM1B. I am not using EPWM1.

I have also disconnected the EPWM1 clock to ensure it is switch off. 

--> With the same software, wiring the I2C A on GPIO32 and GPIO 33 it works well. There is no interference with the interrupt ! 

Is there anything I am missing with I2C A on GPIO 0 and 1? Haven't found anything relevant in the errata either

here below some trace on a picoscope. 

in purple the interrupt pulses 50us before the I2C is transferring (reading) data 

red is the I2C clock

blue is the I2C SDA

as soon as the SDA is high the interrupt handler will be called (an interrupt happens)  

a bigger view

  • 0
    TI__Mastermind 30185 points

    Hello Brice,

    Can you show me the code you're using to configure the GPIO0/1 pins for I2C? Specifically the GPAGMUX1 and GPAMUX1 configurations. It would also be helpful to see the code you use to configure the ePWM, ADC, and the interrupts between the two.

    Best regards,

    Omer Amir

  • 0 in reply to Omer Amir
    Prodigy 25 points

    Hi Omer, is there a way for me to share the code privately ? 

  • 0 in reply to Brice Plavonil
    TI__Mastermind 30185 points

    Yes, I have accepted your friend request.

  • 0 in reply to Omer Amir
    Prodigy 25 points

    I have checked all my registers and I saw that the register XBARFLG2.EXTSYNCOUT is set (=1) with 

    XBARFLG2.INPUT1 ... to ... XBARFLG2.INPUT6 are set too. 

    I have seen that INPUT5 is connected to ADC SOC. Setting INPUT5 to GPIO1 instead results in no unintended interrupt being triggered.

    Since I am not setting the external Sync voluntarily, I find out that in the EPWM setting I had enabled the PHSEN in the TBCTL register. 

    0: Do not load the time-base counter (TBCTR) from the time-base
    phase register (TBPHS).
    1: Allow Counter to be loaded from the Phase register (TBPHS) and
    shadow to active load events when an EPWMxSYNCI input signal
    occurs or a software-forced sync signal, see bit 6.

    Disabling this bit would stop the untended interrupt. 

    Do you know if there is anything that I have missed since I might need the shadow register feature. 

    I am not sure why the EXTSYNOUT is set in the first place though.

  • 0 in reply to Brice Plavonil
    TI__Mastermind 27636 points

    Hi Brice, 

    Are you using SysConfig when developing your code? By default the EXTSYNCOUT from PWM module are disabled. How are you syncrhonizing your PWM modules? They have all the same period correct? Do you have any other possible ISR that could be triggering the ADC?

    Without I2C module added, you get your expected ISR EOC occuring normally correct? But once you add the I2C module, multiple EOC interrupts are occurring? 

    Best,

    Ryan Ma

  • 0 in reply to Ryan Ma
    Prodigy 25 points

    Hi Ryan, 

    Without I2C module added, you get your expected ISR EOC occuring normally correct? But once you add the I2C module, multiple EOC interrupts are occurring?     --> I get an ADC start of conversion triggered, which then trigger an interrupt on EOF, ONLY when SDA is connected on GPIO0. 

    Are you using SysConfig when developing your code?  No I am not - I made an attempted really long time ago but not sure it is on the same project I am currently working on.

    By default the EXTSYNCOUT from PWM module are disabled. How are you syncrhonizing your PWM modules? They have all the same period correct?

    All 6 PWMs have the same period of 20khz. The deadband is set for inverting the EPWMxB based on the A' ones.

    ==> I had the PHSEN set to enable. keeping this enabled causes the all EPWM counters to be 0 when the GPIO0 goes high. this would trigger the ADC conversion and so an interrupt.  

    Do you have any other possible ISR that could be triggering the ADC? No- the only ISR is the ADC EOC. 

    thanks

    Brice

  • 0 in reply to Brice Plavonil
    TI__Mastermind 27636 points

    Hi Brice,

    How are you outputting the purple waveform indicating the EOC? Are you toggling a GPIO? What signal is the yellow waveform?

    Can you confirm whether you see ADCINT flag set in ADCINTFLG register? We need to confirm whether ADC EOC interrupt (this has to be checked at ADC module level instead of CPU) is actually getting triggered when I2C communication is initiated. It could likely be a wrongly fired ADCA interrupt because of interrupt nesting.

    Best,

    Ryan Ma

  • 0 in reply to Ryan Ma
    Prodigy 25 points

    Hello Ryan, 

    The purple waveform is a GPIO pin set high when the ADC ISR is entered. The ISR will execute the scheduler, then the GPIO will be set low. 

    the signal in yellow is not significant to this problem. it is just a pin set high as soon as the addressing in the I2C is performed.

    the ADCINT flag is set when the interrupt occurs. I am then clearing this interrupt in the ISR. 

    The SOC is triggered when the SDA (of the I2C) is going high on pin GPIO0. 

    As I mentioned before the reason for this unwanted interrupt I believe is that the PHSEN bit is set and it forces synchronisation based on INPUT5 of the InputXBar. When the SDA goes high it triggers the synchronisation and set the TBCTR to 0. if I select Input5 to be something differnt that GPIO0 or remove the PHSEN bit then obviously I don't have the undesired interrupt. 

    I am not sure if need the PHSEN to be set to achieve synchronisation of the 6PWM. The have the same period.and their clock are synchronised (TBCLKSYNC set to 0 before initialisation of all pwm and then set to 1) .

  • +1 in reply to Brice Plavonil
    TI__Mastermind 27636 points
    Brice Plavonil said:
    I am not sure if need the PHSEN to be set to achieve synchronisation of the 6PWM.

    If you do not need to phase shift these signals from each other then you do not need to enable PHSEN. For now you can disable the PHSEN to prevent the unwanted interrupts.

    TBCLKSYNC will ensure that the TBCTR starts at the same time.

    Best,

    Ryan Ma