I2C_DRV_MasterInit() getting stuck at OSA_SemaCreate(&master->irqSync, 0) within the function

[wildhorsemusic]

Hello, sorry to trouble you for something that will probably be a NOOB issue.  I am running MQX 4.2, KSDK 1.2, KDS 3.0 and have created a test MQX app using Processor Expert to create a couple GPIO drivers, a couple tasks and an I2C driver on I2C1.  Just to begin to get some experience with working with the I2C driver I made a call to I2C_DRV_MasterInit() in the fsl_i2c_master_driver.c and it seems to go into an endless loop at:

Line #103, OSA_SemaCreate(&master->irqSync, 0);

I've tried it with enabled I2C interrupts and without but the result is the same.

Everything is autogenerated except the call to I2C_DRV_MasterInit() and a couple variables.  I was able to get the GPIO and task stuff to work, but not the I2C.  By the way, I'm calling the I2C_DRV_MasterInit() from the main() function in the main.c file that is autogenerated.   I've tried to keep things real basic to make it easier to troubleshoot.

By the way, are there going to be in tutorials for this stuff based upon the latest MQX 4.2, KSDK 1.2, KDS 3.0?  It's confusing because the newer versions appear to do a lot of the low-level setups while there's no examples that match my configuration.

Thank you!

Duane

[wildhorsemusic]

FYI,

One thing that was giving me fits is that when using Processor Expert, you must pay attention to the ORDER of your components.  I had created one task, an I2C component and a GPIO component (in that order).  This order is how they are initialized in the CPU.c file created by PEX. In my project I was having issues with the application locking up and not firing the ISR.  This was because the task was started BEFORE the I2C was initialized.  Once I realized the issue, I dragged the components into their proper order and everything worked!

Duane

[danielchen]

Hi Duane:

Which board you are using, frdmK64f or other?

Regards

Daniel

[wildhorsemusic]

Hey Daniel,

Thank you for your reply.  Yes, it is the FRDM-K64F board, with the EVBCRTOUCH board.  I discovered that I needed to move my code out of main.c.  I then tried to put a I2C_DRV_MasterReceiveData() function in the ISR, but it doesn't present the proper I2C Slave Address for some reason.  So, When I put the I2C_DRV_MasterReceiveData() function in a task, I can now see the proper addressing on my logic probe. However, the problem is that the CRTOUCH won't clear the IRQ pin until I read the CRTOUCH registers. But, because the ISR has a preemptive priority, the task never gets called because the IRQ pin is forcing the ISR to continuously fire.

I have studied the CRTOUCH Datasheet, but it is pretty light on it's description of the I2C read flows.  I know it's a timing issue, but I haven't been able to find an example of the EVBCRTOUCH board and FRDM-K64F.

I really appreciate your time and insights!

Duane

[danielchen]

Hi Duane:

It is not good to put the I2C_DRV_MasterReceiveData function in the ISR, putting it in a task is right.

Yes there is a timing issue between the two boards, unfortunately we don't have an example of the EVBCRTOUCH board and FRDM-K64F.

I have an idea, but I don't know whether it work or not. You can disable the CRTOUCH interrupt in the ISR.  then the receive task should run.

And in the receive task, enable the interrupt again.

You can try it. Hope you have good luck

Regards

Daniel

[wildhorsemusic]

Hi Daniel,

We must have been thinking the same thing! 1st thing to know is that the CRTOUCH interrupt pin can only be cleared by reading the status registers in the CRTOUCH and I also by reading the data register (I think).  BOTH of these require a read operation... which won't run within the ISR.

I tried disabling the pin interrupts for PORTC so at least the MCU would not respond to the CRTOUCH after getting the initial IRQ:

ISR CODE:

PORT_HAL_ClearPortIntFlag(PORTC_BASE_PTR);

PORT_HAL_SetPinIntMode(PORTC_BASE_PTR,PADEVT,kPortIntDisabled);

_lwevent_set(&portcevents,0x01);

It's surprising to see this problem, when it is common to have to read a register on the slave device in order to clear the interrupt.

Also, it's surprising that no example exists for a Freescale M4 processor and CRTOUCH combination.  It doesn't appear that the CRTOUCH is that popular or isn't used in this configuration very often?

I chose the Freescale K64F, KDS, MQX platform because it appeared that Freescale was very engaged with creating solutions for easy 'on-ramp' of their products.  Instead, I'm spending days and hours working on basic interface issues instead of my application.

Sorry to dump on you Daniel, I guess I just need another cup of whiskey... I mean coffee.

Please let me know if find a solution.

Thanks

[danielchen · Accepted solution]

Hi Duane:

We can configure the interrupt pin  as level trigger or edge trigger.  Please see  Regitster PORTx_PCRn, 19-16.    Could you try to configure the interrupt pin to edge trigger?  Please check the reference manual for more details.

Regards

Daniel

[wildhorsemusic]

Daniel,

Thank you for your response.  I was able to get out of the ISR by setting the value to "Falling Edge".  Thank you.  Now the code will hang after cycling through the task a couple of times.  I have determined that it's hanging in the driver.  The driver waits for confirmation of send/receive of data. Somehow, it gets stuck there.  Any thoughts on why this is happening?  The driver seems have all of the proper "waits' in place, so the processor should not be able to run ahead of the slower I2C bus.

I've attached my test project for your review... but, I'm trying to keep things real simple until I can get it all working.

I am hoping to move on to an eDMA test once I understand the nuances of getting the FRDM-K64F and CRTouch working together.  It's really basic stuff, I know, but I'm having challenges in getting success.

Thank you!

[wildhorsemusic]

Daniel,

By the way, I removed all the code from my MQX task except the line containing:

pstatus = I2C_ReadRegister(PADADD,PADSTR); //Clear CRTouch Interrupt Pin.

When I do, the task runs clean, without any lockups.  I can touch the screen and the ISR is called and the task clears the CRTouch interrupt and the cycle repeats.

Duane