• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 283 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.

MSP430FR5964: Software overload causing I2C hardware delays?

Richard Kovacs
Prodigy 20 points
Part Number: MSP430FR5964


Tool/software:

Dear all,

I am working on a project where we use most of the available USCI modules, some for UART, 1 SPI and 3 I2C. The I2C modules are the last ones in ISR priority (UCB1-3). On UCB3 we sometimes get unwanted STOP condition interrupts, and this ruins the whole communication. The code basically works fine for a (random) while and then gives this stop condition interrupt (which is not initiated from software) and that messes up the whole communication. This situation seems to be coming from timing issues (e.g. timing between the SCL and SDA is sometimes too marginal and makes a fals STP).

My question is: Is it possible that the hardware USCI module (in this case UCB3) has some lagging or delays (during e.g. transmitting the address and the byte I want to send) because the software overloads the processor, or is this only possbile if e.g.an interrupt is fired but not serviced in time? 

Thanks,

Richard

  • 0
    Guru 100705 points

    As far as I know, the eUSCI-s operate independently of the CPU, and of each other. I2C mode provides some flow-control (via clock-stretching). In those cases, CPU intervention is required, but generally things proceed on their own.

    I'm not sure what you mean by an "unwanted" Stop interrupt. If you don't enable the Stop interrupt in the IE register, it won't be presented in the IV register. (It will still be presented in the IFG register.)

    There is a race in Master-Receiver mode, since the STPIFG is higher priority (in the IV register) than the RXIFG. If the RXIFG for the final byte isn't serviced before the Stop completes, the STPIFG will be presented first. The time span is a single SCL cycle, so this is fairly likely, particularly if your CPU is busy. If you think this is happening you might consider (a) not using the STPIFG at all (b) checking the IFG bits directly [imposing your own priority scheme] (c) using DMA.

**Attention** This is a public forum