MCP39F521 i2c power monitor

[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.