AnsweredAssumed Answered

Register read problems with ADE7763 (Solved)

Question asked by fllfreak on Feb 9, 2012

I am posting to leave some breadcrumbs for other people.


I am using an ADE7763 for a home energy monitoring project. I picked this chip because it provided me with Irms and Vrms. The other functionality (power, energy, waveform sampling, ...) was fun but less important. Another important aspect to this chip was its physical size in that I could solder it by hand!


Once I got the chip, it was very easy to solder it to a SMT to DIP adapter and get it up and running on a breadboard. Just a few decoupling caps, the crystal and its load caps, and a pullup on the interrupt lines were the only support parts it needed. For the initial phase I elected to skip the anti-aliasing filter on the two ADC inputs. I used a CT for the current sensor and a voltage divider after an isolation transformer for the voltage sensor. The ADE7763 is connected at this time to an Arduino simply for the ease of interfacing. My final design calls for an MSP430 as the host for each of thirty plus sensor nodes.


I implemented the SPI interface on the Arduino using a simple bit-bang approach using digitalRead and digitalWrite routines and had luck reading and writing registers. I then converted the digitalReadWrite routines to direct register mapping to improve the speed such that I could respond in a timely manner to interrupts. Sometime after this I noticed that when reading the VRMS and IRMS registers, the content returned would be incorrect. It appeared as if the registers were reversed. That is I would get an indication of current from the VRMS register and vs-versa.


Analog informed me (kindly) that it was extremely unlikely that the problem was chip or document related and that I should look at the SPI interface. This I did and over the course of several evenings (this is a hobbyist project) checked that I was not violating any of the setup times for data and clock lines. But eventually (via several detours) I realized that reads were often giving me the contents of the address I had read previously. This lead me to realize that I was violating the "command byte to first read byte" (t9) parameter. I was not providing the specified 4usec after telling the chip what address to read before reading it. Hence I was getting the contents of the previous address that had been latched. Adding the correct delay solved the issue.


More information on this project can be found at


-Skye Sweeney