7 years, 1 month ago.

K64F I2CSlave does not receive, hangs in slave.read()

Please see edit below.

So this question was solved by a library change a long time ago (https://developer.mbed.org/forum/bugs-suggestions/topic/5220/). I tried posting on that topic, but apparently it didn't gather much attention. Here's the issue that I'm seeing, so you don't have to wander off to read it on the old topic:

I'm essentially using the I2CSlave example code from the mbed OS reference (https://docs.mbed.com/docs/mbed-os-api-reference/en/latest/APIs/interfaces/digital/I2CSlave/), but I'm using a K64F with the slave on I2C1 (PTC11 and PTC10).

On an oscilloscope, I can see the address ACK, I can see the master ACK when the slave writes, but the slave will not ACK when written to by the master, e.g. during slave.read(&buf[0], 1). I flip the blue LED when in the I2CSlave::WriteAddressed case of the switch, and the LED changes, then the code hangs on the read statement. I know it hangs because I try flipping the LED back directly after the read, but it stays on.

I tried my code on an LPC1768 (after changing the pin numbers) and it works fine....

This smacks of a library problem for the K64F. It was repaired in 2014, so the only thing I can figure is that it got broken again during the upgrade to mbed 5.0.

Can anyone verify this for me? Thanks in advance for any help.

Regards,

- Just Gary

EDIT: I don't have the time (nor do I get paid) to fix this issue. I have gotten past it with a workaround that I really hate, but it works. The solution does not include mbed at all, which is a first for me since I started using mbed almost seven years ago. I really don't mind that an officially supported library has an occasional issue, but the fact that it gets no attention at all from the support team is disturbing.

Has all of the push for new boards and CPUs finally made mbed too big for its own britches? I truly hope not, but I can't use a product that leaves no hope of getting a "supported" library fixed. I contribute to mbed when I can, but please understand that I get paid to get *my* stuff working using whatever method I can, which might include using *your* stuff. If I can quickly work around issues with your stuff, I'll use it. Otherwise, I'll move on to a solution that will work for my current requirements.

So in this specific instance, I2C Slave receive (apparently) didn't originally work correctly on a K64F, but got some attention a few years ago (around 2014) which resulted in a fix. From what I can tell, the code got completely overhauled after that, and it doesn't work any more. Since the exporter for K64F got broken also during the V5 upgrade, it's not at all convenient for me to take everything offline to try to fix it.

I don't know how the mbed team assigns issues, but this is an issue. If I'm wrong about it, that's fine with me, but can somebody please take a moment and help me confirm it? Thanks for your time.

1 Answer

7 years, 1 month ago.

You could check older versions of the mbed lib to verify that it worked in the past. Select mbed lib in your project, the window in the upper right hand shows the current lib version, you can then click on ''revisions'' to show other versions. Select the desired version, click ''change'' and recompile.

It's been a week without any other help.

I understand that basically nobody uses I2CSlave, but I am very disappointed that this is on me to fix if I want it working. If no one wants to at least check my work, I'm not interested in a fix either. Like I said before, this works on an LPC1768, so my project is proceeding, just not on the board I wanted to use at first.

posted by Just Gary 29 Mar 2017