CCS/UCD3138PFCEVM-026: PWR026_PFC

Especially with PFC, that's a long list.  It's pretty easy to hit the chip with high voltages, which will stop it from working by blowing things up inside it. it's also pretty easy to make a program change and lock it up with the checksum, so that you can't reprogram it.  In that case, it should still be able to run the program you downloaded into it.  For the first case, a good indication is the chip power consumption.  For the second case, if it's still running, and communicating, but you can't download code, then its locked with the checksum.  We can give some recommendations to avoid that.

Of course, if you change the program, and then write the checksum without checking the checksum erase functions, you could have something like an infinite loop, or an interrupt lockup, which would make the program not work, and lockup the checksum

These are the most likely candidates.

Those are mostly standard problems with programming, not specific to the UCD.  So there are pretty standard ways to solve them.  For checksum lockup, don't program the checksum.  download the program without checksum, and then try to command it to return to ROM mode.  If it doesn't go to ROM mode, it probably didn't reset, which doesn't mean it may not have cleared the checksum.  However if it does reset, that doesn't mean it also cleared the checksum.

To check the checksum clear, click on the checksum tab on the Device GUI, and click on validate.  If the checksum area shows all zeroes, the clear worked.  If it shows all FFs, the checksum clear didn't work, so you need to fix it.  There is lots of advice on E2E already for how to fix the checksum issues.  

For the other issues, also don't set the checksum, since a infinite loop  or interrupt lockup will also prevent checksum clear.  I like to use an unused I/O line to see where the program is getting stuck.  Toggle it at various points in the program until you find where it doesn't get to.  You can kind of do a binary search, first put the toggle half way in to the program, and then go up or down by a quarter depending on where it gets to.   Or just look at your code.

The default PFC has a checksum backdoor, I think it's on the Fault 1 pin - look at the beginning of the main function.  If you've still got that in there, and the basic checksum clear is still working, you can pull the relevant fault pin to the correct state and reset the device.  That should clear the checksum, even if the program doesn't make it very far.  

If you look at the code, you will find 3 defines of identical setpoint defaults:

#elif(PFC_TYPE == SINGLE_PHASE)//single phase PFC
// vout_command, vout_ov_limit, frequency
#define PFC_SETPOINT_DEFAULT {390, 435, 100}

The 390 is the vout command.  If you change this number, you will change the default vout command.  There are 3 #defines, one for each PFC topology supported.  Make sure you change the correct one.  

Next time, please start a new forum question so that searching for answers will work better.