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.

TPS65987D: TPS65987D custom board without external FLASH

Part Number: TPS65987D
Other Parts Discussed in Thread: TPS65987, , TPS65988, TIDA-050012, TPS65981, TPS65982

Hi,

We have  TPS65987 on the custom board, without external FLASH.

For more robust debugging, we decide to start whit USB-C-PD-DUO-EVM.

1.) I erase flash, so it wouldn't boot from SPI FLASH. I remove R243 and R241 on USB-C-PD-DUO-EVM and connect LunchPad on the connector. 

2.) I have I2C working. I can read 0x3 reg and I get back "APP ".

3.) I translate JSON file (basic project - configuration for source board), translate to C commands, length and payload. Sending on registers seems to be fine..

4.) TPS65987D do any action if I connect USB.

I saw conversations where you promised users documentation on how to install a patch on a device without external FLASH (over I2C).
I'm also interested in any guide, how to start, etc.
"TPS65987 and TPS65988 SPI Flash Firmware Update over I2C" doesn't seem to be a useful document for "no FLASH system", or it is?

Regards, Mare 

  • Good Morning Mare,

    I will look and see what documentation and steps I can provide you for this, and respond back by EOB, March 3rd.

    Kind regards,

    Conner Gillette

  • Hi Conner,

    After long research on TI E2E I found some mentioning SLVA972A. So I found this document “TPS65987 and TPS65988 SPI Less Host Programming Over I2C” (SLVA972A–May 2018–Revised April 2019). If newer version exist, please send to me.

    I go through the document and make progress step-by-stap.

    1.) In Application Customization Tool: Project->New->TPS65987DDH->TIDA-050012 Source Board, and open project.

    2.) in APP: Binary->Save Binary->Select “Low Region (minimal Header)”, save as “C array declaration (.c)
    3.) In Lunchpad code:

    3.1) Read mode register, return APP

    3.2) Send Cmd ‘PTCr’ whit:

        cmdTx[0] = 0b00000011;//AppConfigReset,DevicePatchReset
        cmdTx[1] = 0;
        cmdTx[2] = 0xBE;//DevicePatchResetKey
        cmdTx[3] = 0xEF;//AppConfigResetKey

    3.3) reading IntEvent1 register and waiting for ReadyForPatch flag. If not set in 5s then I call "GAID" Cmd and retry process from point 3.1.

    3.4) If ReadyForPatch bit is set, then Cmd PTCs whit "0b00000011" Data is sent. I check if response is 0.
    3.4.1) Just for debugging purposes, I read the mode register, and is "APP" why not "PACH"?
    3.5) Then I load patch "tps6598x_lowregion_i2c_array" made by 2.) step.
    3.5.1) At that point I check if Byte2 - TransferStatus is 0, if Byte3 - PatchLoadingState is different than 0 and 0x09(error). Should I check anything else as necessary?
    3.6) When all data are downloaded, then I send "PTCc" and check if Byte3 or Byte4 are equal 0.
    3.7) Then I send  "PTCq" and get in respond:

    [0]	unsigned char	0x00 '\x00' (Hex)	OK	
    [1]	unsigned char	0x00 '\x00' (Hex)	PatchReturnCode == 	Success
    [2]	unsigned char	0x0A '\x0a' (Hex)	PatchLoadingState == Patching Processes Completed Successfully
    [3]	unsigned char	0x00 '\x00' (Hex)	Reserved	
    [4]	unsigned char	0x40 '@' (Hex)	Size low == OK	
    [5]	unsigned char	0x34 '4' (Hex)	Size Hi == OK	
    [6]	unsigned char	0xC0 '\xc0' (Hex)	DevicePatchDataTransferred	
    [7]	unsigned char	0x2B '+' (Hex)	DevicePatchDataTransferred	
    [8]	unsigned char	0x80 '\x80' (Hex)	ApplicationConfigurationDataTransferred	
    [9]	unsigned char	0x04 '\x04' (Hex)	ApplicationConfigurationDataTransferred	
    [10]unsigned char	0x03 '\x03' (Hex)	DevicePatchState == Device Patch Running	
    [11]unsigned char	0x03 '\x03' (Hex)	DevicePatchSource == Device Patch Loaded from I2C
    [12]unsigned char	0x08 '\x08' (Hex)	ApplicationConfigurationPatchState == Application Configuration Patch Error	
    [13]unsigned char	0x03 '\x03' (Hex)	ApplicationConfigurationPatchSource	== Application Configuration Patch Loaded from I2C


    On Byte13 we have Application Configuration Patch Error. Any idea what is wrong? I load values generated from Application Customization Tool! I also see on the forum someone propose to use "Advanced Template" in Application Customization Tool for I2C patching patch .c array generation. Any idea why is that?

    3.8) I send Cmd Gaid and EVM seems to work! Now I'm confused...

    Also, I read between steps, a mode register, APP status is reported, and never PACH.

    Can you analyze my steps and propose improvements? 

    Regards, Mare




  • Good Morning Marko,

    The error is likely caused by which boot mode you are entering. I have attached the TPS65987D datasheet. Section 8.4.1, Table 8-5, lists the correct resistor divider configurations for ADCIN1 to enter device configuration mode "Infinite Wait", which will enter you into PATCH mode. You likely have a resistor divider configuration which is putting you into one of the other modes listed in Table 8-5. For more detail, you can see Table 1. BUSPOWERZ Configurations in the SLVA972A document you referenced.

    tps65987d_tps65987d_datasheet.pdf

    Kind regards,

    Conner Gillette

  • Thanks Conner for reply,

    We change the resistor to a ratio 0.32, so we boot in BP_ECWait_Internal.
    The state is PACH. That is ok, but after patching, the error in Byte 13 shows "Application Configuration Patch Error" ( 0x08).
    Do you have any info under what circumstances this error is raised?

    Thanks, Mare

  • I will research further and get back to you by tomorrow, EOB.

    Regards,

    Conner

  • Which firmware version are you using?

  • TPS65981_2_7_8 Application Customization Tool

    GUI Version : 6.1.3

    Date of release : March 28, 2022

    Supported Devices:

    TPS65981 : 1.12.11

    TPS65982 : 1.12.11

    TPS65986 : 1.12.11

    TPS65987DDH : F707.10.10

    TPS65988DH : F707.10.10

  • Hi Marko,

    Conner is currently out of office, but he will get back to you sometime this week. Thank you.

    Best Regards,

    Aya 

  • My apologies for the delay Marko. I've spoken with my colleague and discovered that you want to be in configuration BP_WaitFor3V3_Internal based on your setup. That should put you in the correct boot mode based on your setup and should resolve the error.

    Kind regards,

    Conner Gillette

  • Hi,

    unfortunately, our custom PCB does not allow this.
    The "SPI_POCI" pin is connected to GND since in "slvses1d" it is written that the pin must be connected to GND if it is not in use.

    So for our next PCB version, we can connect SPI_POCI to 3.3V.

    Regards, Mare

  • I see. As we've reached the natural conclusion of this thread, I am going to close it. Please feel free to open a new thread if you experience any issues with your updated PCB design.

    Regards,

    Conner