• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 65 subscribers
  • Views 600 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.

TPS65381-Q1: Unclear busy wait loop in TPS_driver.c

Kenneth S
Prodigy 20 points
Part Number: TPS65381-Q1

Hi,

First of all, I apologize if I've hit the wrong forum. This is my first post and I'm still on somewhat shaky ground.

We're using the most recent TPS driver from the TPS library for the TPS65381. In our application this results in a high load on our microprocessor, that we have traced to the TPS_CheckEnabledAMUXSignalLimits() function in tps_driver.c, which includes the following busy wait loop:

for (u32temp = 0U; u32temp < 60000U; u32temp++)
{

}
/*add some delay so that the analog output is stable*/


We understand that this is a generic implementation, which makes it difficult to provide an efficient wait method (such as a task sleep when using FreeRTOS, for instance) and we don't mind modifying the implementation to better suit our environment (if licensing allows). Is it possible for you to provide us with some more specific information regarding timing - how long would you expect it is necessary to wait before continuing execution? We've skimmed through the datasheet, but are having trouble finding specifics.

- Kenneth

  • 0
    TI__Genius 16410 points
    Hi Kenneth,

    I've notified the product expert, he will be able to respond to your question. Could you explain what the code is doing before and after this wait loop? Is it simply selecting the analog mux channel?

    Regards,
    Karl
  • 0 in reply to Karl Wallinger
    Prodigy 20 points

    Hi,

    Thanks for the quick reply. I'd paste the code, which would probably be the clearest way to explain it, but I'm not sure if I'm allowed to or not (it's in the TPS_driver.c file), but I can at least try to explain in broad terms.

    Nothing but variable initialization and some data checks occur before the loop.

    Right after the loop the contents of the TPS_DIAG_CFG_CTRL and TPS_DIAG_MUX_SEL are read with TpsIf_GetRegister(), after which (our) user code is called in a callback with GetTPSDiagPinSampledValue(), which is supposed to provide the ADC sampled value.

    -Kenneth

  • 0 in reply to Kenneth S
    TI__Mastermind 20590 points

    Hi Kenneth,

    This forum supports the TPS65381 and the MCU teams support the software and processors on a separate forum. 

    From the TPS65381 device viewpoint at a high level flowchart view the software should do the following to use the DIAG_OUT mux for diagnostics.

    1) Configure the MUX settings for the appropriate signal that needs to be read, in this case since you mention ADC, it appears you are trying to us the analog mux (AMUX). 

    DIAG_MUX_SEL bits are used for the specific signal wanted. See sections 5.4.1.9 for AMUX listing of signals http://www.ti.com/product/TPS65381-Q1/datasheet/detailed_description#SLVSBC46704 and 5.4.1.10 for DMUX signals http://www.ti.com/product/TPS65381-Q1/datasheet/detailed_description#SLVSBC46008

    DIAG_CFG_CTRL register should have MUX_CFG bits set to 10 for Analog Mux mode (see page 92 of the TPS65381 Rev F datasheet for the other options), this register is also has the MUX_EN bit to enable the MUX output to DIAG_OUT.

    2) Once the MUX has been set up and enabled there will be a settling time on the DIAG_OUT pin output depending on the previous level on DIAG_OUT and the RC loading on the pin.  Each Analog MUX signal has a maximum output resistance specified in section 5.4.1.9 AMUX.  This resistance, the output voltage step between signals and the external RC loading of the ADC and it's input filter if required will determine the settling time for your system.    The ADC sampling should wait until the signal settles.

    3) Use ADC to sample the signal wanted.

    4)  If another signal is to be measured immediately:  change the AMUX signal via DIAG_MUX_SEL if desired, wait till signal settles and sample new signal.  (The recommended signal ordering to have the fasted stabilization of the AMUX signals is listed in the text under Table 5-4. 

    5) If there is a longer time between needing AMUX readings or DMUX signals are needed then disable or re-configure the MUX output via DIAG_CFG_CTRL register.  

    Note:  for DMUX signals, they are digital so the DIAG_OUT pin can be routed to both an ADC channel (AMUX measurements) and a GPIO so that for digital signals on the DIAG_OUT the MCU overhead is reduced to reading a GPIO instead of sampling on the ADC and converting back to binary. 

    To get more support on the software libraries I would recommend posting to the Hercules Microcontroller forum at: https://e2e.ti.com/support/microcontrollers/hercules/

    Hopefully that helps you understand the AMUX and DIAG_OUT on TPS65381-Q1, if not please post a follow up question as necessary. 

    Best Regards,

    Scott