Using SSP 1.2.1 on an S5D9 part. I've got multiple threads working over an I2C bus that has several parts on it but I'm having an interesting problem with the driver not working as I expect it to.
I'm looking for possible parts on the bus so I look for an old part at address 0x28 and if I don't find it I look for a new part at 0x18. Open one instance of the I2C and do a read of the old part which NAKs correctly since it's not there.
Close that instance and open another instance of the driver which has the new part configuration (everything is the same but for the address). That part wants to do a read after write (with a restart) so 20mS or so after I close the first instance, I open this instance I do a write ala:
buf[0] = 0xAA; buf[1] = buf[2] = 0x00;
RetVal = g_sf_i2c_device0.p_api->write(g_sf_i2c_device0.p_ctrl, buf, 3, true, 2);
Which goes through most of the motions on the bus but comes back with SSP_ERR_TRANSFER_ABORTED and leaves the bus hung
The bus will stay low like that till a person resets the part. Note that I'm seeing the ACKs from the part all the way along with this AND it's doing the restart correctly. Note also the incorrect data involved here, the bus should be writing 0XAA 00 00 but it does something odd with the zeros here.
If I don't look for the old part first (getting the NAK), this code runs fine (with the correct data even!). No problems.
Anyone got some patches for this?
Hi rjl,
Could this be related to this thread https://community.renesas.com/embedded-system-platform/synergy/f/forum/17323/i2c-ssp_err_assertion-after-ssp_err_transfer_aborted and this other thread https://community.renesas.com/embedded-system-platform/synergy/f/forum/16286/riic-sclk-rate-is-screwy that you've posted 2 years ago?
JBIf this response, or one provided by another user, answers your question, please verify the answer. Thank you!Renesas Engineering Community Moderatorhttps://community.renesas.com/https://academy.renesas.com/https://en-support.renesas.com/knowledgeBase/
I backported what diffs I could find between the referenced file and a stock 1.7.5 driver to my 1.2.1 driver and it doesn't fix the NAK problem. That implies that I'm going to have to selectively backport some other 1.7.5 changes to this driver as well and I have not done that just yet.
There are structural changes to the .h files between 1.21 and 1.7.5 so I'll have to carefully do the port there... I might have to just bite the bullet and upgrade the project to 1.7.5 but I was hoping I didn't have to take the [probably considerable] time to do that...
I'll see if I can go after that nut later this week and report back what I find...
I gave up on backporting this and converted the project to SDK 1.7.5 (I have another project that works fine on that version) with the pointed to r_iic.c patches. It now has a different problem that I'll open anew case about.