Scenario: RT1064 with FreeRTOS and SDK 2.8.2
I'm facing some issues using the LPI2C peripheral with eDMA - I've used the sdk example "evkmimxrt1064_lpspi_edma_b2b_transfer_master" as reference.
The transfer is working properly, for reading and writing a slave device in the bus.
But when I try to read some data from a device address that is not present in the bus, the problems start. The transmission, of course, finishes with a NAK: Start + Slave Address + NAK + Stop.
Problems:
1) The callback is not called when some errors happen. The callback is tied to the eDMA channel completion trigger, and probably in case of errors like this, the transmission was not completed and the callback is never called. In my standpoint, the callback should be called even in case of error, because we need to handle it.
2) Ok, we can workaround this with an LPI2C IRQ in case of error. Then the most logical path would be call "LPI2C_MasterTransferAbortEDMA" to clear the transfer handlers, FIFOs, DMA TCD, etc so the device is ready for a new transfer. This function correctly clears the FIFOs but then sends a Stop command to the bus, which will be kept in the TX FIFO buffer because there are error flags set in the LPI2C peripheral. In the next transaction, when the error flags are cleared, immediately the MSR->FEF will be raised since we are trying to transmit a Stop without a Start. By the way, the AUTOSTOP bit is not set.
I can see there function "LPI2C_MasterEDMACallback" can handle some errors, the problem is that it will not be called in some errors, like this when the transfer is not completed. That would need a proper fix. And the "LPI2C_MasterTransferAbortEDMA" should check if there is any ongoing transaction before sending the stop.
Am I doing something wrong in the procedure?
Cheers.
Alex
Solved! Go to Solution.
Hi,
Thanks for your reply.
In general, I've replicated your testing result and in my opinion, it needs to combine the interrupt mechanism to handle the error conditions, otherwise, the DMA is incapable of doing this job actually.
I'll transfer this software requirement to the SDK library team in the next round of Field trials of the SDK library.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, thanks for your reporting, next, I was wondering if you share the test code, and it will be great if you can attach the wave that is captured by the logic analyzer, as I'd like to replicate the phenomenon prior to transfer the report to SDK library team.
Looking forward to your reply.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Jeremy!
Yes, I can share the code with you but not here, in public, because it is a company project. I can send it zipped to a nxp email.
But I would say you are gonna have the exactly same behavior using the sdk example I mentioned.
If you try to use the "evkmimxrt1064_lpi2c_edma_b2b_transfer_master" and send a read or write command with no slaves in the bus, the callback "lpi2c_master_callback" will never be called and the software will hang forever waiting for it.
I attached 2 pictures from logic analyzer showing one successful transfer and one that failed because the slave was not in the bus to reply.
Hi,
Thanks for your reply.
In general, I've replicated your testing result and in my opinion, it needs to combine the interrupt mechanism to handle the error conditions, otherwise, the DMA is incapable of doing this job actually.
I'll transfer this software requirement to the SDK library team in the next round of Field trials of the SDK library.
Have a great day,
TIC
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------