• State
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 38 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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

Nguyen Thao
Prodigy 80 points

Part Number: TMS320F2800157
Other Parts Discussed in Thread: LM5066H,

Hi C2000 Team,

I am configuring the PMBUSA peripheral on TMS320F2800157 in Controller (Master) Mode to communicate with an LM5066H target device. However, I am encountering an issue where both SDA and SCL lines immediately latch LOW (0V) as soon as PMBus_enableModule(PMBUSA_BASE) is executed.

Hardware & Schematic Details:

  • SDA Pin: GPIO44

  • SCL Pin: GPIO35

  • SMBA Pin: GPIO37

  • External Pull-ups: 2.2kOhm pull-up on both SDA and SCL lines; 10kOhm pull-up on SMBA.

  • Bus Line State: When PMBus is disabled (or before PMBus_enableModule), both SDA and SCL lines measure 3.3V with a multimeter.

Software Configuration:

void Setup_PMBus(void)
{
    // 1. Enable Peripheral Clock
    SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_PMBUSA);

    // 2. Configure PinMux & Pad Config
    GPIO_setPinConfig(GPIO_44_PMBUSA_SDA);
    GPIO_setDirectionMode(PMBUS_SDA_PIN, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(PMBUS_SDA_PIN, GPIO_PIN_TYPE_OD);
    GPIO_setQualificationMode(PMBUS_SDA_PIN, GPIO_QUAL_ASYNC);

    GPIO_setPinConfig(GPIO_35_PMBUSA_SCL);
    GPIO_setDirectionMode(PMBUS_SCL_PIN, GPIO_DIR_MODE_IN);
    GPIO_setPadConfig(PMBUS_SCL_PIN, GPIO_PIN_TYPE_OD);
    GPIO_setQualificationMode(PMBUS_SCL_PIN, GPIO_QUAL_ASYNC);

    // 3. Reset & Clock Setup
    PMBus_disableModule(PMBUSA_BASE);
    PMBus_disableI2CMode(PMBUSA_BASE);
    PMBus_deassertAlertLine(PMBUSA_BASE);

    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);

    // 4. Enable Module
    PMBus_enableModule(PMBUSA_BASE);
}

Diagnostic & Register Inspection:

  1. PinMux Verification:

    Checked GPBMUX1 in CCS Registers view: GPIO44 = 10 and GPIO35 = 10 (MUX selection for PMBUSA is confirmed correct).

  2. Clock Calculation:

    DEVICE_SYSCLK_FREQ =120MHz. moduleFreq returns 20000000 (20MHz), which is valid for PMBUS_MODULE_FREQ_MAX.

  3. Thanh ghi PMBSTS (Status Register) right after PMBus_enableModule():

    • PMBSTS = 0x00042100 (or 0x0004B110)

    • SCL_RAW = 0

    • SDA_RAW = 0

    • BUS_FREE = 1 (prior to enable)

    • UNIT_BUSY = 1

    • CLK_LOW_TIMEOUT = 1

Questions:

  1. What could cause the PMBus hardware state machine to pull SDA and SCL LOW immediately upon un-resetting (PMBUS_RESET = 0), despite lines being physically pulled up to 3.3V beforehand?

  2. Is there a required sequence, delay, or register lock/unlock (EALLOW) step that I might be missing between PinMux/PadConfig setting and clearing PMBUS_RESET?

  3. Why would SCL_RAW and SDA_RAW report 0 as soon as the peripheral exits reset?

Thanks in advance for your support!

 

  • 0
    TI__Mastermind 25560 points

    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

  • 0
    Prodigy 80 points

    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

  • 0 in reply to Nguyen Thao
    TI__Mastermind 25560 points

    Hi Nguyen,

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

    Best Regards,

    Delaney