• TI Thinks Resolved

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

Part Number: TMS320DM355

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



  • In reply to Pavel Botev:

    See also what is recommended for unused pins for similar device DM385:

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

    4.4 Handling Unused Pins

    Regards,
    Pavel



  • In reply to Pavel Botev:

    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
  • In reply to TETSUOMA:

    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
  • In reply to TETSUOMA:

    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



  • In reply to Pavel Botev:

    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
  • In reply to TETSUOMA:

    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



  • In reply to Pavel Botev:

    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
  • In reply to TETSUOMA:

    Tetsuo,

    TETSUOMA
    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



  • In reply to Pavel Botev:

    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