Repeated first byte on I2C read with Azure Sphere

Question

I've been trying to get the PN7120 based NFC click working with the Avnet Azure Sphere starter kit. It's not been easy. I should have been more wary after my road test of the similar PN7150. The weirdest problem of many was the fact that the output buffer meant that you might have 2 attempts at request A because the first one failed, make request B and get the buffered answer to one of the request A's that you made earlier. As the only documentation is sample code like this (which I've simplified significantly to illustrate the point), and the responses seem undocumented and fairly similar, it wasn't easy to debug. // Retry this until it succeeds...
NxpNci_HostTransceive(NCICoreReset, sizeof(NCICoreReset), Answer, sizeof(Answer), &AnswerSize);
if ((Answer[0] != 0x40) || (Answer[1] != 0x00))
 return NXPNCI_ERROR;

// Then try this...
NxpNci_HostTransceive(NCICoreInit, sizeof(NCICoreInit), Answer, sizeof(Answer), &AnswerSize);
if ((Answer[0] != 0x40) || (Answer[1] != 0x01) || (Answer[3] != 0x00))
 return NXPNCI_ERROR; This might be a UK thing, but it reminded me of this:

You don't have permission to edit metadata of this video.

Edit media 
 
 
 
 
 
 Dimensions 
 
 
 
 x 
 
 
 
 
 Small 
 Medium 
 Large 
 Custom 
 
 
 
 
 Subject (required) 
 
 
 Brief Description 
 
 
 Tags (separated by comma) 
 
 
 Video visibility in search results 
 
 Visible 
 Hidden 
 
 
 
 Parent content 
 
 
 Repeated first byte on I2C read with Azure Sphere 
 
 
 
 
 
 
 
 
 Poster 
 
 
 
 Upload 
 Preview 
 
 
 
 
 
 
 
 
 
 
 
 
 Ok 
 
 
 
 
 
 Cancel

Anyway, I think I've got round all the quirks of the NFC click's PN7120 - and I'll post some example code once it's tidied. The problem I have now seems to be an MT3620 one. I frequently (but not consistently) get a stray byte at the start of my response. Sometimes it's the first byte repeated. Sometimes it's 0xFF. Perhaps it could be left over from the last response. I've written code to detect and remove it, but it really shouldn't be there. I've taken a close look at my code and nothing is out of the ordinary. The error comes back from the I2CMaster_Read function in the Azure Sphere SDK. Has anyone seen this problems before or have any other ideas?

bwilless · Accepted Answer

Hi David, Sorry you're having issues getting the PN7120 click board working on the Starter Kit. From all the great details you provided, I agree that this looks like a MT3620 issue. I've never run into this issue, but since it looks like a chip level issue, I recommend that you post your question on the MSDN forum here: https://social.msdn.microsoft.com/Forums/en-US/home?forum=azuresphere This forum is monitored my Microsoft and the Azure Sphere developer community. You may find someone who's had similar issues there. Brian

Fred27 · Answer

clem57 wrote: OK on a more serious note, look at https://ez.analog.com/audio/f/q-a/3553/i2c-timing-issues-with-ssm2529 . It suggests the need for a pull up resistor. But that may cause parasitic capacitance. Read https://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/ . So this is a bit tricky. Hope this helps, Clem The SCL and SDA lines I'm using already have 4.7k pull-ups on the Azure Sphere as they're also used for the onboard LSM6DSO gyro/accelerometer. There are also 10k pull-ups on the NFC click board. The result doesn't seem to vary with bus speed. I will double-check that the signal is reasonably clean.

ralphjy · Answer

Thanks for posting. I also have an NFC Click from a previous project that I want to use with the Azure Sphere. I'm traveling a lot in September so I won't get round to it for a few weeks. I expect that I will encounter all the same issues but I'll post if I my experience is any different. I've thought about taking the various project boards with me so that I could work on the road but I decided that it's not worth testing TSA's reaction to loose PCBs in your luggage. I've already had enough unpleasant experiences with them that it isn't worth the risk. I guess I won't complain about them keeping us safe.

clem57 · Answer

OK on a more serious note, look at https://ez.analog.com/audio/f/q-a/3553/i2c-timing-issues-with-ssm2529 . It suggests the need for a pull up resistor. But that may cause parasitic capacitance. Read https://hackaday.com/2016/07/19/what-could-go-wrong-i2c-edition/ . So this is a bit tricky. Hope this helps, Clem

Fred27 · Answer

Let me know if you're starting and I haven't yet got around to posting some working sample code. I should be able to save you a bit of time.

javagoza · Answer

I have had similar problems working with the Uart with the POXIS read and write functions. I solved the problem by doing the readings and writings in separate threads and adding nano sleeps in the threads to let the uart data be read or written.

Maybe this is not yout problem as I2C Azure Sphere operations are all blocking, synchronous operations. In the UART only asynchronous operations are supported by now.

Perhaps you can increment the timeout ( I2CMaster_SetTimeout) or make a delay before reading.

Repeated first byte on I2C read with Azure Sphere

Top Replies