Other Parts Discussed in Thread: BQ25703, TPS65987,
Team,
I have a customer desigining around several TI devices, and their current issue revolves around the TPS65987 and BQ25703.
They began development by getting the two dev kits: one for the TPS65987 and one for the BQ25703. They were able to get the TPS configured as they wanted it with these devices. With their battery connected to the BQ dev kit, they were able to get the TPS to sink and source with the charge levels we needed.
In parallel, they developed an alpha prototype PCB of one of the boards in their device to implement and test the PD circuits along with interfacing to the SOM they are using from Phytec, and the LCD display.
With the above board, their SOM can now communicate with the on-board TPS65987. They have taken the working binary and have been able to program up the attached (to the TPS65987) SPI flash with the binary file we developed using the above development kits. They can read back (through the TPS65987) the flash and it matches the binary. They can boot the TPS on their board, and according to the TPS status registers, it sees the flash and boots from zone 0. It does not show any errors in the other status flags. It also reports the correct base bin version that they used to generate the full bin so they know that something has loaded (default TPS base bin version is older and we see it if we do not boot off flash)
The problem they are encountering is that none of the configuration registers are setting up correctly. For example, they set 0x64 with the i2c address for the BQ 25703. On the eval board, when they query the register in debug it reports the correct address. However, when they query their TPS chip on the alpha board it reports all 0x00 for all the bytes in the register. That said, a lot of the registers seem to be set to 0x00. Looking at the I2C bus to the BQ part with our scope: they do see expected and correct traffic on the eval board; but there is no traffic on our alpha board (which would make sense since according to 0x64 nothing is set there).
They have changed individual bytes in the bin file in order to force CRC and other errors in the flash to verify its behavior (loading from zone 1 if zone 0 has problems, etc…). They are at a loss. It almost seems like the bin file is getting loaded but then something is causing the default ROM configs to be pushed into the registers after the bin is loaded. Could we get your thoughts on this?
Any assistance or advice you can provide would be greatly appreciated. This aspect of the design is really starting to fall into the critical path and we are in the process of working on the beta version of this board with prototypes to deliver to customers in Q2.
