Hi there,
Seems I2C module (hardware mode 100Kbit) on PIC32MX130F064D is not acknowledging any READ at all. Is this a known issue? I'm running latest FC9 version.
I have enabled Slew Rate as well as SMB options, but same issue is seen.
I have attached scope trace highlighting the issue.
The I2C READ routine is exactly the same as the one from the I2C sample FCX files we've been using for years.
Thanks for taking a look at this!
PIC32MX I2C NACK ON ALL READS
-
- Posts: 54
- http://meble-kuchenne.info.pl
- Joined: Wed Sep 08, 2021 10:36 pm
- Has thanked: 26 times
- Been thanked: 11 times
-
- Matrix Staff
- Posts: 1742
- Joined: Mon Dec 07, 2020 10:06 am
- Has thanked: 442 times
- Been thanked: 604 times
Re: PIC32MX I2C NACK ON ALL READS
Hello,
When reading bytes the ack is used as a flag to let the slave know if any more bytes are going to be read. This is the "Last" parameter of the Receive Byte macro.
If last is set to 0 then the byte should be acked and if last is set to 1 then the byte is nacked.
Hopefully this helps.
When reading bytes the ack is used as a flag to let the slave know if any more bytes are going to be read. This is the "Last" parameter of the Receive Byte macro.
If last is set to 0 then the byte should be acked and if last is set to 1 then the byte is nacked.
Hopefully this helps.
Regards Ben Rowland - MatrixTSL
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
Flowcode Online Code Viewer (Beta) - Flowcode Product Page - Flowcode Help Wiki - My YouTube Channel
-
- Posts: 54
- Joined: Wed Sep 08, 2021 10:36 pm
- Has thanked: 26 times
- Been thanked: 11 times
Re: PIC32MX I2C NACK ON ALL READS
Hi Ben,
Thanks for clarifying, this makes sense! All is working perfectly well now
Cheers!
R
Thanks for clarifying, this makes sense! All is working perfectly well now
Cheers!
R
-
- Posts: 54
- Joined: Wed Sep 08, 2021 10:36 pm
- Has thanked: 26 times
- Been thanked: 11 times
Re: PIC32MX I2C NACK ON ALL READS
Just noticed the line stays low, so always 1 is needed for last ReceiveByte and should I assume there will never be an ACK? I guess this is how I2C works... I was expecting always an ACK, but I was wrong it seems...