Based on information from Chris and the Particle team provided about Argon and Boron have different I2C setups on the feather boards. All nRF52840 MCU Gen 3 devices have 13K ohm pull up resistors on. SDA nd SCL.
The solution to getting data at all was removing the two 2.1K ohm resistors on the ADM00686 (MCP39f521) development kit. For Argon I used the 13K ohm internal pull-ups plus external 2.4K ohm resistors to achieve a 2.0K ohm equivalent pull up on the I2C bus.
For Boron, I just used the 13K pullups in the nRF52840 and the 4.7K already on the board because the Boron has a few I2C devices on it already.
This didn’t fix my issues completely, now I can get data that is accurate to my test instrumentation but the I2C bus still drops out from time to time, about every 8 to 24 seconds. I’m looking into these issues in more detail.
We tried to migrate our platform from 1.5.2(Boron) where I2C was working correctly to 2.0.1 and are now seeing the Wire.endTransmission returning “2: START bit generation timeout” when communicating to a FRAM chip.
I was unable to solve the i2c Issues with the Boron, works great on Argon. I believe the issues hardware related because the boron uses a battery IC over I2C already and those traces might not be stable enough.
My solution was to change from i2C to UART with the ICE I’m using, lucky there are many COM options. I ended up using an nRD5840 Dev board with the i2C library and it works perfectly with the MCP32F521 dev kit.
The Bron’s problem is not consistent so it’s hard to track down because it works with other i2C devices. If particles had the ability to increase the width of those traces that might help with possible impedance issues with different i2C frontends and connections. I haven’t looked at the board layout file, but the i2C traces might pass too close to a noisy trace and be getting an unwanted interface. My scope didn’t pick up anything like that but it’s also a cheap scope.
I just came across this thread! I’m the author of the original UpbeatLabs_MCP39F521 library (available for Arduino and Python), and great to see it being ported to Particle!
Hope all the kinks have been worked out! Fascinating thread!
A couple of thoughts come to my mind about some issues I faced. I also did a version of this library for the CC3200 on TI-RTOS, and had to slow it down to 100 kbits/s for consistent data read, IIRC. The MCP39F521 can do i2c timeouts and clock stretching, and many MCUs cannot deal with that, and so reducing the clock speed helped. That, and I had to make sure about the quality of the wires and the strength of the pull-up resistors.
The MCP395321 is a great little chip. Your Watson monitor is a nice little project! If you ever want to connect I see you’re in Mountain View on Tindie, I’m in redwood city.
Why, we’re practically neighbors! Would love to meet up and exchange notes once the pandemic situation is under control with vaccinations, etc - hopefully soon!
