SDK I2C fails using DMA with KL27

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SDK I2C fails using DMA with KL27

773 Views
bcstewart
Contributor III

Processor:  MKL27z256

SDK 2.2

uVision IDE

I have three interrupts defined.  One for DMA, one for PIT, and one for I2C.

The I2C uses the master operation in transactional mode.  It uses the I2C_MasterTransferCreateHandle to install the interrupt and uses I2C_MasterTransferNonBlocking to access data.

Both the PIT and DMA use the CMSIS interrupts, i.e. default interrupt names (like in the examples).

The DMA is triggered by a TPM and runs continuously feeding data to a DAC.  It works perfectly.

The PIT works perfectly.

The I2C work perfectly by itself, or with PIT interrupts engaged.  Even adding a long delay in the PIT routine still allows the the I2C to function.

However, once I engage the TPM to drive the DMA, I2C fails to read the data on the I2C bus correctly.  It has very sporadic behavior as seen with a logic analyzer.

The DMA handler only uses 12% of the CPU resources, so there is plenty of time for the PIT and I2C to function.  DMA has the the highest interrupt level 0.  The PIT has level 1, and the I2C has level2, the lowest.

The only thing I can think is that the I2C uses the transactional method where it must travel through more software layers.  Or something in the DMA is causing problems.

I've had no problems like this use PE Device Init on both a K22 and a KL25.

What is wrong with the SDK?  Any ideas?

Tags (3)
0 Kudos
1 Reply

607 Views
bcstewart
Contributor III

I changed the I2C routine to functional mode (blocking).  Now I have it working--kind of.

The main problem is due to the I2C device I chose--it's a touch sensor made by another semiconductor company.  It does not have a proper I2C function--you must monitor a RDY flag that informs you when it's OK to access it.  It also fails if you get an interrupt during I2C activity so it's not fully synchronous. 

The work-around is to set semaphores to inform the blocking task when the DMA and the PIT interrupts are idle.  This is far from optimum and will change to a different touch sensor vendor.  Too bad you guys discontinued the MPR121--it worked perfectly.

I would mark this as "solved" but I can't find the button that let's me do this.

0 Kudos