upgrade mqx 4.0 to mqx 4.1, i2c interrupt driver

[Cdn_aye]

We are using the i2c non-polled driver from AN4652 in MQX 4.0.1 and it works without problem for the k20dx256. Before using this driver we had a lot of problems with missed data and the system hanging in the driver with the polled driver system.

We have to move to MQX 4.1.1, can anyone tell me please if the non-polled driver in version 4.1.1 is actually non-polled and is there any potential for hanging? The reason I ask this is the non-polled driver in 4.0.1 actually had a polled component and we don't want to go through the grief with this version of MQX that we experienced in the past. It was very time consuming.

Or should we just add the appnote working driver code from 4.0.1 to 4.1.1 and not use the interrupt driven i2c included drivers.

Can anyone share any possible problems to look for in the upgrade.

Thanks for any help.

Robert

[gfinlay56]

Hi Robert,

Like you, we have been using Guo Jia's i2c non-polled driver from AN4652 (with the updated patch to the  i2c_int_k_fb.c module). We still have problems with timeouts on _fb_tx_master and _fb_rx_master although it doesn't seem to hang on while loops any more..

One thing we have noticed is that when building with the IAR Embedded Workbench EWARM compiler, if optimization is turned on then the driver does not seem to work well, but when optimization is turned off, it seems to behave.  Is it possible that there are some missing declarations of volatile for certain items, where the compiler might attempt to use a stale value from a register or move what it believes to be a loop invariant outside of a loop?

I would also like to hear from anyone who has feedback on migrating from the i2c driver in appnote AN4652 back to the standard interrupt-driven MQX i2c master driver supplied with MQX 4.1.1.  Any comments on robustness of the new i2c driver relative to the AN4652 driver?

[Cdn_aye]

Hi Gordon

I have recently seen my IAR code miss flags in register status values, for example     if(FTM0_C0SC & FTM_CnSC_CHF_MASK){    .

So I put a static global variable and read the register then did the mask check on the value and the test worked. But then reducing the code and then putting back the test above and it worked correctly. So I don't know what was going on. I had no optimization on.

I worked with a support person from IAR related to the MQX 4.1.1 and an IAR 7.4 build. What he told me was that IAR did not recommend using "no optimization" but always to have the lowest form of optimization if we were just debugging. I do not know the absolute certainty of this statement and was not given any convincing underlying reasons. That said I have never built a system with the optimization at full and tested it. It would be some work but if you have a random unresolved problem with execution, I would suggest building your project with a trial version of CW and see if the gcc compiler yields the same result. It is not that difficult other than entering a legion of paths for the mqx libraries and being familiar with Eclipse.

I looked at going to the new i2c driver and decided to wait. The current driver never hangs and did not I see not real benefit in taking the risk. The latest driver was developed after a lot of problems that were reported with the IRQ based driver that was doing polled access's. That alone makes the whole thing suspect in my mind. We spent excessive time tracking down the problem and then trying to find a work around with that driver.

I built the code to work with MQX 4.1.1 but could not get the serial driver to work on a UART port. I changed all the pin assignments but then had to leave the project for a later time. So I will pick it up in the near future.

[soledad]

Hello Rober,

The I2C driver has modifications between 4.0.1 and 4.1.1 MXQ versions.

According the MQX 4.1.1 release notes:

Both interrupt driven I2C master and slave mode drivers are changed to support synchronous blocking mode and share

the same API with the polling driver variant. This way users can interchange the polling and interrupt I2C driver easily

in their final application.

You can find the below example codes at the path C:\Freescale\Freescale_MQX_4_1\mqx\examples

• i2c: Shows how to read/write data from/to external EEPROM. Additional HW setup is needed.
• i2c_slave: Shows usage of the I2C driver in slave mode – emulates the external EEPROM behavior.

    The current version of the MQX I/O driver supports two I2C IP modules. The legacy module requires an additional configuration. To confirm which IP you are using, see the figure in the MQX Release Overview section.

• i2s_demo: Demonstrates use of audio I2S driver. TWR-AUDIO card is needed to run this example.

Have a great day,
Sol

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------