I2C slave ACKs to any address (buggy Maxim design?) - Page 1
Forum section: electronics / projects

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 01, 2015, 02:29:15 pm
content: I have hit a bit of problem and I am not sure how to proceed.I would like to have two I2C slaves function on the same bus: aMAX17048 fuel gauge(slave address 0x36) andEEPROM(slave address 0x50). The problem is that the MAX17048 fuel gauge seems to generate a (messy) ACK to any slave address. Decreasing the baud rate and inserting delays between I2C master events does not solve the problem.I have captured some oscilloscope/decoding screen shots that clearly demonstrate the issue. The cursors highlight the ACK/NACK clock cycle."Send 0x50 with no slaves attached.png" - No ACK, as expected."Send 0x50 with only 0x50 slave attached.png" - Clean ACK, as expected."Send 0x36 with only 0x36 slave attached.png" - Clean ACK, as expected."Send 0x50 with only 0x36 slave attached.png" - Messy ACK that should not happen (also notice skewed SLK line)What could be causing this? Is there likely to be an errata for the MAX17048? What could a workaround look like?

author: SL4P
author_rank: Super Contributor
timestamp: February 01, 2015, 08:59:42 pm
content: With my very limited use of I2C - I'd be trying to figure out why the CLK line is being corrupted.Two masters ?

author: hamdi.tn
author_rank: Frequent Contributor
timestamp: February 01, 2015, 09:16:18 pm
content: value of pull up resistor maybe, what microcontroller are you using , i think i had this kind of problem ( the messy ACK )once with an STM32 with an EEPROM as far as i remember i was doing something wrong when initialising the stm32 i2c hardware.

author: Howardlong
author_rank: Super Contributor
timestamp: February 01, 2015, 09:18:30 pm
content: Is there some clock stretching going on?In addition, the traces seem to be showing something no quite right with your VCC rail, what's going on, it's wondering up and down, and it doesn't look like it's dodgy probing.

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 01, 2015, 09:53:45 pm
content: Quote from: SL4P on February 01, 2015, 08:59:42 pmThere is only one master. The skewed clock was a red herring and disappears if I insert a (<1us) delays between the master 'send' and 'stop events.Quote from: hamdi.tn on February 01, 2015, 09:16:18 pmI'm using a PIC32MX, 3.3V, 5.6k pull-ups. I slowed the clock down to 100 kHz and 50 kHz but the problem remains. The slave consistently releases SDA a few ns after the SLC rising-edge regardless of clock speed... as if it knows its done something wrong and is hoping it won't get caught! ...too late though, the master has seen an ACK.Quote from: Howardlong on February 01, 2015, 09:18:30 pmClock stretching would see SLK held by the slave but this is not happening.Quote from: Howardlong on February 01, 2015, 09:18:30 pmI saw this too. The "wondering" only occurs when the Maxim slave is attached. I think this is due to the Maxim slave having weak pull-downs on the SDA and SCL lines "for sensing disconnection" (page 6 ofdatasheet). Notice that the "wondering" up and down of SLK matches the state of SDA.Another quick observation I can share is that, by sending 0xFF, I confirmed that the slave is not asserting the SDA line at any point other than during the ACK clock cycle.Thanks for the comments and questions. Please keep them coming.

author: Howardlong
author_rank: Super Contributor
timestamp: February 01, 2015, 10:03:54 pm
content: Not sure which PIC32MX you are using. There is a feature of the PIC32MX1xx and PIC32MX2xx where it draws way too much current if the slew rate control is active. the errata only discusses I2C1 but affects both I2C1 and I2C2. You need to disable slew rate control by setting the appropriate DISSLW bit to 1.I had this exact problem on I2C2 on a PIC32MX230 a couple,of years back, it took me a long time to figure it out, not least because in the errata it only covers I2C1, and that the errata puts the error as an I/O port fault rather than I2C.

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 01, 2015, 10:26:48 pm
content: Thanks for the tip, Howardlong. I am using the PIC32MX470F512L. Thesilicon erratadoes not indicate any relevant issues. I have experimented with the slew rate control (DISSLW) and SMBus (SMEN) bits but these have no apparent effect. I also decreased the pull-ups to 2.5k, this results in 'nicer' wave forms but the unwanted ACK remains.

author: cosmicray
author_rank: Frequent Contributor
timestamp: February 01, 2015, 10:44:29 pm
content: I have seen data-sheets that say 10k for Rpullup, then I found one (Atmel AVR315) that says "The value of Rp depends on VCC and the bus capacitance (typically 4.7 k)"

author: Howardlong
author_rank: Super Contributor
timestamp: February 01, 2015, 10:54:57 pm
content: That wondering VCC concerns me, is VCC itself also wondering or is it just something else.If it were just weak pull down resistors, I would not expect it to wonder in the way it is.I assume there's no current limiting going on? Regretfully, I've been caught out on that one a few too many times. All sorts of weird stuff goes on.

author: SL4P
author_rank: Super Contributor
timestamp: February 01, 2015, 11:16:31 pm
content: Another off-beat suggestion.Is there anything in the 'real world' side of the 17048 that may be stressing the chip internally, or feeding an unexpected +/0/- voltage backintothe chip?An internal limitation of the 17048 perhaps - allowing some leakage or sink effect back through the chip onto the I2C buss? This could also affect those supply glitches with the 17048 pulling more current than expected, or feeding 'something' onto Vcc during the undocumented state...

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 01, 2015, 11:42:48 pm
content: Quote from: Howardlong on February 01, 2015, 10:54:57 pmThe VCC rail is not wondering around. The SLK upper voltage level observed on the scope is not VCC; it is VCC through a 5.6k resistor. Also, the SLK upper voltage is not wondering randomly, it consistency reduces whenever SDA is pulled-low. The wondering disappears when the pull-up resistors are reduced to 2.4k. The SLK/SDA logic high/low levels required by the slave are 0.5V and 1.4V.Quote from: SL4P on February 01, 2015, 11:16:31 pmNothing springs to mind... A relevant observation is that the slave consistently asserts the SDA line upon the falling edge of the last data bit (regardless of the byte value). This suggests that the assertion is the result of the slave's I2C logic/controller and not an arbitrary glitch that happens to align in time.

author: nctnico
author_rank: Super Contributor
timestamp: February 02, 2015, 12:44:16 am
content: Quote from: sebmadgwick on February 01, 2015, 09:53:45 pmIs your I2C protocol implementation 100% correct? I had problems with a chip from Analog devices. IIRC I didn't acknowledge the last byte my controller read with a NAK. That caused the chip to ignore the stop condition on the bus. Compare the waveforms on your scope to the datasheet very carefully.

author: SL4P
author_rank: Super Contributor
timestamp: February 02, 2015, 05:30:15 am
content: Quote from: nctnico on February 02, 2015, 12:44:16 amWorth considering... although I2C is a 'standard' - there is nothing to say that two different chips will handle the same clocks, rise-times, word lengths, and inter-bit timing identically. I see you have tried to eliminate these, but maybe worth printing the I2C part of each spec sheet to see if there is a tiny difference in how each responds - e.g. ifalreadyin slave mdoe, and then set to slave mode again... etc. May cause an unexpected extra idle bit-time or whatever.

author: free_electron
author_rank: Super Contributor
timestamp: February 02, 2015, 06:02:51 am
content: looks like a valid nack to me.the procedure for sensing an acknowledge is as follows :master raises SCLmaster samples SDA : this should be low for an ACQmaster lowers SCLthe SDA line does not need to be low prior to the SCL going high. it is allowed for SDA to follow SCL

author: Gixy
author_rank: Regular Contributor
timestamp: February 02, 2015, 08:40:17 am
content: Yes, it's NACK because SDA changes during clock high period. The decoder should also display ACK/NACK on the B1 line. Finally, the x50 device is suspect as each time it is on the bus there is a coupling between SCL and SDA.

author: SL4P
author_rank: Super Contributor
timestamp: February 02, 2015, 11:26:49 am
content: OK, far out theory.The 17048 fuel gauge Vcc and GND pins are not truly tied to Vcc/0V... ?The chip responds when addressed... biased by prevailing pin states - and floats all around the rails when it replies - while the EEROM does what it's supposed to.What happens if you lift the EEROM off the I2C buss - does the 17048 behave correctly (and the buss levels appear within spec?)

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 02, 2015, 12:29:36 pm
content: Quote from: Gixy on February 02, 2015, 08:40:17 amThe MAX17048 datasheet states:"The SDA logic level must remain stable during the high period of the SCL clock pulse"...and..."To generate an acknowledge, the receiving device must pull SDA low before the rising edge of the acknowledge-related clock pulse (ninth pulse) and keep it low until SCL returns low."The unwanted ACK does"pull SDA low before the rising edge of (SCL)", but it doesnot"keep it low until SCL returns low."; SDA returns high shortly after the rising edge. The MAX17048 is therefore is generating a NACK according to it's definition of an ACK. However, it achieves this by violating the I2C specification (as stated it's own datasheet) because SDA returns high after the SCL rising edge even though"the SDA logic level must remain stable during the high period of the SCL clock pulse"Quote from: SL4P on February 02, 2015, 11:26:49 amFar out theories are goodThe MAX17048 VCC is the battery (not 3.3V rail), this is Maxim's recommend circuit.Quote from: SL4P on February 02, 2015, 11:26:49 amThe original screenshots already showeitherthe EEPROMorthe MAX17048 attached. Even when the MAX17048 is the only device on the bus, it consistently pulls SDA low immediately following the last data bit.Quote from: SL4P on February 02, 2015, 11:26:49 amThe bus levels look ok to me. The SLK/SDA logic high/low levels required by the MAX17048 are 0.5V and 1.4V. I am able to repeatedly read measurements from the MAX17048 for long periods of time without observing any errors. This suggests that the MAX17048 does not have any issues with the SCL or SDA waveforms as generated by the master.

author: Gixy
author_rank: Regular Contributor
timestamp: February 02, 2015, 12:53:15 pm
content: Hope that GNDs are common for all the devices.Again, the I2C decoder should display the ACK/NACK. There is an interrogation mark "?" on the first picture and nothing on the others: did you configure completely the I2C trigger and decoder?

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 02, 2015, 01:08:32 pm
content: Quote from: Gixy on February 02, 2015, 12:53:15 pmOf course. Ground connections are starred and as short as possible. Ground will become dedicate layer once the design progresses to a PCB.Quote from: Gixy on February 02, 2015, 12:53:15 pmThe decoder displays a "?" to indicate a NACK. The decoder does not provide an indication of ACKs. This just how the decoder works.

author: Howardlong
author_rank: Super Contributor
timestamp: February 02, 2015, 04:02:26 pm
content: Is it worth sharing your schematic and code? Maybe there'll be something in there. Right now I'm scratching my head.I know you've discounted it, but I can't explain the wobbly VCC on the SDA/SCL. The data sheet says there's a permanent pulldown, which, if that is the case, means that you shouldn't get the wobblies depending on a combination of SCL/SDA.I am also wondering if the power into the Maxim device is steady, and it's not just running off parasitic power through the protection diodes.

author: AndyC_772
author_rank: Super Contributor
timestamp: February 02, 2015, 04:45:53 pm
content: What's this "SLK" you keep mentioning?The pins on I2C devices are SCL and SDA, always. If you have a pin somewhere called SLK, perhaps it's not designed to connect to an I2C interface at all?

author: Gixy
author_rank: Regular Contributor
timestamp: February 02, 2015, 08:24:52 pm
content: Pin is named SCL on the datasheet.Two screen copies of I2C decoding on a MSO2072A (upgraded to 2302) showing ACK displayed by decoder

author: Zarhi
author_rank: Contributor
timestamp: February 02, 2015, 09:13:00 pm
content: Quote from: sebmadgwick on February 01, 2015, 02:29:15 pmFrom datasheet You noted:QuoteSeven bit slave address 0x36 must be shifted left, and then bit 0 will be R/W, which gives exactly 0x6C/0x6D which must be transmited first.From same datasheet:QuoteSo, Your write transaction must be 4 bytes: "Write: S. SAddr W. A. MAddr. A. Data0. A. Data1. A.P"And read transaction is 5 bytes: "Read: S. SAddr W. A. MAddr. A. Sr. SAddr R. A. Data0. A. Data1. N.P"S => Start conditionSAddr => Slave address (0x6C - read, 0x6D - write)A => AckSr => Repeated Start conditionP => Stop condition

author: Howardlong
author_rank: Super Contributor
timestamp: February 02, 2015, 09:24:32 pm
content: Quote from: Zarhi on February 02, 2015, 09:13:00 pmIf you look at the OP's waveforms, that is what they're doing.

author: Zarhi
author_rank: Contributor
timestamp: February 02, 2015, 09:47:08 pm
content: I already look at them and see: "Start condition, 0x36, ...." which gives "7-bit address" 0x1B + R/W bit = 0 (write). And that is not MAX17048 slave address.

author: Zarhi
author_rank: Contributor
timestamp: February 02, 2015, 09:53:17 pm
content: BTW: Same mistake with 24AA256, it's 7-bit address is 0x50 (A0-A3 at GND), but that must be shifted left, which gives 0xA0 for writing and 0xA1 for reading EEPROM.

author: Gixy
author_rank: Regular Contributor
timestamp: February 02, 2015, 10:01:22 pm
content: Right, and this is exactly what you can see on the pictures... The decoder takes into account the shift.

author: Zarhi
author_rank: Contributor
timestamp: February 02, 2015, 10:07:48 pm
content: Sorry my mistake. When counting pulses it looks that 0x36 and 0x50 are left 7 bits only. I expect to see "0x36, W" or similar from that I2C decoder.

author: cosmicray
author_rank: Frequent Contributor
timestamp: February 03, 2015, 12:41:01 am
content: Quote from: sebmadgwick on February 02, 2015, 12:29:36 pmI read the data-sheet, and that is what it shows. What about the battery ... is it reasonably well charged when this happens ?

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 03, 2015, 03:10:55 pm
content: Quote from: AndyC_772 on February 02, 2015, 04:45:53 pmSorry, this is just a typo. I am only ever referring to the clock (SCL) and data (SDA) lines of a standard I2C bus. I would have meant "SCL" when saying "SLK".Quote from: Gixy on February 02, 2015, 08:24:52 pmThanks for sharing. I am using a Rigol DS2202A with "Rigol RS232, I2C, SPI Decoding Kit Option". It looks like the MSO provides more information than the DSO.Quote from: cosmicray on February 03, 2015, 12:41:01 amMost of this debugging has been with the battery fully charged (charger attached). When not debugging, I have been reading/logging the fuel gauge measurements at 4 Hz during charge/discharge cycles with the battery voltage ranging from 3V to 4.2V. The part consistently provides reliable measurements. I have not specifically tested the for the erroneous ACK at different supply voltages.

author: amyk
author_rank: Super Contributor
timestamp: February 03, 2015, 04:15:40 pm
content: Have you tried asking Maxim...?

author: sebmadgwick
author_rank: Regular Contributor
timestamp: February 06, 2015, 04:00:07 pm
content: Quote from: amyk on February 03, 2015, 04:15:40 pmNo. I'm cynically assuming that they would not assist an individual unless I proposed a volume order.I have tested an alternative but similar Maxim part, the MAX17047. It does not have the ACK problem. I'm increasingly convinced that the problem is a Maxim bug. The bug is inconsequential provided that all slaves on the bus ACK when addressed. It is not hard to believe that this bug (on such a new part) could go unnoticed.

author: SL4P
author_rank: Super Contributor
timestamp: February 06, 2015, 08:11:19 pm
content: Quote from: sebmadgwick on February 06, 2015, 04:00:07 pmCertainly sounds dubious.The only thing that still niggles me (and I'm happy to accept that you've found a manufacturers bug) is that there could be- somethingveryspecific about word length (collision of tx/rx bits), or- a voltage floating/pulled somewhere (which is only applied under specific chip states)- perhaps an internal gotcha which is only apparent insomevery specific operating configuration which they never validated.Good luck - a really interesting bit of exploration