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

[manu]

Here is a link to the Microchip forum for the serial version of the chip (MCP39F511, I think) for an Arduino Mega:
https://encrypted.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwiZzvuA8cPSAhWLOhQKHcPdDGIQFggbMAA&url=http%3A%2F%2Fwww.microchip.com%2Fforums%2Fdownload.axd%3Ffile%3D1%3B896733&usg=AFQjCNG22iv12MoUPFrl6tB_uJHjZ7eBVA&sig2=xs8icn7NT7c_Kw8STWaYvw&cad=rja

This page may also be userful:
https://sites.google.com/site/tgmaxx/mcp39f511-power-monitoring

My attached files are intended to use 2 MCP39F521's. This driver may not be free of bug, so take it with a grain of salt. It uses I2C1, you'll have to modify the i2c layer to make it work on Arduino. It probably need a half a day or so.

Good luck,

[brianthechemist]

Thanks! do you think the serial version has any advantages over the i2c version? (I could use either one but have been working with the i2c)

[manu]

I choosed the i2c because I needed 2 energy monitors and I would have run out of uarts in this very specific case.
If you need only one MCP39F5xx, it is probably easier to have the uart version as the code already exists, but it's not a big deal to write your own code based on the driver from my previous message (basically, replace the i2c i/o with the Wire library from arduino).

[brianthechemist]

Excellent. 

Though more painful than I thought it would be, I finally got it working.  One issue though:  What is this code?? 

Code: [Select]

TypPowMonOutReg batteryPowMon; // export to main
TypPowMonOutReg inverterPowMon; // export to main

TypCalReg batteryCalibration; // export to main
TypCalReg inverterCalibration; // export to main

TypConfReg batteryConfiguration; // export to main
TypConfReg inverterConfiguration; // export to main

TypControlReg batteryControl; // export to main
TypControlReg inverterControl; // export to main

I'm not sure what you mean "export to main".  I can't seem to use anything from those structs in the main code without moving the declaration (but then it is out of scope for the cpp file.  (I'm not quite sure how to handle typedefs...)

Thanks!

[manu]

Hello,

This code is from a prototype of mine which supports 2 MCP39F521 (meant to monitor a battery and an inverter).
I cannot publish the whole code project so you only have a partial driver which needs some work...

There are 4 structures that represents the internal registers of the MCP39F521: TypPowMonOutReg, TypCalReg, TypConfReg, TypControlReg (cf. datasheet).
You have to declare one struct per internal registers and per MCP39F521.
For exemple in main.c, as a global variables:

Code: [Select]

#include "mcp39f521.h"
TypPowMonOutReg batteryPowMon;
TypCalReg batteryCalibration;
TypConfReg batteryConfiguration;
TypControlReg batteryControl;

int main(void)
{
...
}
You'll also have to modify the i2c driver for your micro...

[brianthechemist]

Yes, I understand that part.  I got everything i2c ported over to Arduino (elegant use of the Union, by the way!).  The problem I am having is with the header file.  This probably comes from my poor understanding of structs and prototypes.

For some reason, the struct is not being seen as a global variable with the declaration in the .cpp file (I moved it to C++ as well).  Maybe that is the problem.

[manu]

I'm probably not the best guy to give you advices in C++, but you could use the structs in a mcp39f521 class as internal variables. This probably would resolve your definition problem: just instantiate a class and the structs will be created with the instantiation.
If structs are too difficult to handle you can break them into variables corresponding to mcp39f registers.

[pf22]

Hi All,
I have the same problem with I2C on the MCP39F521.
I verified all the pins according to the demoboard design.
I have always a NACK on Writing address (0x74).
I have a RTC on the same bus which works well.

It seems that the chip doesn't answer, but why...
Have anybody has an idea ?

Best regards

[manu]

What microcontroller are you using ? Check if your i2c lib shifts the address (0x74 becomes 0xE8 with the R/_W bit).

[PiotrO]

@pf22
Are you using external Xtal or build-in?
Mine all 5pcs of mcp39f521 aren't working with internal xtal - no matter what I'm trying.
I spent literally week hunting this issue.
Once i added external 4Mhz xtal + 2x 22p - all started to work beautifully.

This is very bad about microchip - and i will avoid this company since this non-pleasant experience....   

[TJ232]

Same here, was not able at all to reliable use internal Xtal.
Might be a silicon bug or something.
Did anybody made it working properly in that way?

[pf22]

I'm using a cortex STM32F030RCT6.
In fact, it works now. The issue was resolved by adding 2K pullups on the bus.
I'm working with the builtin oscillator.
Thanks for your answer

[TJ232]

Can you please try if is working properly with 4k7? Thanks.

[elliottke]

I am also having trouble talking to the MCP39f521 via I2C. I have an I2C connection between and ST Nucleo board and the MCP39f521 demo board. I have the issue where I get an ACK on the address, but a NAK on the control byte (0xA5). See attached picture. I believe common A/B are tied together on the demo board, so I don't think it's that. Any other ideas?

Thanks

[manu]

Strange because the first byte is ACKed, so it should be that the chip is registered on the i2c bus (?).
Did you connect the microcontroller on the mcp39f or the isolated side of the i2c bus (there is an isolation barrier U6 = ISO1541). Try the MPU_SDA and MPU_SCL pins.
You must power the demo board with an external 9V power supply too.

[elliottke]

Manu--thanks so much for the quick reply. I'm viewing the trace from the isolated side of the i2c bus and powered via 9V wall wart power supply. I got one step further by reducing the clock speed to 200kHz. I now get ACKs for all the bytes I'm sending the in the write request (A5, 08, 41, 00, 02, 4E, 1C, 5A), which is exactly the same as one of the packets sent by Microchip's GUI application. This packet sets up the address pointer to 0x02 (status) and requests 28 bytes.

However, I'm struggling with the read part. In the attached file, bad_read_200khz, you can see the trace that shows the response. We're expecting 0x06 (ACK), but we get 0x83 (?? anyone know what the possible response codes are? I don't know if it's garbage or a meaningful code)

Since that didn't work, I tried at 100kHz. Even weirder behavior, see bad_read_100khz.png. We setup to read, then immediately setup to write. Garbage from there. I'm inclined to point the finger at the clock again because it looks quite different from the GUI read (gui_read.png attached). I'm certainly not intentionally sending a write, though it's possible there's a bug.

any ideas?

[krho]

Looking at the picture for which you are saying that it succeeds it seems that the MCP is using clock stretching.

[manu]

Looking at the picture for which you are saying that it succeeds it seems that the MCP is using clock stretching.

Effectively:
Try to add a small delay (a few ms) between each byte read.

[inky]

I am having the same issue, the MCP39F521 takes and holds SCL low after the ninth clock cycle with its address.
 - I have a 4MHz external clock going into the device on pin 6
 - I have used a circuit very similar to the data sheet and the dev board
 - I have used both 4k7 and 2k0 with no visible difference
 - I2C frequency about 87kHz (otherwise unreliable - as determined by another engineer using the dev board)

Using a raspberryPi to communicate to the MCP39F521, there is a mux to select the MCP39F521 devices and I can program that correctly, so the I2C is working OK.

Does anyone have any suggestions?

Thanks in advance

[manu]

Hi,
The 4MHz clock must be +/-2% (I only tried with the internal oscillator).
The datasheet specifies also that OSCO capacitance should be 15pFmax.
Maybe if your wiring between the rpi and the mcp39f is too long, you're having signal integrity issues. Please attach a scope screenshot...

[inky]

The actual set-up is using a PCA9615 SCL/SDA differential line driver on the pi, over a cable (about 20cm) to PCB with another PCA9615, into a PCA9544 (1 to 4 MUX) and then to 4 channels with an MCP39F521. These are separate channels as there is an I2C OLED with an address that can not be changed, on each channel. Power for both the Pi and the MCP39F521 PCB are from the same mains supply

Now, I can talk to the mux without issues, I don't have the OLED on there as they have not arrived yet, so can't test that them. Attached are a couple of pics, the second zoomed in on the last transaction, where SCL is kept low by the MCP39f521

[ngjohnson]

Hello EE's

I'm using the MCP39F521 on a project and have the ACM0686 Dev Kit hooked up to a Particle Argon, and I'm having many strange I2C issues, might be Partciel might be Microchip, and I'm still stuck. I'm able to get the same code working on an Arduino 34u4 feather, but when I connect it to particle, everything falls apart!

I've posted the issue in the Particle community https://community.particle.io/t/mcp32f521-library-port-to-particle/56952/34 and after reading through your ideas and solution wanted to see if you see anything I should try to get my code working. I can get data from an LM75 temp sensor without issue on the same I2C bus, so know the i2C bus is working as expected fro smaller data packages.

I have a simple setup with the Devkit connected directly to the Argon/Boron Gen 3 Particle device. It uses a nRF52840 MCU and its own customer HAL layer to allow wiring like code, similar to Arduino.


Current Development Setup

Right now, I can get the Write setup as expected, know the hardware works with another MCU, and confirm that the read command starts off correctly but don't receive the expected 0x06 back from the MCP39f521 sensor. At this point, I read 0xC1, not the correct response header, and then either all zeros of ones fro 32 bytes of data. 

If you look at my Particle community post, you can see logic captures and data back from the sensor and what the MCU is doing. Anouther strange thing is it won't work at 100MHz but seems to "Work" the i2C bus behaves and doesn't have missing ACK's.

I'm not sure what else to try besides messing with Particle's Hal layer, but that is slow and will defeat the entire purpose of using their platform. I'm going to take a scope capture tomorrow, but I don't think it has anything to do with capacitance on the wires because it does work with another MCU.

Any ideas would be lovely, and I'm not sure what else I can change or manipulate at this point to get data from the chip.

Best,
Nicholas

[manu]

Hello,
If it works with another mcu, I would blame the HAL i2c driver. Many implementations of i2c need to be tweeked because they are sometimes not written to be fully compliant with the i2c protocol (clock stretching, ...).
Try to write your own i2c code, it might help you.

[ngjohnson]

Thanks, working on writing my own i2c driver now. Do you know if you have to update any registers to run at 400kHz clock speed or does running at 400lHz from master automatically tell the MCP32f521 to send data that that rate?

[manu]

The MCP will work at 400kHz without any register update.