This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
We are having issues with the initial bring-up of new PCB assemblies with this device. We would like TI to review the hardware and software (EEPROM image) design to see if you see anything that might be a problem. We would also like to understand debug capabilities - how to use the SigGen Architect for debug and/or are other tools available? Do we do all of this through this forum? Or is there a different process for this kind of detailed technical assistance?
Thanks much,
Kevin
Hi Kevin,
Yes you can share schematics, register configurations, EEPROM files, etc. on this forum and my team and I can help support. We can help answer detailed debug questions here as well. Let me know if you have any concerns about sharing files or receiving support on public forum and I can share other options.
Best,
Lucas
Lucas:
Attached is a screenshot from the page of the schematic that shows the DS100BR111 ICs. It shows that we have two ICs sharing a single EEPROM. It also shows we originally had the I2C slave addresses strapped to 0xB0 & 0xB2; however, during initial board bring-up we discovered these addresses conflict with another device on the I2C Bus (the information available for the other device was misleading in it's I2C slave bus address usage). Since we could not physically change the I2C slave address of the other device on the initial boards, we modified the I2C slave address of the DS100BR111 ICs - changed them to 0xC8 & 0xCA as shown in the red-lined mark-ups.
You will also notice we have the boards assembled with a pull-up on the ENSB pin to allow initial programming of the EEPROM per https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1440603/ds100br111-ds100br111/5529246#5529246. The pull-up resistors are removed after the EEPROMs are programmed. Note that we did try a board with the pull-up removed and a blank EEPROM and it did render the bus useless as explained in the answer to the older forum question. This verified that this process was required for these initial boards. We plan on addressing this on the next release of the boards.
Also attached is the EEPROM image we used for the final configuration (0xC8 & 0xCA slave addresses). An I2C bus monitor shows that it appears that the ICs are properly reading the EEPROM data during power-up. The image was created based on configuring the ICs for 10G-KR mode and with Vod_Level=1, DE_level=0 and EQ_level=4 which is per our SI analysis. I also included an Excel file we used to help determine the EEPROM image. Note that I tried using the SigGen Architect software to create a .hex image file, but the image seemed to be missing a required byte (see Excel file).
Can you please review this information and provide feedback? We are also looking for further guidance on the SigGen Architect usage for debug and/or if there are other debug tools available.
Thanks much,
Kevin
Hi Kevin,
Thank you for your detailed explanation.
Here is my feedback on your schematic. Note that you are still responsible for ensuring your design will work as intended.
I reviewed your EEPROM hex file and noticed 3 bytes are used for address headers, however the base header bit 5=0 for EEPROM <= 256 bytes. This bit needs to be asserted to use 3 byte address headers, and can be asserted regardless of actual EEPROM image size. Therefore I recommend changing byte 0x00=0x41 to 0x00=0x61.
I see that the following settings are programmed with this EEPROM configuration. If all of these settings are correct, then I see no further issues with the EEPROM hex file.
The DS100BR111 device profile of SigCon Architect GUI is split into 3 different pages.
Let me know if you have any additional questions about SigCon Architect. This is the only tool we have available to assist with debug. You can additionally ask any debug questions on E2E forum and my colleagues or I will help support.
Best,
Lucas
Lucas:
Thanks much,
Kevin
Hi Kevin,
Thank you for pointing this out on the EEPROM image. That was my mistake, I now see that 2-byte address headers are used. I don't see any issues with your EEPROM hex file.
Regarding SigCon Architect:
Best,
Lucas
Lucas,
The issue turned out to be AC coupling - misunderstanding on where these were located in our partner's design. We were able to rework an assembly to add in caps in the inputs of one IC and the link came up.
Thanks for the help,
Kevin