UCD3138A: PMIC is not responding

It's hard to say from the information you give.  What tool are you using, or what specific commands are you writing to do the checksum verification.

Normally the boot flash should look at the 32K checksum and if it's not valid, clear the 2K checksum.  If it doesn't do that, you still need some way in the 2K boot flash area to clear the 2K checksum to prevent bricking anyway.  

How is your 2K boot structured.  You need to have everything in the 2K to be able to verify the 32K checksum and to clear the 2K checksum.

If you don't have that, you can experience lockups like this.  

Also, you need to calculate the checksum independently from the device and compare the result to what the device calculates.  This is a way to make sure that the code has downloaded correctly.  If there is a problem with the code download, and you just use the checksum calculated by the device, you have just locked up a corrupted code.  

I'm using a C# program and am writing a series of 16 byte words to PMIC memory through a PMBus connection.

I don't write the 2k checksum until my code verifies the 2k and 32k checksums. (I take the fact that I don't write my checksum beforehand into account in both my independent checksum calculations and the PMIC checksum calculations.) My code independently verifies the 2k and 32k checksum from the hex file I'm programming from and then, after programming the PMIC, compares these to the PMIC calculated checksums. If these are the same, I then write the 2k checksum.  If they are not the same, I don't write the 2k checksum and the program aborts. So the PMIC should remain in ROM mode. But it seemingly doesn't since I can no longer communicate with the PMIC in ROM mode or programming flash mode.

Is it possible that I've written the code to memory correctly, verified the correct checksums, wrote the correct 2k checksum and then accidentally wrote corrupted bytes somewhere thereby corrupting the program?

Could some power loss or other hardware issue during programming cause the PMIC to lockup?

What could cause the PMIC to lockup besides the checksum being correct and the code is corrupted?

To help debug, I encourage you to make the bootflash work the way I suggest.

It's possible that your problem is writing 16 byte words.  If your bootflash code is running right up to the checksum, or if you are writing anything but FFs to the bytes other than the highest 4 in that 16 byte block when you write the checksum, you could have a problem.  It's better to write the checksum word with a single word write, rather than all 16 bytes.   If you are writing the 16 bytes for the checksum starting with the checksum address, then you're overwriting some of the rest of the 32K  

Since you say that you are writing a correct checksum and verifying that the device returns the checksum you expect, I'd expect that somehow the last 30K is getting corrupted somehow, which could be caused by power loss or other hardware issue.  If the written checksum, or the 2K code is corrupted, and the 32K checksum is not valid, then it should stay in ROM mode.  I assume it's getting stuck in program mode?

If so, under the conditions you describe, it is probably going through the boot flash and then jumping to the program flash area.  The program flash area probably has some kind of corruption that causes an abort or other fault, which resets the UCD.  The process repeats over and over, because the ROM will see the valid checksum and then jump to the boot flash again.  

This is why we recommend that the 2K boot flash area be able to detect corruption in the 30K area, and clear the 2K checksum.  Otherwise potential errors and corruption of the 30K area can cause this kind of lockup.  They can happen not only in programming, but also in testing and in the field.

Of course, you could also have a bug in your code.  I know I often try to blame the device, and it turns out to be a bug of my very own.  

I think I found my issue. Suppose I successfully wrote to the PMIC, successfully entered into programming flash mode with the PMIC responding properly. Then, suppose I forgot to erase the UUT, rewrote the exact same data to the PMIC memory. Is the data written more likely to be corrupted?

If you write the exact same data only twice, you should be safe.  The program flash actually permits double writes.  That's how we clear the checksum is by writing to it a second time.  You should be safe there.  I'm not sure about the data flash, though, becuase it has error correction.

If you write data with any differences, you will have a problem, but you should get a checksum change.  This is because flash erase makes the flash all FFs.  Once you write a zero anywhere, you can't put it back to a 1 without another erase.  You can keep changing ones to zeroes, however.  

I should try checking the data flash. Is there a way to look at the device's memory or erase the checksum if it locks up? I don't have a jtag connection to this chip. Would incorrect data writes cause the PMIC to lock?

generally if the PMBus is not communicating, and you don't enable JTAG, no, there is not a way to communicate with it.  Once in a great while, the data flash causes the device to lock up, but I've never seen it prevent PMBus communication.  But there's always a first time.  If nothing else, I'd suggest for debugging purposes that you at least have a hardware backdoor on the boot flash.  put an I/O line check in there so that if an I/O line is at a certain state, the 2K will clear the 2K checksum.  bear in mind that all the checksum clearing code and the bootflash startup have to be in the first 2K themselves.