TPS65982: Over-writing TPS65982 internal 'appcode' in OTP memory, rather than using SPI flash memory or UART

Hello forum!

Q1. Okay. Thank you, Adam!

Q2. Okay. Thank you, Adam!

Q3. Okay. Thank you, Adam!

Q4. The data sheet reads "...The unique I2C address is based on the customer programmable OTP..." I do not understand this. Isn't customer reprogramming allowed to happen more than once? Why call customer programmable one-time programmable (OTP)? If the customer can re-program boot code and appcode repeatedly, then why is the data sheet referring to "one-time programmable" here? How many times can the customer program the OTP" to define the unique I2C address? Are not "customer programmable" and OTP" self-contradictory? I must be missing something here.

Best regards,

Michael

Hello,

I would not get hung up on the term OTP. This is in reference to the image put on the external flash that the PD controller will load each time. However, you can still read/write to the PD controller as many times as you want. However, any settings that you re-programmed will be erased after each power cycle, where it will then load the configuration from the external flash again.

Hi Adam,

I've been working with Michael to help understand and clarify his questions. The ultimate goal here is to understand the potential need for uploading something over SPI Flash once the product is released to the field, or if the updates and future proofing can be done in another manner.

Based on our discussions, we agree it is possible to operate standalone with the internal ROM without the use of the SPI Flash, correct? Once flashed properly, it will use the internal boot code from the SPI Flash binary image instead of the internal ROM. The major question stems from is there any need from the SPI Flash or can all these changes be made by controlling each individual I2C Register? Is there anything else done in the Configurator besides register manipulation that cannot be done otherwise?

Thanks,

Matt

Good afternoon Adam, 

Matt had kindly re-phrased my questions for the post that you replied to. I find your answers valuable, as it is important for me to understand and be able to explain to my management that it is possible that the base appcode is updated by TI over time and that may be reflected in the output of the configuration tool. 

Apart from the base code image appcode, are there differences in what can be configured by the configuration tool and the I2C interface? 

Does all configuration, via the configuration tool and the I2C port, amount to setting the state of the same set of configuration registers?

Is there any configuration that the configuration tool can do which can not be done via the I2C port?

I had read the data sheet, EVM manual, design guide, and the slvae21a.pdf app note, and will continue to refer to them. 

Best regards,

Michael

Hi Michael,

Here is another way to phrase the importance of the firmware base image. Our PD controllers such as the TPS65987D operate from a ROM and RAM architecture. The ROM is of course physically etched onto the silicon with the RAM being loaded externally from the SPI flash. As mentioned, over time issues are found that need to be resolved. There is no way to change the code of the ROM, so we copy the relevant portion of the code that needs to be fixed into the RAM, and whenever that specific function is called on, instead of pointing to the ROM it instead gets pointed to the new function in the RAM. The firmware base image includes all of these fixes and updated functions into the RAM.

There are also registers such as the sink/source capabilities that cannot be changed via I2C master control, but can only be set within the configuration.

Hope this helps. Let me know if you have any other questions.

Hi Adam,

Are the sink/source capabilities the sink/source capabilities of certain I/O, pins, or what sink/source capabilities are those?

Best regards,

Michael

Will the TPS65892 or TSP65987D ROM programming (state, data, bits) ever change over their mass-production lifetime? 

Regards, Michael

Hello Michael,

No, the internal ROM will not change over the production life of either device

Hello Adam,

Are there any other flash memories that are suitable? The TPS65987EVM BOM document SLVUBO9A specifies the Micronix MX25L8006 8Mb SPI serial flash. I have been seeking an alternative that is certain to function adequately identically, as Micronix is not an approved supplier at my employer. I see that the MX25L8006 includes additional unique features, such as an "additional 512 bit secured OTP for unique identifier", that I believe are not used in the TPS65987D application. I studied the memory maps in section 4.2 Flash Memory Organization in document SLVAE21A. Has TI considered hosting a FAQ page?

Regards,

Michael

Hello Adam,

Thank you!  I will use section 9.2.2.2.2.7 Thunderbolt Flash Options Table 21 "Flash Supported for Thunderbolt Systems" for my non-Thunderbolt Mode design.

Is it okay to use the Macronix MX25V8035FM2I rather than the TI-recommended Macronix MX25V8006FM2I? These are identical in function supposedly, but it turns out that even though Macronix has the '8006' on a year 2015 longevity list, Macronix is now recommending to replace the '8006' with the '8035' for new designs.

Cheers,

Michael

Hi Michael,

I'm sure it is fine, but I cannot comment on their recommendation or say with 100% certainty that it will be the same.

Hi Adam

Can you please direct me to the TPS65987D data sheet definition of the function of each of the GPIO pins? Where do users (customers) find this information? TPS65987D data sheet SLVSES1B –MAY 2018–REVISED JANUARY 2019

Best regards,

Michael