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.

TMS570LC4357: TMS570LC4357 I2C2 and SPI5

Part Number: TMS570LC4357

Hi all,

on a TMS570LC4357 I use I2C2 in conjunction with SPI5. Either module works fine by itself. If I initialize IC2C, SPI5 stops clocking (verified with a scope). I narrowed it down to the pull-up resistor on I2C2's SDA line. As soon I enable a pullup on that line, SPI5 won't clock anymore. I turned off the internal pullup and added an external pullup resistor, which resulted in the same behavior. Has anyone seen this behavior before? I am using my own board, can't verify that on the HDK yet. I'll try to get hold of a HDK. In the meantime, I'd be happy if someone could verify whether nor not this behavior is a problem exclusive to the HW I use.

Best Regards 

Juergen

Pin Usage/Multiplexing

I2C_SCL:          G16

I2C_SDA:         G17

SPI5_CLK:       H19

SPI5_SOMI0:   J18   

SPI5_SIMO0:   J19

SPI5_CS0:       E19  

SPI5_CS2:       W6

SPI5_CS3:       T12

  • Hello,

    Can you check if any short between G17 and H19? 

    BTW, the external pull-up for I2C signals are required.

  • Hi QJ, 

    thanks for answering so fast. A short between G17/H19 is what I thought of right away, but there is none.

    Thanks for mentioning the pullup. resistors, will add them in the next revision. Good think I forgot them, that's how I found out that they cause a problem.

    Best Regards,

    Juergen

  • Hello Juergen,

    You said that the pull-up (internal or external) causes this problem. What happens if you configure pin G16 and pin G17 as SPI signals (SPI5SOMI[3]/SPI5SIMO[3])? 

    You can also use those two pins as GIO signals by setting the 27th bit and 19th bit, and enable the pull-up using SPIPC7~SPIPC8 registers.

  • Hello QJ,

    that's an interesting idea, haven't thought of that yet. And surprisingly that does not cause the same problem. 

    Best Regards,

    Juergen

  • Hello Juergen,

    Be aware of that both SIMO[0] and SOMI[0] should be configured as SPI functional pins even though the SOMI[0] pin is not used, otherwise, no SPI clock is generated.

  • Hello QJ,

    your idea, using SIMO[3] as GIO and then enabling the pullp for it somewhat solves my problem. I couldn't explain before why that would work and I still don't have a full understanding of the issue. 

    Anyway, if I configure SIMO[3] as GIO, everything works just fine. If it's controlled by SPI I run into the trouble, it doesn't clock if, and only if, G17 is controlled by I2C2 and the pullup there is set. 

    On the scope I also see that for the very first transfer it shifts out 16 Bits (instead of 32) before it goes quiet forever.

    As of right now I have no clue how all of this is connected. It works, but it doesn't feel good this way, 

    Best Regards,

    Juegen

  • hello,

    It doesn't make sense to me. I will do a test later.

  • Hi QJ,

    I tried it on the HDK, got the same result. I stepped into spiTransmitData() and found out that after the first transfer the BITERRFLG in the flag register ist set. If I set SIMO3 to GIO, the bit won't be set and SPI keeps operationg as expected. 

    Best Regards,
    Juergen

  • Hello,

    The MibSPI does support parallel mode to increase the throughput. If the parallel mode is not enabled, only SIMO[0] and SOMI[0] are used. Other SIMO[x] don't affect the transmission and will not generate BITERR.