• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 566 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Enabling I2C1 causing prob with ADC/DMA/SPI

Robbie Valentine
Expert 2975 points

Hello,

I'm stuck on an issue involving the I2C controller or at least I think thats the culprit.  I have a decently complex embedded system using the TM4C123GE6PMI DMA'ing data out of two SPI ports into memory which I then download to a computer to view/check the integrity of.  Initially it looks like this is working great.  I can run this for millions of cycles downloading >10MB of data and everything checks out ok.  I verify this by pushing a counter to memory instead of ADC values.

The problem I 'm having is I need to add a I2C link to send out some control bytes to something else.  When I add this instruction:

SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C1);

Just enabling I2C1 causes immediate data integrity problems where I'm dropping substantial numbers of bytes.  I'm DMA'ing buffers out of two separate SPI ports to memeory when the buffers fill up from the ADC.  This works really well until I enable the I2C1 peripheral.  I am 100% confident that PA6 and PA7 are unused as well as I've planned on dedicating them to I2C.  I've tested this on a Tiva launchpad with these instructions to configure it as a master:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C1);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    GPIOPinTypeI2C(GPIO_PORTA_BASE, GPIO_PIN_7);
    GPIOPinTypeI2CSCL(GPIO_PORTA_BASE, GPIO_PIN_6);
    GPIOPinConfigure(GPIO_PA6_I2C1SCL);
    GPIOPinConfigure(GPIO_PA7_I2C1SDA);



    I2CMasterInitExpClk(I2C1_BASE, SysCtlClockGet(), false);

and I can communicate fine to my target chips.  Applying this to my other project I intended to use this code on seems to screw it up.  Even just the 

SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C1);

Being compiled in the project causes this problem.  I'm really stuck right now so I wanted to throw this up to see if anyone had any ideas regarding the problem or troubleshooting it. 

Effectively I configure the system and then kick off the sampling, pushing the bufferst memory via dma as fast as I can (the timing here is very tight), but I don't know how configuring a peripheral could affect the performance of these other peripherals.

  • 0
    Guru 47900 points

    Robbie Valentine said:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C1);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);

    Either I missed - or you don't detail the "where" of those 2 SPI ports.  I know that one may exist upon Port A - and your call to, "SysCtlPeripheralEnable() (Port A)" may prove disruptive as (one assumes) Port A had previously been enabled. 

    Like you - if (really) nothing else impinges upon PA6, PA7 - something's up.  I'd bet on the (duplicate) Port A enable...

  • 0 in reply to cb1
    Expert 2975 points

    Hey cb1, I should have putsome more detail. I thought the same thing about port a gpioa enable call and removed it so I'm not enabling it twice. This still doesn't help eliminate my problem.

    As for the SPI ports...I"m using SPI0 and SPI1.  There is an errata that was affecting their performance because they don't play nice together with the DMA unfortunately, but I implemented a work around by enabling/disabling as recommended in the errata and they work fine now.  I wasn't sure if there was something going on with the I2C involving an errata issue, but I haven't found anything so it looks like I2C is clean.


    The only SPI port close to the I2C controller is the one on PortA, but it uses pins 2,4,5 so I should be good to go assigning 6 and 7 to I2C.

  • 0 in reply to Robbie Valentine
    Guru 117850 points

    Remains unclear the, "Where, when" you enable that I2C instantiation.

    Have you tried placing that I2C enable "prior" to the other Port A peripheral set-ups?  Results? 

    Better still - try to enable only that I2C - w/out other code bits intruding.  Are proper (external) pull-ups present upon each I2C pin.  (plz don't tell me manual says internal are fine - same team said 129xx would be plentiful - months earlier)

    Have you tried - at least temporarily - to enable another I2C unit?  Results? 

    A long shot - but maybe your stack is "close to bursting" and the call to I2C pushes it too far.  Double and report...

  • 0 in reply to cb1_mobile
    Expert 2975 points

    Hey CB1,

    Yea I've put the enable call for I2C1 pretty much everywhere including before and after the port A enable call.  Still no luck.  I've tried to slim down my code set to eliminate unneeded code, but the SPI ports (0,1) are required to produce this problem (along with DMA etc...) and this doesn't seem to help.

    I have 4.7k external resistors as pullups.  I have also verified, with a multimeter, they are pulling the pins up to Vcc (3.30V).

    Now, I've tried to enable I2C2 and that didn't seem to screw up any of my data.  The port used for I2C2 is Port E pins 4,5.    Unfortunately for me the only pins I have open in this design are A6 and A7 for I2C1. 

    As for the stack bursting, I"m not sure how to check that with the debugger, but I am configuring I2C1 when I configure all my other stuff.  It seems that all of the other configuration calls don't cause any stack problems.

    I'm just testing any idea I come up with now to try to get more clues.  I'll report back after gathering some more info.

    Thanks!

  • 0 in reply to Robbie Valentine
    Guru 117850 points

    Not to make you too krazy - but does I2C1 actually perform when attached to an external slave and your program is reduced?  "Still no luck" reflects your frustration/disappointment - but conveys little hard fact.

    I continue to believe you'll "raise your odds" by initializing I2C1 prior to the other Port_A peripherals.  Also - just after I2C1's init. - suggest that you reset the I2C1 peripheral.  (just in case)

    You should be able to increase your stack size via a simple IDE command.  (that's how IAR works)  Cannot hurt - when your ship's going down - good sailors try everything...