SM72442 I2C Register Read Returns 6 Bytes Instead of 7 With Arduino—Why?

183 11

#1 21683393 31 Oct 2019 03:27

Justin Huebner Justin Huebner

Anonymous
Post #1
21683393 31 Oct 2019 03:27

I am using an sm72442 for mppt power management. I am using an arduino to prototype a board. The problem I am having is that the datasheet shows that there are 7 bytes in each register; I have set up the communication with no problems, but I can't seem to get all the data. I only get 6 bytes from the chip, and always a number 7. So, my data looks like this, for every register:
(byte::data)1::72::data3::data...6::data7::0
So, I can't tell if the data is missing from the front of the transmission or the end. I also don't know why I am receiving a 7, when my microprocessor should be the one sending a 7. If I instead request 8 bytes, I still receive a 7 as the first byte, and more zeros at the end of the transmission.I have also tried to write to every register with the max value. When I read the data back, I get data like the following:(byte::data)1::72::2553::255...6::2557::0
I would really appreciate any advice for troubleshooting this problem, it has been driving me crazy. I've tried every combination of things I can think of.

Attachments:

forums-page12.png (347.16 KB) You must be logged in to download this attachment.

forums-page13.png (269.98 KB) You must be logged in to download this attachment.

forums-sketch.txt (1.79 KB) You must be logged in to download this attachment.
ADVERTISEMENT
#2 21683394 31 Oct 2019 13:22

Maurizio Di Paolo Emilio Maurizio Di Paolo E...

Anonymous

Post #2
21683394 31 Oct 2019 13:22

I2C libraries for Arduino don't work...? That IC has a dev kit...?
ADVERTISEMENT
#3 21683395 31 Oct 2019 21:01

Elizabeth Simon Elizabeth Simon

Anonymous

Post #3
21683395 31 Oct 2019 21:01

I don't see where you set the I2C speed? It looks like the sm72442 only supports 100kHz.
ADVERTISEMENT
#4 21683396 31 Oct 2019 21:53

John Beetem John Beetem

Anonymous

Post #4
21683396 31 Oct 2019 21:53

I usually need a digital 'scope to debug I2C problems. I2C can be confusing if you don't work with it every day (or week). With a 'scope you can see if it's a signal integrity problem or a timing problem, such as I2C speed as Elizabeth suggested.
#5 21683397 07 Nov 2019 03:28

Justin Huebner Justin Huebner

Anonymous

Post #5
21683397 07 Nov 2019 03:28

Update: I believed that 100khz was the default i2c frequency for Arduino, which is true. Explicitly declaring this in code had no effect. I snooped the communication on the scope, and have determined that the chip is only sending 6 bytes, which is what I am getting in code.
2 bytes for selecting device and command register, then a pause, then requesting 7 bytes from the device, but only getting 6 in response.

Zoom in on the request to the device, and its response.

I can, of course, request more bytes from the device, but they are always zero, even after writing 0xFF to every byte.I have no idea where to go from here.
#6 21683398 08 Nov 2019 10:55

Rose Eden Rose Eden

Anonymous

Post #6
21683398 08 Nov 2019 10:55

Like UART communication, I2C only uses two wires to transmit data between devices: SDA (Serial Data) – The line for the master and slave to send and receive data. I2C is a serial communication protocol, so data is transferred bit by bit along a single wire (the SDA line).
#7 21683399 08 Nov 2019 21:53

Elizabeth Simon Elizabeth Simon

Anonymous

Post #7
21683399 08 Nov 2019 21:53

Justin,If I remember right, the master (Arduino) sends out the SCLK even when the slave (sm72442) is sending back data. So I'm wondering why the Arduino isn't sending out the SCLK for the last byte...When you write to the sm72442 do you see the right number of bytes getting sent?
#8 21683400 09 Nov 2019 15:18

Rose Eden Rose Eden

Anonymous

Post #8
21683400 09 Nov 2019 15:18

The line for the master and slave to send and receive data. I2C is a serial communication protocol, so data is transferred bit by bit along a single wire (the SDA line).
#9 21683401 14 Nov 2019 04:13

Justin Huebner Justin Huebner

Anonymous

Post #9
21683401 14 Nov 2019 04:13

The arduino master does pulse the clock line while the slave sends data. I should have shown the picture of the scope where I request more data. Any data after the 6th byte returns as 0x00. The best way I can explain the real confusion here is this: I can write all registers to 0xFF. Still, I will always get the first byte back as 0x07, and any bytes after the 6th byte returns as 0x00. So, I can't tell if there is something causing me to get a 0x07 as the first byte, or if there is something causing me to lose the last byte every single time.
The first byte is what really jumps out at me, because I think that the aruindo should be sending the 7, as the number of bytes. But it is always 7 even if I request 8 or 6 bytes.
#10 21683402 14 Nov 2019 04:47

Paul Reds Paul Reds

Anonymous

Post #10
21683402 14 Nov 2019 04:47

Hi Justin,are you facing the same issue described here: https://github.com/arduino/ArduinoCore-avr/issues/171?I don't know whether that issue has been fixed or not, but according to the user Wire.requestFrom"... is not returning the number of bytes returned from the slave device, it is returning the number of bytes requested from the slave device..."
ADVERTISEMENT
#11 21683403 16 Nov 2019 17:30

John Swinehart John Swinehart

Anonymous

Post #11
21683403 16 Nov 2019 17:30

This is a topic that is near to my heart... Cheers! Where are your contact details though?wow 51900 error 319
#12 21683404 15 May 2020 13:55

eva poppy eva poppy

Anonymous

Post #12
21683404 15 May 2020 13:55

where do u set the I2C speed? I can write all registers to 0xFF. Still, I will always get the first byte back as 0x07, and any bytes after the 6th byte returns as 0x00.
Create an account, log in here. You will receive points by participating in discussions.
Join this discussion.

Install Elektroda application

Didn't find an answer? Ask Artificial Intelligence

*I agree to send the question to OpenAI, Anthropic PBC, Perplexity AI, Inc., Kagi Inc., Google LLC - owners of language models in order to prepare the best response. The companies may monitor and log information entered into the form.

*I agree to publicly display my question and answer. The question and answer will be publicly available to everyone. The process may take a few minutes. Upon completion, you will be redirected to the page with the answer.

Wait...(2min)

Topic summary

✨ The discussion addresses an issue with reading I2C registers from the SM72442 MPPT power management IC using an Arduino. The datasheet specifies 7 bytes per register, but only 6 bytes are received consistently, with the first byte always being 0x07 and subsequent bytes after the sixth returning 0x00, even when requesting more bytes or writing maximum values (0xFF) to registers. The Arduino acts as the I2C master, generating the clock (SCLK) during data reads, but the last byte appears missing or replaced by zeros. Troubleshooting steps include verifying I2C speed (noted that SM72442 supports only 100 kHz), using an oscilloscope to monitor signal integrity and timing, and considering Arduino Wire library behavior where the number of bytes returned may not match the number requested. The problem may relate to the I2C communication protocol nuances, clock pulsing, or library limitations rather than hardware faults. No definitive solution was reached, but suggestions emphasize scope analysis and careful timing and protocol verification.
Generated by the language model.

FAQ

TL;DR: On the SM72442, users report "only sending 6 bytes" when 7 are requested—14% of data missing. Fix by validating I2C speed, reads, and clocking. [Elektroda, Anonymous, post #21683397]

Why it matters:** Incorrect I2C handling can hide a full byte of configuration/telemetry, breaking MPPT accuracy and safety during prototyping.

Typical I2C speed for SM72442 is 100 kHz; set Arduino Wire to match. [Elektroda, Anonymous, post #21683395]
Arduino Wire.requestFrom may return bytes requested, not bytes received—check with scope or Wire.available(). [Elektroda, Anonymous, post #21683402]
Master still drives SCL while slave returns data; confirm clock continues through the last byte. [Elektroda, Anonymous, post #21683399]
Observed symptom: first byte reads 0x07; bytes after the 6th are 0x00. [Elektroda, Anonymous, post #21683401]
Verified on scope: device replied with only 6 bytes when 7 were requested. [Elektroda, Anonymous, post #21683397]

Quick Facts

Typical I2C speed for SM72442 is 100 kHz; set Arduino Wire to match. [Elektroda, Anonymous, post #21683395]
Arduino Wire.requestFrom may return bytes requested, not bytes received—use Wire.available() to verify. [Elektroda, Anonymous, post #21683402]
During reads, the master provides SCL for every data bit and ACK/NACK phase. [Elektroda, Anonymous, post #21683399]
Symptom pattern: first byte 0x07; bytes 7+ read as 0x00. [Elektroda, Anonymous, post #21683401]
Scope capture showed only 6 data bytes returned after a 7‑byte request. [Elektroda, Anonymous, post #21683397]

Why do I only read 6 bytes when the SM72442 register is 7 bytes?

A scope capture showed the device replying with only six data bytes after a seven‑byte request. Confirm SCL continues through byte 7 and that Wire.available() reflects actual bytes. If the device NACKs earlier, you will read fewer bytes. [Elektroda, Anonymous, post #21683397]

Could I2C speed cause the missing 7th byte on Arduino?

Yes. Set Wire clock to 100 kHz to match the SM72442’s typical speed. Mismatched timing can truncate transfers or cause NACKs on late bytes. Reinitialize Wire after changing speed to apply it before transactions. [Elektroda, Anonymous, post #21683395]

Is Arduino Wire.requestFrom reporting bytes received or requested?

On AVR cores, users observed requestFrom returning the number requested, not the number received. Validate the real count using Wire.available() and a logic analyzer. Quote: "...is not returning the number of bytes returned..." Use this to guard loops. [Elektroda, Anonymous, post #21683402]

What does the first byte always reading 0x07 mean?

In the reported setup, the first byte consistently appeared as 0x07, suggesting software interpreted a length field or stale buffer value. Since later bytes past six were 0x00, investigate read framing and buffer handling in your code. [Elektroda, Anonymous, post #21683401]

How do I verify whether the slave or my code is dropping the last byte?

Use a digital oscilloscope or logic analyzer. Check that seven full data bytes and ACK/NACK cycles appear on SDA/SCL. If only six bytes clock, the slave stopped early; if seven clock but code sees six, review buffering and reads. [Elektroda, Anonymous, post #21683396]

Does the Arduino provide SCL while the SM72442 sends data back?

Yes. In I2C, the master always supplies SCL even during reads. If the seventh byte is missing, ensure the master continues clocking and does not prematurely NACK/STOP before byte seven. [Elektroda, Anonymous, post #21683399]

How can I reproduce the forum test where bytes 7+ are 0x00?

Write 0xFF to each register byte, then perform a multi‑byte read. In the reported case, byte 1 read 0x07 and bytes after the sixth read 0x00, indicating read truncation or framing issues. [Elektroda, Anonymous, post #21683401]

Quick 3‑step: how do I read all 7 bytes reliably?

Set Wire clock to 100 kHz and restart Wire.
Request 7 bytes, loop on Wire.available() to read exactly available bytes.
Confirm seven bytes and ACKs on a scope; adjust STOP/NACK timing if needed. [Elektroda, Anonymous, post #21683395]

What is I2C in simple terms?

I2C is a two‑wire serial protocol using SDA for data and SCL for clock. The master controls SCL; data moves bit‑by‑bit on SDA. You can connect multiple devices and address them by ID. [Elektroda, Anonymous, post #21683398]

Why does requesting 8 bytes still show 0x07 then zeros?

The capture showed the device returned only six meaningful bytes. Extra bytes delivered as 0x00 likely reflect unread or defaulted buffer positions when the slave stopped sending. Validate with Wire.available() and analyzer traces. [Elektroda, Anonymous, post #21683397]

What’s an edge case that breaks reads even at 100 kHz?

If the master issues STOP or NACK too early, the slave won’t output the final byte. Ensure the code performs the final ACKs correctly, then a NACK on the very last byte before STOP. [Elektroda, Anonymous, post #21683399]

How big is the data loss when 6 of 7 bytes arrive?

You lose 1 of 7 bytes, or about 14.3% of the register payload. That missing byte can corrupt scaling, checksums, or status bits critical for MPPT control. [Elektroda, Anonymous, post #21683397]

How do I confirm the SM72442 actually sends seven bytes?

Probe SDA/SCL and count bytes between the read address ACK and STOP. You should see seven byte times plus ACK/NACK bits. If you see six, the device or command framing is wrong. [Elektroda, Anonymous, post #21683397]

Could the symptom be pure software even if the bus looks fine?

Yes. If requestFrom reports the requested length, your loop may overread or misreport. Always gate reads by Wire.available() and log actual counts to serial for proof. [Elektroda, Anonymous, post #21683402]

What’s the best first tool to debug this on Arduino?

Use a logic analyzer or scope. Quote: "I usually need a digital 'scope to debug I2C problems." It reveals timing, ACKs, and byte counts instantly, saving hours. [Elektroda, Anonymous, post #21683396]

Does changing Wire speed on the fly help?

Set the speed before transactions and reinitialize if needed. Once configured to 100 kHz, verify on the scope that SCL is correct and stable during the entire read. [Elektroda, Anonymous, post #21683395]

Generated by the language model.