• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 218 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123BH6PGE: Current Loss in TM4C123BH6PGE During One-Wire Protocol Implementation

ygt ulk
Prodigy 100 points
Part Number: TM4C123BH6PGE

Hi, I have implemented the One-Wire protocol for the TM4C123BH6PGE, which features a very quick output-to-input transition. When I tried to read the temperature, everything worked fine, but I noticed a significant drop in current on my device. Later, I disconnected the One-Wire connection and tested the code again, only to find that I was still experiencing a loss of current. I have narrowed down the source of this current loss to this specific operation.

unsigned int OneWireReset(void) {
    OneWireSetOutput();
    GPIOPinWrite(ONE_WIRE_PORT, ONE_WIRE_PIN, 0); // Drive the line low
    delayMicroseconds(480); // Reset pulse time
    OneWireSetInput(); // Release the line
    delayMicroseconds(70); // Wait for presence pulse
    unsigned int OW = OneWireRead(); // Read presence pulse
    delayMicroseconds(410); // Wait for end of timeslot
    return OW; // Return presence pulse status
}


I believe I am experiencing current loss due to switching to input mode too quickly. Has anyone encountered a similar issue before?

  • 0
    TI__Guru**** 191356 points
    ygt ulk said:
    When I tried to read the temperature, everything worked fine,

    Just to confirm that despite the current drop, you are reading the correct data in all conditions. Is that correct?

    ygt ulk said:
    but I noticed a significant drop in current on my device. Later, I disconnected the One-Wire connection and tested the code again, only to find that I was still experiencing a loss of current.

    How much drop are you talking about? If the current consumption in either case is within the datasheet spec then I don't really see a problem. You can also measure the reset current. When the pin is in output, you are sourcing the current depending on the the drive strength and the load you have on the pin. I'm not surprised it is higher than in input mode. 

  • 0 in reply to Charles Tsai
    Prodigy 100 points

    Yes, I can read the data just fine, and all the other functionalities of my device seem to be working well.

    Normally, I power my device with 48V and observe the current fluctuating between 1.00 and 0.98.However, now I see the current rapidly fluctuating between 1.00 and 0.93

  • 0 in reply to ygt ulk
    TI__Guru**** 191356 points

    I suppose the difference between 1 and 0.93 is on your overall system, not just the MCU, correct? Also what is the unit of the current? In A or mA? If it is in A then the difference is 70mA. The entire MCU does not even consume more than 50mA in normal condition. You need to first investigate/isolate how much the MCU only consumes and then investigate your design where other components are drawing current. 

  • 0 in reply to Charles Tsai
    Prodigy 100 points

    "Yes, I am experiencing a 0.70 mA loss in current. I isolated the MCU and observed no drop in current when using the One-Wire protocol. However, I noticed a current loss when it is connected to my PCA card via I2C. Could changing the pin status from input to output be affected by I2C communication?"

  • 0 in reply to ygt ulk
    TI__Guru**** 191356 points
    ygt ulk said:
    Yes, I am experiencing a 0.70 mA loss in current.

    Do you mean 0.7A or 0.7mA. If it is 0.7mA  then it is negligible. You need to check the load on the I2C pin. By default, the SDA pin is configured with 2mA strength. If you have a heavy load then you can try to increase the drive strength. 

    //*****************************************************************************
    //
    //! Configures pin for use as SDA by the I2C peripheral.
    //!
    //! \param ui32Port is the base address of the GPIO port.
    //! \param ui8Pins is the bit-packed representation of the pin.
    //!
    //! The I2C pins must be properly configured for the I2C peripheral to function
    //! correctly. This function provides the proper configuration for the SDA
    //! pin.
    //!
    //! The pin is specified using a bit-packed byte, where each bit that is
    //! set identifies the pin to be accessed, and where bit 0 of the byte
    //! represents GPIO port pin 0, bit 1 represents GPIO port pin 1, and so on.
    //!
    //! \note This function cannot be used to turn any pin into an I2C SDA pin; it
    //! only configures an I2C SDA pin for proper operation. Note that a
    //! GPIOPinConfigure() function call is also required to properly configure a
    //! pin for the I2C SDA function.
    //!
    //! \note A subset of GPIO pins on Tiva devices, notably those used by the
    //! JTAG/SWD interface and any pin capable of acting as an NMI input, are
    //! locked against inadvertent reconfiguration. These pins must be unlocked
    //! using direct register writes to the relevant GPIO_O_LOCK and GPIO_O_CR
    //! registers before this function can be called. Please see the ``gpio_jtag''
    //! example application for the mechanism required and consult your part
    //! datasheet for information on affected pins.
    //!
    //! \return None.
    //
    //*****************************************************************************
    void
    GPIOPinTypeI2C(uint32_t ui32Port, uint8_t ui8Pins)
    {
    //
    // Check the arguments.
    //
    ASSERT(_GPIOBaseValid(ui32Port));

    //
    // Make the pin(s) be peripheral controlled.
    //
    GPIODirModeSet(ui32Port, ui8Pins, GPIO_DIR_MODE_HW);

    //
    // Set the pad(s) for open-drain operation with a weak pull-up.
    //
    GPIOPadConfigSet(ui32Port, ui8Pins, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_OD);