Currently i am trying to Control a PMIC using the S32K148 MCU via I2C , the Communication works fine when using the normal LPI2C_DRV_MasterSendData API , but when I use the transmit with Blocking API LPI2C_DRV_MasterSendDataBlocking , the controller goes into an never ending loop and there is no communication.
I understand that the providing the blocking value as 1 would provide a window period of 1ms for the transmission ,
is there any time constraint on the slave for the acknowledment too.
If not then what could be the reason for the same.
Also when I suspend the debug , the it points to the default ISR and the VECTACTIVE byte in the ICSR shows the value active exception number as 3.
dose this mean I need to configure any interrupt handler.
Could you put a breakpoint in LPI2C_DRV_MasterIRQHandler function and see if it reach it? Then step by step to see were exactly programs enters DefaultISR.
yeah , it reaches the LPI2C_DRV_MasterIRQHandler functionj , the program reaches the osifError = OSIF_SemaWait(&(master->idleSemaphore), timeout);
I understand that it is a problem with the release of the semaphore , have integrated the free Rtos in the current project , so could you please let know what are the main changes to be taken care when using the free RTOS.
From you don't have to change anything in LPI2C driver to use it with FreeRTOS.
Please tale a look over this post: https://community.nxp.com/thread/497317. Do you initialize and use LPI2C driver in tasks?
If this doesn't solve your issue can you send us a project where this behavior is reproducing?
Please call LPI2C_DRV_MasterGetTransferStatus after the blocking transfer and let me know what is the status returned by this function. Based on your logic analyzer capture I suppose the timeout is too small and timeout event occurs.
Did you tried to increase the timeout?
yeah we have the timeout error return value is 3 ,
yeah i increase the timeout and tried with the max 0xffffffff value, but i still have the same issue.
could you please let know how can we decide upon the timeout value that needs tobe set.
thanks and best regards!!!
It seems that the SCL remains low at the end for both cases. The only difference is that you are sending just one byte
The SCL might be held low by the slave. To check this, you could try disconnect the slave and then look at the SCL signal(if the signal is still low then the problems are caused by the master).
Do you observe any difference if you use generate stop at the end instead of repeated start: LPI2C_DRV_MasterSendDataBlocking(INST_LPI2C1,buffer,TRANSFER_SIZE,true,0xFFFF)?
There is no change with the usage of generate stop , I had one observation , the clock is released (HIGH) once I suspend or stop the debug .
When the program is suspended the PC points to the Default ISR as can be seen in the snapshot.
Also while configuring the I2C I had selected the transfer type as Interrupts. Am I missing something.
Do I need to have some kind of interrupt handler for the same.
Have you tried using the lpi2c_master_s32k148 example?
I don't know what might cause entering the DefaultISR, maybe a bad configuration of SCL or SDA pins. Are you using the internal pull-ups? If yes, I recommend to disable the internal pull-ups and use external resistors (~4.7KOhm each, one for SCL and one for SDA).
I observed that master callback != NULL. Could show me how the master callback handle the events or provide me the
project that you are using for master side?
We currently make use of the external pull up resistor , the callback function extern void lpi2c1_MasterCallback1(uint8_t instance,lpi2c_master_event_t masterEvent,void *userData); is defined as dummy NULL function.