TPS65982: TPS65982 multiple configuration problems

WST

Part Number: TPS65982

I'm trying to save time with multiple configurations (each config download takes about 1 min in my system). So I was using GPIO0 & GPIO1 to load multiple configurations. Because of memory limitations the TPS65982 can only utilize 0x400 bytes for configurations (0x2800-0x2BFF) in the flash, although 0x2800-0x2FFF is available. Don't know why the other 0x400 can't be used.

I used version 2.15 of the ApplCustomization tool to have 3 configurations sets, using virtual address of (DBG1)0, (DBG2)0, 1 (93.1kOhm); 0,0,2 (156k) and 0,0,3 (220k). I then change just the SinkCapabilities so that I ask for a single 5V PDO if GPIO0 or 1 fall, and a 5V/12V 2 PDO set if GPIO0 rises, and a 5V/20V PDO set if GPIO1 rises. This uses up 0x3F0 of the 0x400 space, so I can't have 4 config sets.

On the Misc config page I set the App Config Group1 settings as GPIO low transition to 0x1, and the GPIO high transition to 0x2. I set the App Config Group2 settings as GPIO low transition to 0x1 and GPIO high transition to 0x3. I set the Command channel to CMD3 in both App Configs. Then I set the 4CC Commands for both the rising and falling edges to 'ANeg'. I populated all 4 slots in each App Config with 'ANeg' to see if it would fix my problem.

Finally, under the GPIO Event Map register I set GPIO0 to 'Load App Config Set 1' as the mapped event, and GPIO1 to Load App Config Set 2.

I saved both the project and the binary files to low/all and then downloaded that to my board with a TPS65982 IC on it. I then connected to a TP65982 EVM board with the switches set to 0110 (6) so that it would advertised source capabilities of 5V, 12V, and 20V and powered up that board. I have a PD analyzer looking at the CC lines.

RESULTS:
When I toggle GPIO0, it switches between a 5V and 12V contract as it loads the different config and then sends the Aneg command. I see the GPIO0 switching as I probe and I see a trace on the analyzer that shows the request and the PSRDY as the EVM board switches between 5V and 12V.
BUT... If I try the same thing with GPIO1 it doesn't work. I probe the ball and see the GPIO1 line toggle high and low. I also use an Aardvark and the Host Interface Utility and read the Sink Capabilites register (0x33) toggle between one PDO of 5V and 2 PDOs of 5V and 20V. However, I don't see the PD traffic and the EVM board doesn't change the lights. I can using the HIT to send a 'ANeg' command after I toggle the GPIO1and then I see the PD traffic and it works. So for some reason, switching GPIO1 doesn't send the command, even though I see the configuration change?!? I have to manually send the command myself using the HIT. GPIO0 works fine and doesn't have this problem.

I changed the command channel on the AppConfigGroup2 (GPIO1) to CMD1 instead of CMD3 but this didn't help, I still don't see any PD traffic.

Is there a timing issue with the command channel? Do you see anything I have set up incorrectly in my programming? And why is only 0x400/0x800 of the flash part used for config?

over 8 years ago

0 Praneet Kumar over 8 years ago

TI__Genius 16230 points

Your settings seem correct, but I'd want to test/review your configuration in detail - Can you please share the configuration-file (*.pjt)??

-/Praneet

0 WST over 8 years ago in reply to Praneet Kumar

Intellectual 965 points

I would, but I don't know how to send it to you. I'll keep looking for a way...

0 Antenna_Head over 8 years ago in reply to WST

TI__Genius 12205 points

I will forward to Praneet.

0 Praneet Kumar over 8 years ago in reply to Antenna_Head

TI__Genius 16230 points

Warren, I'm not able to load the project that you shared - Which version of the tool have you been using?

-/Praneet

0 WST over 8 years ago in reply to Praneet Kumar

Intellectual 965 points

I upgraded to 2.15, thinking that the reason I was having problems was because of an older version. So I'm using 2.15 now.

0 WST over 8 years ago in reply to WST

Intellectual 965 points

I verified that I have the same problem using 2.12. I had to start from another 2.12 image, but made a very similar image with 3 config sets. I have the same problem, GPIO0 will switch and send the ANEG command, but GPIO1 will not send the ANEG command.
I found there are other differences between 2.12 and 2.15. The 2.15 image with 3 config sets is 0x3F0 in size (out of 0x400) and the 2.12 image is 0x3DC in size. So, if it continues to grow with each new revision, this method of switching will be limited since 3 config sets may no longer fit.
I will continue to experiment with switching the GPIO lines, but I'm not sure this is a viable way to load new configurations since it is somewhat limited.

0 WST over 8 years ago in reply to WST

Intellectual 965 points

I have tried everything I could think of. I have 3 GPIOs coming to the TPS65982, to GPIO0, 1 & 2. So I tried switching which GPIOs are used. What I have determined is that it only runs the 'GPIO High 4CC Command' or 'GPIO Low 4CC Command' in the App Config Group settings on the lowest GPIO, not the 2nd. I have ANEG set for the Command in each case. If I set up in the GPIO Event Map as:
GPIO0 = Load App Config Set1
GPIO1 = Load App Config Set 2
then when GPIO0 goes high, it loads the High Transition config and sends the ANEG command, if I transition it low, it loads the Low Transition config and sends the ANEG command.
But if I toggle GPIO1, the configs are loaded but the ANEG command ISN'T sent. If I read the Sink Cap register I see it change with no problem. I know the ANEG command isn't being sent since I am triggering on the PD traffic.
If I use GPIO0 and GPIO2, then only the GPIO0 switching will send the ANEG command.
If I use GPIO1 and GPIO2 (GPIO0 is set to DISABLED), then only the GPIO1 switching will send the ANEG command.
In all cases the configs change, but the commands aren't sent for the higher GPIO.
I also tried to move the config selections so that the App config group 1 was switching between 1 & 3, and the group 2 was switching between 1 & 2. It doesn't matter. Whichever config group is assigned to the lowest GPIO is the one that gets the command sent, no matter which tabs are assigned.
So, with 2.12 and 2.15 configs, it seems like I can only expect one GPIO to send the commands automatically.

I can get around the problem by sending the command separately AFTER the GPIOs switch since the configs change, but again, the commands aren't sent by anything but the lowest GPIO.
I also tried different commands for the two GPIOs, but this didn't help, the 2nd GPIO doesn't send any commands, even if they are different than the first.

0 WST over 8 years ago in reply to WST

Intellectual 965 points

Well, this is disappointing. I thought that I had remembered this working earlier, so I went back to a version I created with 2.10 software. I changed all of the registers to match the projects for 2.12 and 2.15. And then I downloaded this to my board. Well, it works. I can now change either GPIO and I see the ANEG happen. GPIO0 high -> 12V from the EVM board; low, back to 5V. GPIO1 high -> 20V from the EVM board; low, back to 5V.
So, something is wrong with the 2.12 & 2.15 software or I have misunderstood all of this. I'll just use my 2.10 created file for now, even though the 2.10 software has other problems that make it harder to use.
I will send on the .pjt file that was created by the 2.10 software.

0 Praneet Kumar over 8 years ago in reply to WST

TI__Genius 16230 points

Warren, I see the problem you mentioned on tool v2.12 - We'll investigate the issue, and keep you posted on the progress.

Thanks & Regards,
Praneet

0 Steve Preissig over 8 years ago in reply to Praneet Kumar

TI__Expert 5330 points

Hello Warren. This issue is being caused by an uninitialized section of register in the configuration tool. The firmware is treating the fields 'Command Channel to use for Command (not Task) Slot' and 'Command Channel to use for Command or Task Slot' as 8-bit values, but the config tool is treating them as 2-bit values and leaving the upper six bits uninitialized.

This will be fixed in the next release of the configuration tool templates. Also, the firmware will be updated to mask off the upper six bits. Only one of the two changes is required to fix the issue, but both will be applied for greater reliability.

There is a workaround for the issue and a fix. Warren -- I will apply the fix to the project file that you sent in to use and return it to you. I will post the workaround and the fix for others who run into the same issue

0 Steve Preissig over 8 years ago in reply to Steve Preissig

TI__Expert 5330 points

WORKAROUND (note only the workaround or the fix needs to be applied, it is not necessary to do both.) :
--------------------------

The workaround to this issue in current tool/project is to go into the raw view, locate register 0x5E, and manually zero it out by writing '0x0' into the raw value of the register. This will zero out the uniinitialized sections from the register.

The user will then need to go to the field view of the register (labelled as 'Miscellaneous Configuration' in the left pane) and manually re-enter each field. Note that command/task slots will now show as "Unknown (0x0).' It is recommended that the user replace each of these with '!CMD' from the pulldown list. This is the correct way to signal the firmware that there is no command in this slot. '0x0' will produce the same effect as it will be submitted but then rejected as an unrecognized command, but it is preferred to use '!CMD'

Once these changes have been made, the project should be saved and upon re-flashing the system with the new settings the issue should be removed. Please note that it is possible for the uninitialized fields to later become corrupted, for instance if an "import settings from project" or "import settings from device" operation is used, so this workaround is not a permanent fix. The permanent fix will also be posted but is more involved.

0 Steve Preissig over 8 years ago

TI__Expert 5330 points

FIX (Note that only the woraround or the fix needs to be applied, it is not necessary to do both.):

The next release of the configuration tool (any verison later than v3.05) will have updated templates that fix this issue. In order to fix the issue with a fixed config tool release, please start a new project with any template from the new tool that is applicable to the device used and then use the "Project-->Import Settings from Project" to import the settings from the previous project into the new project. (Note that just opening an old project in the new tool will not fix the issue. Projects are designed to behave the same across tool versions, so only updating to the latest template will fix the issue.)

In order to fix a .pjt file generated from a current configuration tool (which will then make this single project work correctly in any version of the tool), the following lines need to be added into the .pjt file. It is recommended to use a python editor as the .pjt files are implented as python modules. It is possible to edit using a standard text editor, but if a standard text editor is used, all indentations must be implemented with spaces (not tabs) and care must be taken to align the indentations exactly.

To repair a current project, please locate the following code segment in the project:

cmdOnlyChannel = register_class.cListDMTerminator(self.register,
{'name' : 'Command Channel to use for Command (not Task) Slot',
'offset' : 16,
'bit length' : 2 })

cmdOnlyChannel.setMaxValue(2)
cmdOnlyChannel.setReportList(['CMD1 (0x08)', 'CMD2 (0x09)', 'CMD3 (0x1E)'])

self.addChild(cmdOnlyChannel)

This code segment should remain unchanged, but directly below, please add the following code:

reserved = register_class.cForceSetDMTerminator( self.register, { 'name' : 'Reserved',
'offset' : 18,
'bit length' : 6,
'force value' : int(0),
'force display' : 'Reserved, Set 0' })

self.addChild(reserved)
reserved.setFromInt(0)
reserved.hide()

Then locate the next code segment (should be the next code in the project)

cmdTaskChannel = register_class.cListDMTerminator(self.register,
{'name' : 'Command Channel to use for Command or Task Slot',
'offset' : 24,
'bit length' : 2 })

cmdTaskChannel.setMaxValue(2)
cmdTaskChannel.setReportList(['CMD1 (0x08)', 'CMD2 (0x09)', 'CMD3 (0x1E)'])

self.addChild(cmdTaskChannel)

Again, this code segment is unchanged, but directly below it, please add the following. Note that this is slightly different than the code added above because it has a different offset.

reserved = register_class.cForceSetDMTerminator( self.register, { 'name' : 'Reserved',
'offset' : 26,
'bit length' : 6,
'force value' : int(0),
'force display' : 'Reserved, Set 0' })

self.addChild(reserved)
reserved.setFromInt(0)
reserved.hide()

0 WST over 8 years ago in reply to Steve Preissig

Intellectual 965 points

I finally got back to this to create an image that used 2 GPIO lines and was based on 3.05 software. I started from scratch, and it still had the problem of not recognizing the 2nd GPIO. I then cleared register 0x53 and then updated all of the miscellaneous configuration fields, and used !CMD. When I use this 'corrected' image it works and I can toggle the first GPIO on my board and see it switch between 5V and 12V (w/ the EVM setting = 6) and then switch the 2nd GPIO and see the EVM switch between 5V and 20V.
Thanks for the answer; it is still needed with version 3.05 of the configuration tool.

Interface

Interface forum

TPS65982: TPS65982 multiple configuration problems