Notecarrier F v1.0 versus v1.3

Hardware
1

Last March I posted about some I2C issues which were resolved by adding a mux. Fast forward to now where I’m building essentially the same prototype but again started encountering very similar issues. The Notecard reports an error “i2c: unknown error on TwoWire::endTransmission() {io}" and my sensors will stop sending data / become unresponsive.

I’m stacking an Adalogger between the Swan and Notecarrier, and I suspected it was causing the problem, and indeed when removed, the symptoms disappear. I de-soldered the I2C pull-up resistors from the Adalogger but the symptoms persisted.

I then realized the main difference between prototypes is that the Notecarrier F versions are different. I originally used Notecarrier F v1.0. This latest build uses Notecarrier F v1.3. And if I simply swap out the Notecarrier v1.3 (keeping the Adalogger in place) and replace it with v1.0 – the symptoms disappear!

So two questions:

  1. Where could I find a change log or summary of differences between the two Notecarrier versions? I did look in the Blues developers portal and on Github, but haven’t found it yet.
  2. Does it sound plausible that the Notecarrier F updates would cause a change in the behavior of the I2C bus, and if so, what sort of change could cause that?

Thanks in advance for any suggestions for additional troubleshooting or potential explanations.

Note that I have only tested with a single Notecarrier F v1.3, so I realize this might be unwarranted generalizing. I do have other v1.3s so I will repeat the test with a different Notecarrier F v1.3 board to make sure it’s not something related just to the specific part I tested.

3 Likes
2

Hi @noforan,

Thanks for your question. I got some info from the team re: differences between 1.0 and 1.3:

  1. With v1.0, the SDA/SCL is supplied directly from the feather, again with 10K pull-ups to the F_3V3 level.
  2. With v1.3, the SDA/SCL on both the Qwiic and the pcb are switched by a level shifter isolating the feather from the I2C bus, with 10K pull-ups to the F_3V3 level. This was done so that the feather can power off/on its 3V3 independently (and thus external I2C devices) and can still communicate with the Notecard.

You may already know this, but both 1.0 and 1.3 schematics are available in the note-hardware repo on GitHub.

Otherwise, we don’t know anything that should be impacting the i2c behavior and haven’t heard of other issues. I hope this helps though!

Rob

3

Thanks Rob. I have looked through the note-hardware Github repo.

Couple updates:

  • I installed a different Notecarrier F v1.3 with the same results.
  • I installed a different SD card breakout board that has no RTC, and thus no I2C device or pull-ups – with the same results in terms of no sensor data. However, in this case, the Notecard does not give any I2C errors.
  • There’s no problem if this SD breakout board is wired up, but not initialized.
  • There’s no problem if this SD breakout board is initialized but then the CS pin is disconnected.

The above results (and now your comments) make me think that while the abundance of pulls-up caused the original issue, there is also another (power?) problem as SD cards reportedly draw quite a bit of power.

So, I rewrote my program to sequentially power only the sensor board currently being polled (previously they were all powered simultaneously once the MCU came out of sleep), but that doesn’t seem to mitigate the issue.

I also tried a variety of ways to sleep the SD card during sensor reads, but the standard Arduino SD library doesn’t appear to allow for that, so I’m in the middle of changing the library over to SdFat to see if that provides better options.

I also found a few issues opened in the SdFat library that suggest there’s potentially some conflict between SPI and I2C on STM32s. I’ll chase that down too.

In any case, I think the change in Notecarrier probably just exacerbated a pre-existing condition unrelated to the Notecarrier, but I do appreciate the feedback!!

1 Like
4

Oh yeah – one other thing I tried was to slow the I2C clock frequency (via Wire.setClock() ) to 50000, 10000, 5000 Hz. Assuming the clock was actually modified, I didn’t see any beneficial change.