TMS320F2800157: PMBUSA SDA and SCL lines latched LOW immediately upon PMBus_enableModule() in Controller Mode

Hi Nguyen,

There are some EALLOW protected registers in PMBUS, so I would suggest wrapping your whole initialization sequence in EALLOW; and EDIS;. Are you running your code free run and seeing the SCL/SDA go low indefinitely or are you pausing after the PMBus_enableModule()? I'm wondering if this is just emulation-related behavior.

Best Regards,

Delaney

Hi Delaney,

Thanks for the suggestions! I wrapped the entire initialization sequence inside EALLOW; and EDIS; and tested it in Free Run mode (running continuously with all breakpoints cleared):

void Setup_PMBus(void)
{
EALLOW;
SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_PMBUSA);
PMBus_disableModule(PMBUSA_BASE);

// Setup SDA Pad
GPIO_setPinConfig(GPIO_44_PMBUSA_SDA);
GPIO_setDirectionMode(PMBUS_SDA_PIN, GPIO_DIR_MODE_IN);
GPIO_setPadConfig(PMBUS_SDA_PIN, GPIO_PIN_TYPE_PULLUP | GPIO_PIN_TYPE_OD);
GPIO_setQualificationMode(PMBUS_SDA_PIN, GPIO_QUAL_ASYNC);

// Setup SCL Pad
GPIO_setPinConfig(GPIO_35_PMBUSA_SCL);
GPIO_setDirectionMode(PMBUS_SCL_PIN, GPIO_DIR_MODE_IN);
GPIO_setPadConfig(PMBUS_SCL_PIN, GPIO_PIN_TYPE_PULLUP | GPIO_PIN_TYPE_OD);
GPIO_setQualificationMode(PMBUS_SCL_PIN, GPIO_QUAL_ASYNC);

PMBus_enableI2CMode(PMBUSA_BASE);
PMBus_deassertAlertLine(PMBUSA_BASE);
PMBus_setOwnAddress(PMBUSA_BASE, PMBUSA_OWN_ADDRESS);

uint32_t moduleFreq = PMBus_configModuleClock(PMBUSA_BASE, PMBUS_MODULE_FREQ_MAX, DEVICE_SYSCLK_FREQ);
PMBus_configBusClock(PMBUSA_BASE, PMBUS_CLOCKMODE_STANDARD, moduleFreq);

PMBus_initControllerMode(PMBUSA_BASE);
PMBus_setTargetAddress(PMBUSA_BASE, LM5066H_SLAVE_ADDR);
PMBus_enableModule(PMBUSA_BASE);
EDIS;
}

Unfortunately, even in Free Run, both SDA and SCL lines are still latched LOW (0V) permanently on the scope as soon as PMBus_enableModule() is executed. Please note that at this point, the application only initializes the peripheral—no read or write transaction has been triggered yet.

Does the PMBus Controller hardware require an initial transaction or specific status/flag reset sequence immediately after PMBus_enableModule() to release the bus?

Looking forward to your guidance!

Best Regards,

Thao

Hi Nguyen,

Let me try this out myself on hardware to see if I can replicate and get back to you.

Best Regards,

Delaney

Hi Delaney,

I just wanted to follow up on this and see if you have had a chance to test it on the hardware yet.

Please let me know if you have any updates or if you need any further information from my side to help with the replication.

Best regards,

Thao

Hi Nguyen,

Unfortunately, I haven't had a chance to test this yet due to another high-priority debug. Would it be ok if I provide an update by the end of this week?

Best Regards,

Delaney

Hi Delaney,

Thanks for the update! That sounds completely fine.

I will look forward to hearing from you by the end of this week.

Best regards,

Thao

Hi Nguyen,

Sounds good, I will update tomorrow.

Best Regards,

Delaney

Hi Thao,

I was able to test this out myself today and I'm seeing some different behavior. When I step over the PMBus_enableModule() line in initializtion, I see the PMBUS send out a packet based on the address and R/W settings in the PMBMC register. This behavior is expected since the RESET only resets the FSM and doesn't clear the register configurations, so the settings in PMBMC are triggering a new frame.

After this, both the SCL and SDA lines go back high (idle) as expected. Can you check and make sure you don't have a scope trigger enabled that is freezing the screen during the packet send? The packet I see has the below structure (NACK is there because I don't have any slave devices on the bus to ACK):

• START condition
• Slave address
• Write bit
• NACK
• STOP

Best Regards,

Delaney

Hi Delaney,

Thanks for checking and for the detailed explanation!

I verified the scope settings and confirmed that it's not a trigger freezing issue. Even when using the F2800157 EVM board with external 2.2k ohm pull-up resistors, both SCL and SDA lines are continuously latched LOW right after PMBus_enableModule() is called and they never return to HIGH.

Just to clarify, before calling PMBus_enableModule(), both lines are correctly sitting at 3.3V. We haven't attempted to transmit any frames yet; this happens purely during the initialization sequence. So, being latched LOW like this seems abnormal to us.

For reference, here is the state of the PMBMC register before and after the setup:

Before setup: PMBMC: 0x00000000

• PRC_CALL: 0

• GRP_CMD: 0

• PEC_ENA: 0

• EXT_CMD: 0

• CMD_ENA: 0

• BYTE_COUNT: 00000000

• SLAVE_ADDR: 0000000

• RW: 0

After setup (right after PMBus_enableModule()): PMBMC: 0x0000002C

• PRC_CALL: 0

• GRP_CMD: 0

• PEC_ENA: 0

• EXT_CMD: 0

• CMD_ENA: 0

• BYTE_COUNT: 00000000

• SLAVE_ADDR: 0010110

• RW: 0

We notice that the Slave Address is populated during the setup.

Are there any other registers (e.g., PMBSTS, PMBCTRL) we should check or capture at this point to help diagnose why it's getting stuck LOW instead of returning to Idle? Any further insights would be greatly appreciated.

Best regards,

Thao

Hi Thao,

Can you try following the initialization order done by Sysconfig exactly? That is the initialization sequence I used to test this. It seems that yours is similar already but just wanted to rule this out. 

Also, do you have optimizations turned on in your project at all? Can you disable optimizations and rebuild to be sure of which line causes the change in GPIO state to low when stepping through?

Best Regards,

Delaney

Hi Delaney,

Thanks for your continued support!

I was finally able to successfully communicate with the LM5066H and read the data.

To resolve the permanent latch-up issue I reported earlier, I had to add a specific bus recovery sequence right before starting the transaction.

PMBus_disableModule(PMBUSA_BASE);
DEVICE_DELAY_US(1000U);
PMBus_enableModule(PMBUSA_BASE);
HWREG(PMBUSA_BASE + PMBUS_O_PMBCTRL) |= PMBUS_PMBCTRL_MASTER_EN;
DEVICE_DELAY_US(1000U);

Without this sequence, both lines still latch LOW permanently on my board.

However, I observed a new, specific latch-up behavior that happens immediately after the setup/initialization phase when a NACK occurs (not during normal, ongoing communication):

1. Immediately after the NACK (on the 9th clock), SCL is held LOW by the MCU instead of generating a STOP condition.

   

2. ~35ms later, SDA also goes LOW (which perfectly aligns with the SMBus timeout limit, meaning the slave resets because SCL is stuck).

   

3. Both lines stay latched LOW for exactly 1 second before finally returning to HIGH (IDLE).

   

I have attached oscilloscope captures showing this exact sequence (the 35ms and 1-second delays).

Could you let me know if this 1-second latch-up and the failure to issue a STOP after a NACK is an expected fault-handling behavior for the C2000 PMBus state machine? Is there a recommended way to force the module to release the bus properly right after a NACK?

Best regards,

Thao

Hi Thao, 

Please allow me some time to look into your new question, as well as try out the latching solution you are mentioning. I will have a response back early next week. 

Best Regards,

Delaney

Hi Thao,

I apologize for the long delay here. Can you verify that this isn't the LM5066H device clock stretching? Usually, SCL being held low is due to the slave device pulling it low after a transmission to process the data. I'm not familiar with the LM5066H so I'm not sure if it has this capability.

Best Regards,

Delaney