Issue with I2C on Photon

Troubleshooting
21

Since I see no solutions posted yet, I beg to ask another question (Just for consideration, no reply necessary).
Since the Photon runs much faster than the Core, could the Photon be pushing data to I2c bus faster than it can handle?

22

The 9th bit of the frame is the NACK/ACK bit. This is the case for all frames (data or address). Once the first 8 bits of the frame are sent, the receiving device is given control over SDA. If the receiving device does not pull the SDA line low before the 9th clock pulse, it can be inferred that the receiving device either did not receive the data or did not know how to parse the message. In that case, the exchange halts, and itā€™s up to the master of the system to decide how to proceed.
From https://learn.sparkfun.com/tutorials/i2c

23

Hey @BDub. I just thought I would check in. Have you guys had a chance to look into this at all yet?Thanks a lot!

Erin

24

@modulo we just talked about this today and will be giving it some attention in a couple days. Thanks for your patience on this :smile:

1 Like
25

Cool. Thanks, @BDub.

26

Hi @modulo,

I think I got a fix for this issue on both Core and Photon via this commit:

Hope it addresses your concern and thanks for bringing out this issue in open.
Please let us know the result after testing with the latest code in ā€œdevelopā€ branch.

Thanks,
Satish

27

Thank you, Satish! Iā€™ll find some time soon to give it a shot.

28

@modulo did this fix work for you?

Im having trouble getting my mpu6050 working. i can see the bus stops after some time and its in exactly the spot where @satishgn made the fixes.

Its driving me madā€¦ i cant wok out how to use my scope to catch the data right before it fails. any ideaā€™s? (i have a MSO-19.2 scope/logic analyzer)

If i leave the code running i can see a few little blips on the bus and every once in a while it will restart and run for a bit and then stop again.

29

I actually still havenā€™t had time to test the fix. Iā€™ve just been busy with other priorities. Hopefully Iā€™ll have time soon and Iā€™ll definitely post here either way when I do.

30

I think Iā€™m also having this issue. How do I load the fix onto my Photon? Iā€™m trying to compile it from source, but Iā€™m having problems because the instructions arenā€™t quite current. Is that even necessary? Is there a way to make the Photon grab the fix over the air?

31

I found more instructions that tell me how to install from the develop branch, and Iā€™m to the point of compiling, but now Iā€™m getting these linking errors:

`snprintf' referenced in section `.text.log_print_' of /var/folders/mx/5lh29pcs0lsgq2chqfzdykb40000gn/T//ccTIcVLi.ltrans3.ltrans.o: defined in discarded section `.text' of ../../../build/target/system-part1/platform-6-m-lto/../../../modules/photon/system-part1/src/import_rt.o (symbol from plugin)
`vsnprintf' referenced in section `.text.log_print_' of /var/folders/mx/5lh29pcs0lsgq2chqfzdykb40000gn/T//ccTIcVLi.ltrans3.ltrans.o: defined in discarded section `.text' of ../../../build/target/system-part1/platform-6-m-lto/../../../modules/photon/system-part1/src/import_rt.o (symbol from plugin)
collect2: error: ld returned 1 exit status
make[1]: *** [../../../build/target/system-part1/platform-6-m-lto/system-part1.elf] Error 1
make: *** [/Users/owen/firmware/modules/photon/system-part1/makefile] Error 2

Any ideas?

32

Getting the same error as @osmithy

Can one of the people more active in the develop branch suggest the best stable snapshot/commit to develop from for the Photon/P1 ?

Also, is there any other guide other than the build.md that outlines building / flashing for the new hardware?

33

Are you sure youā€™re building the latest develop?

Thise errors with log_print_ are related to compiling with DEBUG_BUILD=y. This was reported as issue 473 and fixed in this commit: https://github.com/spark/firmware/commit/2b5e45c9cb47bf64b17f6a8c2f4744caf6cda895

Please either remove the DEBUG_BUILD flag or update to that commit. Thanks :smile:

34

Iā€™m three commits ahead, and was still having that issue.

Successfully compiled and flashed via dfu-util with COMPILE_LTO=n ( https://github.com/spark/firmware/issues/471 ) but Iā€™m having issues getting code to run, P1 is unresponsive even after flashing tinker.

Is there a stable branch for building to P1 and Photon?

35

Yes, the release/0.4.3 branch tracks the latest release.

1 Like
36

Just to tie up that loose end about the P1 not responding - the P1 issue is resolved, 0.4.3 Building locally for P1 issues [SOLVED]

37

Yup. Big thanks for all the help, mdma

And to update, 0.4.3 firmware has I2C working for both P1 and Photon

1 Like
38

Hey all. I finally got back around to testing this.

I wasnā€™t sure if this fix is in any release branches, so I decided to try the develop branch. Unfortunately, after getting my local firmware build working with the develop branch it still doesnā€™t appear work. Iā€™m getting the same behavior as before.

After digging around a bit I found that the earlier fix may have been reverted? Hereā€™s the change I found.

Satish or other Particle folks, do you have any new info on this?

Thinking about the change a little more I think this should not be a timeout condition anyway. If a NACK is received it should be possible to detect that immediately without any delay waiting for a timeout.

Thanks a lot,
Erin

39

I did a little more digging. I think the problem is that itā€™s stuck waiting for the ā€œmaster transmitter mode selectedā€ event but instead we get a ā€œslave ack failureā€ event.

I tried coding a fix and it seems to address the immediate problem, though Iā€™m not sure if the return values are correct (could use some enums or constants for those) or if it affects any other conditions.

I forked the firmware repo and checked a change in here if youā€™d like to have a look:

Itā€™s still freezing up when I try to run a more complicated test using the modulo protocol. Iā€™m not sure why, or where itā€™s stuck. Hmm, I think itā€™s time to go order a programmer shield. :smile:

40

@modulo, did you see the STM32F20x I2C errata:

STM32F2ā€™s I2C limitation(from ERRATA):
1)Start cannot be generated after a misplaced STOP
2)Mismatch on the ā€œSetup time for a repeated Start conditionā€ timing parameter

I suspect you may be seeing condition 1) and the only solution is a soft reset of the I2C channel. I'm trying to get to this with the Particle team. Nice work! :smiley: