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.

Linux/TMS320DM355: Strange behavior of power consumption of DM355.

Part Number: TMS320DM355
Other Parts Discussed in Thread: DM385

Tool/software: Linux

Dear All,

Does anyone know the method to trace the GPIO pins using XDS560 USB emulator?

The reason is as follows.

We are facing a strange behavior of power consumption of our system.

Our board is Linux based and equipped with several peripherals such as GPS, SD slot.

Regarding the functions, our system works as we have expected but the behavior of power consumption is quite strange.

While we are measuring the current of VDD (3.3v), when we put our finger on the device (DM355) the current  goes down around 20mA!

We guess that there would be some pins whose impedance are high and are unstable.

So when a finger comes closer to the device, it might give some inductive influence to the device.

We have found no errors from software view point.

Because the device is BGA package, we can't access several pins which have no external connection.

So we would like to know whether we an trace the status of pins using the emulator or something.

I'd appreciate any advises.

Regards,

Tetsuo Maeda

 

  • Hi Tetsuo,

    There are some GPIO pins (i.e. H15 GIO30 and B18 GIO006] that has no internal pull resistor and are inputs by default (after reset). If you do not handle such unused pins properly, you might have power consumption generated by float on these pins. What I can recommend you to setup these pins as outputs.

    You can also use boundary scan and/or dumping of Control Module pinmux registers to try finding more information regarding DM35x device pins state.

    Regards,
    Pavel
  • See also what is recommended for unused pins for similar device DM385:

    www.ti.com/.../dm385.pdf

    4.4 Handling Unused Pins

    Regards,
    Pavel
  • Dear Pavel-san,

    Thank you for the advice.

    The investigation on our side shows similar result.

    I hope we can solve the problem by setting unused pins properly!

    Kind Regards,

    Tetsuo Maeda
  • Dear Pavel-san,

    Sorry for disturbing you but we have not solved the problem.

    We have been trying to modify the registers such as VIDCTL but it seems they are protected from user level access.

    Are there modules or tools which can modify such registers from user application?

    We are thinking to modify Yout 0 -7 ports to "output" and set them to "L" by setting YCDIR = 0, YCOL = 1 and YVYL = 0.

    I'd appreciate your advice because we are not familiar with MontaVista linux and our software guys will not be able to join us for a week or so.

    Kind Regards,

    Tetsuo Maeda
  • Tetsuo,

    On some devices (like DM8148) we can not write pinmux registers (Control Module) from user space, as ARM core should in supervisor/privileged mode. ARM is in supervisor/privileged mode only in u-boot/kernel stage, not in user space. See below e2e post for more info:

    e2e.ti.com/.../2274078


    I am not sure if this is the case with DM355 device, I can not find such restriction in DM355 documents:

    www.ti.com/.../sprufb3a.pdf
    www.ti.com/.../spruf72c.pdf

    The tool that I use to modify registers from user space is devmem2.

    See also below wiki pages:

    processors.wiki.ti.com/.../O_Power_Consumption_on_DM355_and_DM335
    processors.wiki.ti.com/.../O_Power_Consumption

    Regards,
    Pavel
  • Dear Pavel-san,


    Thanks to your advice, we are almost sure that the reason of our problem is the protection level of the registers that we want to modify.

    Is it possible to confirm that the register "VIDCTL" is among the registers that can't be accessed from user mode modules?
    If we confirm that "VIDCTL"can't be accessed from user level modules, we will have to modify the boot module or the device drivers that will run in kernel.

    We are in very tough situation and your suggestion would be greatly appreciated.

    Kind Regards,

    Tetsuo Maeda
  • Tetsuo,

    VIDCTL is NOT part of Control Module registers, VIDCTL belongs to VPBE registers. Thus I think VIDCTL should be accessible (read/write) from user level with devmem2 tool.

    Regards,
    Pavel
  • Dear Pavel-san,

    Thank you for the good news!

    We are trying to set Yout 0-7 port to OUT mode according to the site you told us as follows.

    VPBE: YOUT[7:0] Set pins to Outputs in code.
    1. Ensure that the PSC clocks to the VPSS module are enabled
    2. Ensure that the VPSS Clock Mux Control register (VPSS_CLK_CRTL) in the System Control Module is configured to select the appropriate VPBE clock source and enable it.
    3. Set the VPBE_CLK Bit to 1 in the VPSS clock control register (CLKCRTL) found in the VPBE users guide.
    4. Set the Video Interface I/O control Register (VIDCTL) YCDIR field to zero (output)

    By reading the corresponding registers, we have confirmed that step 2 is completed.

    But, we can't change the value of CLKCTRL.VPBE_CLK to "1".

    Are there any procedures that we should do before we try to change CLKCTRL.VPBE_CLK to "1"?

    Kind Regards,

    Tetsuo Maeda
  • Tetsuo,

    TETSUOMA said:
    But, we can't change the value of CLKCTRL.VPBE_CLK to "1".

    Are there any procedures that we should do before we try to change CLKCTRL.VPBE_CLK to "1"?

    I checked VPBE guide but I can not find any procedure to be followed before setting CLKCTRL[0] VPBE_CLK = 1

    Make sure you are using the correct CLKCTRL address 0x01C70004.

    Regards,
    Pavel

  • Dear Pavel-san,

    Thank you for the advice.

    I've checked SPRUF72C data sheet.

    The document says that both the addresses of "CLKCTRL" and "VPSS_CLK_CTRL" are 0x01C70004 (the same!).

    We understand the "CLKCTRL" and "VPSS_CLK_CTRL" are two different registers.

    Why the addresses of two registers are the same?

    Or, "CLKCTRL" and "VPSS_CLK_CTRL" are the same register?

    Kind Regards,

    Tetsuo Maeda
  • Tetsuo,

    These are two different registers. VPSS_CLK_CTRL address in SPRUF72C is wrong, it is NOT 0x01C70004.

    Refer to the below pointers for details:

    www.ti.com/.../sprufb3a.pdf

    e2e.ti.com/.../334408
    e2e.ti.com/.../168239

    Regards,
    Pavel
  • Dear Pavel-san,

    Thank you for the clarification.

    We've confirmed that the address of VPSS_CLK_CTRL is 0x01c7:0044.

    Kind Regards,

    Tetsuo Maeda
  • Dear Pavel-san,

    We are still struggling to set Yout 0 - 7 to OUT mode.
    In the analysis of the boot program, we have found that VPBE was turned off in the boot process.

    Because we can't modify the boot sequence, I think we need to turn on VPBE after the system has started.

    Are there method to turn on VPBE using user program or some command from the console?

    Kind Regards,

    Tetsuo Maeda
  • Tetsuo,

    You can try to turn on VPBE module by writing to its registers with devmem2 tool. You can dump the VPBE register values from kernel space and set the same values in user space. You might also need to configure VPBE pinmux and clocking to enable it. Please work with below user guides:

    www.ti.com/.../sprufb3a.pdf
    www.ti.com/.../spruf72c.pdf

    For any detailed software support, bug fixes, or enhancements to TI software, please contact any of the select partners recommended below:

    e2e.ti.com/.../622106

    Regards,
    Pavel
  • Dear All,

    We have finally solved the issue thanks to your advice.

    We believe that this experience will help us in the future developments.

    Regards,

    Tetsuo Maeda