Have you made any progress in understanding how your instrument
Digilent Analog Discovery 2, work, and how it is used?
It may seem from capture in message #16 that observation is done with sampling frequency 400 kHz for 1 million samples.
This might capture a whole 2 seconds measurement sequence,
but sampling frequency may be too low to capture I2C signaling at 100 kHz.
And it is impossible to see any details in the signal, you may try to capture a shorter interval.
Also, capture in message #16 show a lot more signaling
than should be from communication with the sensor.
Question is whether this is caused by noise on the signal lines,
other signaling on the same bus, or wrong setup for the instrument.
What are the signal voltage detection levels used by the Logic Analyzer Inputs?
Questions above are reason for me asking for observation of these signals using oscilloscope mode.
Signal decoding in the Logic Analyzer software seem to function,
but those error messages may indicate sampling frequency too low for the signaling rate,
or other settings not suitable for the actual signals.
Please be aware, that 'Blocking Communication' and 'Hanging program' are two different concepts, and should not be mixed up.
Blocking communication, means doing one thing at a time, and wait while message is transferred.
Waiting for 2 or 10 milliseconds, may not be a big deal if controlling mechanical equipment with time constants between 100 milliseconds and 10 seconds.
Non-blocking communication, is about ability to do other tasks while communication is ongoing.
While this may make your program able to respond sooner, it also make your program more complicated, and may be more vulnerable to bugs in your application code, or in MCC generated code.
I am trying to remove mistakes in the I2C code generated by MCC, and get Interrupt configuration of the I2C code to work better. I do this for my own curiosity, and possible benefit for other members. I am Not doing this on behalf of Microchip Company, but with a (small) hope that MCC developers may pay attention, and eventually improve the generated code.
If you are able to test in your environment, and provide feedback that is possible to interpret, it may be possible to get progress.
Attached are two experiment / example project packages.
The smaller one, Humidity_Sensor.zip have only been run in simulator.
The other have configurations for 3 different devices, default configuration is with PIC16F1718.
In addition to wakeup code for the humidity sensor, it also have a scan for available devices on the bus,
and some Real-Time Clock stuff.
The I2C driver code in this project have some additional modifications.
There are UART print, using pin RC6 for TX data, with bitrate is 38400 bit/s.
post edited by Mysil - 2020/12/01 16:21:33