UCD3138A: How to start a project from 'LLCHBFirmware-1.2'

Xiaofeng, we have the UCD3138 LLC EVM board available here:

https://www.ti.com/tool/UCD3138ALLCEVM150#overview  It''s not very expensive, and it's what most people use to start learning about the UCD and 7138.  It's a complete power supply, including two 7138s.  And it's what the standard TI firmware is designed to operate with.  That way you don't have to build your own test hardware, which enables you to get started much more quickly.  And we strongly recommend that you use the same pinout for your eventual hardware design.  There are lots of configuration bits on the UCD, and if you just decide to use different DPWMs and filters than the EVM, it's easy to make a mistake changing the firmware, and sometimes difficult to find your mistake.  

If you really want to use the LLC firmware on the control card that you have, the best way is to disable all the fault detection.  That way the code will always go to the run state and the filter and DPWM will run.  Then you can either use the CPU sample technique from the labs, or set the high and low clamps on the filter output to control the LLC.  That way you can at least watch the LLC frequency vary.  Probably you can fake signals onto the various fault pins and reenable the firmware and test that.  But the idea of doing some kind of hardware simulation to test the 7138 seems very complicated.  I think that the EVM is the way to go.  

If you really want to disable the faults, there is a state machine in standard_interrupt.c.  

You can see that states in a case statement near the end of the file like this:

switch (supply_state)
{
case STATE_IDLE:
handle_idle_state();
break;
case STATE_CHECK_RAMP_UP:
handle_check_ramp_up();
break;
case STATE_HIGH_CURRENT_DURING_RAMP_UP:
handle_high_current_during_ramp_up();
break;
case STATE_BOUNCE_TO_RAMP_UP_AFTER_WAITING:
handle_bounce_to_ramp_up_after_waiting();
break;
case STATE_RAMP_UP:
handle_ramp_up_state();
break;
case STATE_RAMP_DOWN:
handle_ramp_down_state();
break;
case STATE_REGULATED:
handle_regulation_state();
break;
case STATE_VOUT_TRANSITION:
handle_vout_transition_state();
break;
case STATE_LIGHT_LOAD:
handle_light_load_state();
break;
case STATE_CPCC:
handle_cpcc_state();
break;
case STATE_HICCUP:
handle_hiccup_state();
break;
case STATE_FAULT:
handle_fault_state();
break;
}

You don't need to go to all the states, just the ones in the start up sequence.  

Most of the states will have something like this:

else if (PSON && ABOVE_VIN_ON_LIMIT )

You may just want to change the #defines for each to 1, so it will always thing that Vin is high and PSON is true.  

Then there will be checks like this in the code that check for specific exceptions for that level:

if (ramp_complete && ( adc_values.io_sense > pmbus_dcdc_config_translated[0].iout_oc_warn_limit))
{
supply_state=STATE_HIGH_CURRENT_DURING_RAMP_UP;

}

Comment those out.  

There's also handle_faults, which is called from the regulating state.  You will need to comment out the measurements there.  You will also need to find the code which enables the DPWM faults and their interrupts and comment it out.  

Hi, Ian

thank u so much for the answer.

We will consider of buying a EVM150.

But I think the software for only EVM149 is also needed, because we need to confirm the signals before connected to the circuit of our own.

So at first, I will try the way you have showed, to disable the faults.

while I have more questions about the details in your answer:

1. when you say 'You don't need to go to all the states, just the ones in the start up sequence.  '

    Would you please tell me which ones are the start up sequence?

2. when you say'

   Then there will be checks like this in the code that check for specific exceptions for that level:

     if (ramp_complete && ( adc_values.io_sense >pmbus_dcdc_config_translated[0].iout_oc_warn_limit))
     {
     supply_state=STATE_HIGH_CURRENT_DURING_RAMP_UP;

      }

      Comment those out.  '

     Woul you please tell me all the checks that need to be comment out?

   Maybe that very easy for the specialist like you, but you know I am not so familiar with this IC.

At last, I have another question for the hardware, as there is some code in the main.c as following:

//Check to see if FAULT2 is pulled high and FAULT0 is pulled low.
//If they are go to ROM.
if (MiscAnalogRegs.GLBIOREAD.bit.FAULT2_IO_READ && !MiscAnalogRegs.GLBIOREAD.bit.FAULT3_IO_READ)
{
pmbus_read_write_rom_mode(PMBUS_WRITE);
}

Does it means that I need to connect FAULT2 to hign and FAULT3 to GND?

thanks very much for your help!

with regards

Xiaofeng Wu

I think the states are:

STATE_IDLE

STATE_CHECK_RAMP_UP

STATE_RAMP_UP

STATE_REGULATED

If you get much more complicated than looking at the DPWM waveforms, and especially when you get to things like the UCD7138, you will really need to test on your hardware.  Since it is a feedback system, you will need feedback, which is very hard to simulate.  

To bring the board up safely, the best way to do it is to enable things one at a time.  The sequence is similar to what we do in the training labs.  First bring up the LLC output open loop and verify that the output section is working, and that the signals on the inputs to the UCD are correct.  Then you may want to bring up the fault logic to protect the board.  Then bring up the feedback loop, and other features.  

If you have the LLC EVM, and your circuitry is very close to the EVM circuitry - use the same pins for the same function, you can test your bring up code on it first to verify that it works correctly.  That way if you have a problem with your board, you know that it is probably a hardware issue rather than a firmware one.  

For the Fault 2 and 3, you want to make either fault 2 low or fault 3 high.  If they meet the description in the comment, it will clear the checksum and return the code to ROM mode by clearing the checksum.  This is put in to protect you in case your code has an infinite loop.  It's pretty easy to lock up a UCD by writing the checksum on a modified untested code.  Generally I don't write the checksum during the development process.  

It's true that it's a little easier for me to list all the spots that need to be changed, but it still takes time.  I'll try to get you a more complete list out tomorrow.  

Hi, Ian

Thank ur so much for the details like this, looking forward the complete list of modification spot, it will be of great help.

Actually, we ordered the EVM150 today as your suggest, while it takes a couple of weeks.

Before that, I will follow the steps that you listed to do the modifications. And I am using a FPGA + DA system for emulating the real LLC circuit to do the close-loop testing. Hope it will work. 

with regarts!

Xiaofeng

Here are the other code changes that I see.  I haven't tested these, so I may be missing something.  

I've already covered the the changes to PSON and BELOW_VIN_OFF_LIMIT.  The only other change to idle state is to comment out this line:

Dpwm0Regs.DPWMINT.bit.PRD_INT_EN = 1;

This disables the interrupt for CPCC. Also comment out the same line in init_filter_states, which is called from the idle mode.  A little redundancy.

In the check ramp up state, you just want to ignore the Iout reading and just go to the ramp up state when the ramp is complete:

//if (ramp_complete && ( adc_values.io_sense > pmbus_dcdc_config_translated[0].iout_oc_warn_limit))
{
//supply_state=STATE_HIGH_CURRENT_DURING_RAMP_UP;

}

if (ramp_complete);// && ( adc_values.io_sense < pmbus_dcdc_config_translated[0].iout_oc_warn_limit))
{

The characters in red show a simple way to do it.  If you are feeling more industrious, you can make all of these changes conditional, like with a #define FAULT_DISABLE or something.  

For the RAMP UP state, I don't see any additional changes needed.  

For the handle regulation state, I think you can comment everything out.  Just make it an empty function.  I'm not sure it the SR drivers are turned on or not by default.  If not, let me know, and we can get them turned on.  

You also need to go to init_fault_mux.c and just comment out everything in init_fault_mux and init_ovp functions.  This should prevent the floating ADC pins from shutting off the DPWMs.  

Hi, Ian

Thanks a lot for your help, I will do the modifications following your guide.

While, there this another question, In main.c

there is a segment of code:

//Initialize PMBus
init_pmbus(get_pmbus_address());

when I looked into the 'get_pmbus_address()', it is a fucntion that read the adc input to decide the value to be 0x59 or 0x5A. 

I don't understand the meanings of these numbers, you know in traininglabs, the code is:

init_pmbus(0x58); // initialize PMBus handler

As there will be no input at ADC terminals in my debug, which number should I use?  0x59 or 0x5A?

thank you!

with regards!

Xiaofeng Wu 

You can use either address.  The GUI will scan all the addresses and find where it is.  There are some addresses reserved in I2C and PMBus, but the 50s are not in that range.