MCP39F521 i2c power monitor

[manu]

Hello,

I am having issue trying to drive this component with a dspic33 (I2C is stuck after the I2C address).
(I am suspecting I2C communication weirdness, despite I already have a RTC on this I2C bus which is working).
Does anybody has ever use this chip because I cannot find any code example?
Hopefully I have the demonstration board to compare with my faulty custom board.

What I have on my custom board: cf. attachment #1

what I should have (on the demonstration board from Microchip): cf. attahment #2


Thanks,
Manu

[StuUK]

was the RTC the only device on the bus before you added the new device?

[manu]

Yes, I desoldered the RTC (MCP79402 by the way...) and I kept 2 MCP39F521 (with different I2C addresses configured with straps on their A0 A1 pins)

[manu]

Weird,
I have connected the Microchip demo board to dspic33 and it works (with only one MCP39F521), my pcb must have some issues...

[manu]

Got it: the pins COMMON A and common B must be shorted to make the component work. 
(beside that, these 2 pins play absolutely no role )

[PiotrO]

Hi manu,
I see You are playing with this chip. I trying to get it working with micropython on ESP8266 and constantly getting I2C buss error.
I2c bus seems to be working as I have test slave i2c device (BMP180 temp/preasure sensor) which works.

May You hint me what is minimal working config of 39F521 for You?
Looking on data sheet it seems that AVdd, DVdd, RESET (connected to Dvdd), A0, A1 and SDA/SCL with pull-ups are needed to be connected to get I2C working (OSCO/OSCI are optional). Do You believe is it correct assumption?

I'm asking as I need to verify here is root cause of my issue:
-is chip not properly booted or
-chip works but I2C is not working (or 39f521 don't likes ESP8266 I2C master)

thx in advance

[manu]

Hello Piotr,

The demo board user guide gives a schematic for this chip:
http://ww1.microchip.com/downloads/en/DeviceDoc/50002413A.pdf

Don't forget to connect pins COMMONA and COMMONB together!
Both pins /RESET and /MCLR must be tied to DVdd via 4k7 resistors
The i2c address pins A0 and A1 must be tied to ground with 0ohm straps (for i2c address ending with 00).
REFOUT should have a 10uF capacitor.

Do you have some sort of logic analyzer or oscilloscope to check if the mcp39f acknowleges a i2c request from your esp8266 master?
(The protocol of the mcp39f isn't very straightforward...)

[PiotrO]

manu,

Thx so much for quick replay!

Indeed - I forgot to mention in my post about commonA/commonB. They are connected.
Interesting is that Microchip data sheet omits /MCLR.
Demo board has it pull-up'ed to Vdd.
I added this in my circuitry and now things move little forward:

was: i2c scan detected only my test slave (BNP180, adds 119)

now: i2c scan reports 116 and hangs

looks like 39f512 don't likes I2C scan procedure (starts I2C with addr to device and waits for ACK)

OK - maybe 39f512 hasn't fully conformant I2C implementation - so lets forget i2c scanner issue.
Unfortunately - any attempt to access 39f512 gives I2C bus error.

I'm wonder what chip address are You using in Your software?

I'm asking as micropython for BMP180 (my test slave) uses addr 119 (0x77) - while BMP180 docs are saying 0xEE. Looks for me like big endian vs low endian issue.

For 39f512 I tested 0x15 and 0xE8 - none works.
 
BTW: Another difference between data sheet and demo board is RESET/ - demo had pull-up while data sheet has directly to Vdd. But this is for delta-sigma ADC - so shouldn't be issue....

I'm out of ideas....

maybe i2c speed issue?
ESP8266 has it quite slow - I see it on LED on ESP8266

[gmb42]

Are you remembering about I2C address bit shifting?  The I2C address is 7 bits long and is in the upper 7 bits of the first byte, followed by the direction bit.

This causes endless confusion as to whether software should use the straight 7 bits (e.g. 0x77) or shifted one place to the left, i.e. 0xEE.

See here for more info.

Scanning the data sheet the MCP39F521 is at address 0x74 + 2 * A1 + A0, that is A1 and A0 set the bottom two bits of the address.  If you have both A1 and A0 tied to ground, then the address is 0x74, or 0xE8 when bit-shifted.

[manu]

Here are 2 screenshots for reading the version registers (request and response).

With A0 and A1 tied to ground, the 7-bit i2c address is 0x74 (0xE8, if your library uses 8-bit i2c address).
Try these addresses, but don't forget to reset (or power cycle) the MCP39F at each new try if it hangs, because, even if your code is correct, the MCP39F state machine could be blocked in an undefined state.

Also, make sure your checksum is good and don't forget to add 10ms between a request and its response.

Despite you have a micropython, I could post my C code if you need something to compare with.

[PiotrO]

Well - I don't get it.

I attached logic analyzer to my I2C bus.
I asked my software to send frame as in Yours "03_requete_System_Version".

Sending this to 0x77 addr (my test slave; BMP180) gives all 9 bytes ACK'ed by slave.
(pls see attached 0x77-ACK.png)

Exactly the same software but with addr=0x74 (mcp39f521) exits after sending I2C addr byte (slave gives NAK, so micropython library returns with error).
(pls see attached 0x74-NAK.png)

I2C sequence for slave at 0x74 looks OK for me :-(
For me it looks like mcp39f521 - by some reason - not ACK it's address.
I'm out of ideas why.
I don't know - is this chip not booted by some reason, or addr is wrong or I2C timing or....

I was thinking that maybe I2C state machine went in bad state so I managed to get mcp93f521 master reset before starting I2c cycle (I added /MCLR to GPIO on my ESP8266 and generate short drop to low; 100ms wait; start I2C trans). No difference...

BTW: May somebody give me voltages on all mcp39f521 pins on properly working chip?
Maybe I missed something in circuitry?

[manu]

Could you send your schematic to check you didn't miss something?
Try to slow i2c to 100kHz just in case your pull up resistors are too high.

[PiotrO]

manu,

To avoid potential errors in circuitry I build another test bed based on development board (pls see attached pic).
Next I done tests with logic analyzer. New circuitry behaves exactly the same: NAK after 0x74 address byte.
I hand draw schematic exactly from this new circuitry (see attached pic) - so this schematic is exactly what I have as test bed.

BTW: Interesting is that mcp39f521 react on I2C bus for 0x74 address and an other addr in the same way.
Looking on timing after 8th bit data (b0) and around clock pulse for ACK - it looks like mcp39f521 not touches SDA at all.

Pls look on delay between fall SCL edge and rise edge on SDA: it is the same for b5 and b0.
For b5 SDA rise is driven by pull-up as master turns-off drain FET to generate high state on SDA line.
For b0 it is dependent on slave - after master turns-off drain FET.
If slave is dead or addr is wrong - then b0 SCL->SDA delay between edges should be similar to b5 - and it is the same in my case.
I'm concluding that I2C subsystem on my mcp39f521 is not working at all or it is not recognizing 0x74 address.
Q is why...

I have push-button on mcp39f521 at pin26 (/MCLR). Resetting chip not helps....

[manu]

There are a few mistakes on your hand drawn schematic:
- pin 13 SCL goes to SCL of your microcontroller. The 2k4 resistor must be between pin 13 and 3.3V (but it seems good on your photo, so check your wiring)
- pin 14 SDA goes to SDA of your microcontroller. The 2k4 resistor must be between pin 14 and 3.3V (but it seems good on your photo, so check your wiring)
- pin 21 goes to GND and not 3.3V! ((but it seems good on your photo, so check your wiring)
- pin 23 : add a 10uF and a 100nF for Vref decoupling (probably optional to check i2c communication, but who knows...)
- pin 24 goes to GND and not 3.3V!
- pin 25 goes to 3.3V and not GND

To be clear:
- pins 21, 24, 27, 12, 15  -> GND
- pins 11, 25 -> 3.3V

[manu]

Another question:
could you give me the reference of the qfn adapter? (schmartboard has only 0.5mm and this one is 0.4mm pitch)
thank you.

[PiotrO]

Argh - forgive me wrong DRAWING.
pins 13 & 14 are via 2k4 to 3V3.
pin 21 goes to GND. My drawing is misleading here. Sorry for lacking annotation.
pin 24 goes to GND and pin 25 goes to 3.3V: I simply wrongly draw it on paper.

I can confirm:
21, 24, 27, 12, 15 and heat pad are on GND.
25 goes to 3v3.
11 goes to 3v3 via 47ohm.
I tested pin 23 with 10u - no change.

So I assume my application is not missing anything.
As it is still not working I think issue might be then in:

1.voltage levels on SDA/SCL
2.timming on I2C bus

For 1\ I will try to verify - but this needs digital oscilloscope. Will think how to approach this.

For 2\ I tested with 10kHz I2C clock (9 bits sent in 1ms). No change.

So currently my conclusion is:

1.maybe ESP8266 gives low voltage levels which is not qualified as low by microchip. (strange as BMP180 works OK)
2.maybe I2C speed is wrong (but 400kHz, 100kHz and 10kHz have identical sympthoms)
3.maybe I2C start condition is not recognized (i.e. because MCP not tolerates sequence like on screens attached. Albeit is OK for me and it is conforming I2C specs. in my opinion)
4.maybe application of MCP is wrong (well - still based on microchip data sheet - even with error in data sheet about lacking /MCLR connected to Vdd)

Anyway - I would not advice to go with this chip.
Situation that developing any solution with this chip requires from me logic analyzer and then digital oscilloscope is not engineer friendly...   

If anybody has any additional idea to verify something else - I would love to hear & try!

br

[PiotrO]

Another question:
could you give me the reference of the qfn adapter? (schmartboard has only 0.5mm and this one is 0.4mm pitch)
thank you.

Oh - sure.
I've got it from AliExpress. 4.20Eur for 10pcs.
https://pl.aliexpress.com/item/10p-lot-QFN28-DIP28-patch-turns-into-the-adapter-plate-0-5-5-4-4-mm/32751823211.html?spm=2114.13010608.0.0.UcnlwW

[manu]

mmmh, I can't see if you have a jumper between pins 4 and 5, but you've drawn it on your schematic, so I will suppose this connection exists.

Do you have an Arduino or another platform to verify if ESP8266 is the cuplrit?

[PiotrO]

Well - finally I got it working.

Issue was lacking 4MHz oscillator!
I simple can't believe this!!!!

Looking on data sheet (page11):
OSCI and OSCO provide the master clock for the device. Appropriate load capacitance should be connected to these pins for proper operation. An optional 4 MHz crystal can be connected to these pins. If a crystal of external clock source is not detected, the device will clock from the internal 4 MHz oscillator.
I see here clearly: An optional 4 MHz crystal

I tested 5 different chips - none works without XTAL.
How this is possible?

I'm VERY disappointed by Microchip documentation quality. It misses 1 key message: /MCLR pull-up to Vdd and has wrong info regarding XTAL.
Ill conntact Microchip about this.

Anyway: I wrote web server script for ESP8266 for reading MCP39F521.
it is here:https://github.com/warpme/MCP39F521

Next days I'll put this chip into field operation with real load.
Let see will I have another 'surprises' with MCP39F521....

@manu - MILION thx for Your support!

[manu]

Very strange, I have a board with 2 MCP39F521's for evaluation purpose.
None of them has something attached to OSCI and OSCO and they work anyway...
Here is the schematic for the Microchip demo board:


I gave up with this chip because I tried to use it a little out of his primary specs: DC application (the chip could deal with that) and high side current sensing via a current shunt monitor (mid biased to have bipolar current sensing with unipolar voltage ouput). The MCP39F521 is designed to be low-side direct current shunt sensing.
It is impossible to offset the current amplifier on the MCP39F to get signed value on the current. Believe me, I tried a bazillion values on a bunch of the config registers without success.

The datasheet is very poor as you said and it took me a lot of time to start with this chip. And, as always with i2c, I couldn't go back to the time I didn't own a logic analyzer with i2c interpreter.
My shortcut to start was to buy the demo board from Microchip, sniff the packets and code to mimic them on my microcontroller.
 
However, I guess it could be a nice if used properly chip because I found it quite precise and it processes a lot of data (active power, rms values, nice energy accumulators, ...) Theses values could be processed in software but it is quite time consumming to write these routines.

I'm glad I could help!

[manu]

maybe if common a and common b are not tied together, the external oscillator is mandatory?

[martinayotte]

I had similar issue where internal oscillator of STM32F030 was running only at 1/8 of expected frequency if AGND was not connected to DGND.

[brianthechemist]

Hi Manu,

I too am having problems with this chip on a breakout board.  Did you get the C code working with the demonstration board?  I just bought the demo board and would like to communicate with it directly over i2c so that I have something that works before troubleshooting my board. 

If you got it working, could you email/post your code?

Thanks!
Brian

[manu]

Hi,
I cannot post the entire project but I can share the c code driver for dspic33. I will try to do this tomorrow.

[brianthechemist]

That's great.  Something for me to start from.  How hard do you think it will be for me to port it to Arduino? (usually C stuff goes pretty easily)

Brian