I use J2 to connect to an external PCB board, which can read AD7147-1 normallyBut after changing to AD7147P-1Execute CDC Converter and read greph, it shows **USB communication failed**
AD7147-1 => AD7147ACPZ-1500RL7AD7147P-1 => AD7147PACPZ-1500PL7
1. Are AD7147-1 and AD7147P-1 pin to pin?2. Is the communication interface of AD7147P-1 I2C?
PC link to EVB
Open EVAL-AD7147 Software
=>CDC Converter=>Read Graph
AD7147-1 and AD7147P-1 are pin-to-pin complaint and both have I2C interfaces.
Please provide more details.
1. Have you replaced the parts on the same board?
2. Did you check whether the new part has been soldered properly without any shorts or opens on any pads?
3. Is the new part taking adequate current on the device supply after power-up?
AD7147-1 and AD7147P-1 are both pin-to-pin complaints, and both have an I2C interface.
1. Have you replaced the parts on the same board?Replace two AD7147Ps without modifying other parts
2. Have you checked whether the new parts are soldered correctly, whether there are no short circuits or open pads?Yes, I check every pin with a magnifying glass
3. After power on, does the new component get enough current on the equipment power supply?Yes, I use EVB's Vdrive to provide 3.3V
Excuse me, is there any update on this issue?
The '-1' and 'P-1' versions have the same pin-outs and both are I2C parts.
The only thing I can think of (if it's not a soldering issue) is if the Device ID register contents are different (i.e. the Device ID/revision number may be different). I believe the GUI reads the Device ID reg and if it doesn't get back the value it expects then it gives the USB error. Can you 'tap into' the I2C lines and read that register directly with some I2C reader (this would also tell you if the part is 'alive'? I did a quick search on our depository and unfortunately because the GUI is very old, it doesn't look like we have the source code for that GUI if the Device ID/revision is different.