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.

DM8148 - How to lower the DSP Clock

Hi,

Almost finished product. DM8148 with IPNC RDK 3.8 as basecode.

Question:

Due to an awful amount of overheating problems (from flash corruption to PHY stalling), I need to substantially lower the DSP Clock.

I've followed this post https://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/229933 

And changed DSP_M from 500 to 100, 250 and 400. Only the defult 500 worked. All the others caused the system to stall right after the 'boot' comand on U-boot.

I do not want to turn off the DSP core, just to lower its clock as much as possible. I've also set the core voltage to ~1.16V, to match OPP100 recomendation.

Where else must I change to achieve lower DSP clock speeds? What's the trick?

  • Weber,

    weber de souza calixto said:
    And changed DSP_M from 500 to 100, 250 and 400. Only the defult 500 worked.

    You have requirement for CLKDCO, it can be in two modes:


    HS1: 1000MHz to 2000MHz

    HS2: 500MHz to 1000MHz

    When you set DSP_M to 400 (250, 100) you are violating this 500MHz limitation. See DM814x datasheet, 7.4.8.3 PLL Frequency Limits


    The DSP PLL clkout can be lower to 10MHz. You can leave DSP_M to 500 and update DSP_M2 from 1 to 50. Thus you will have CLKDCO 500MHz and CLKOUT 10MHz.

    u-boot/.../clocks_ti814x.h

    #define DSP_N        19
    #define DSP_M        500
    #define DSP_M2        50//1
    #define DSP_CLKCTRL    0x801

    You can also set DSP PLL in idle bypass mode, thus you will have 20MHz clock, coming directly from the DEVOSC.

    Regards,
    Pavel

  • Pavel,

    I'm into this change again.

    Questions:

    1)
    I've tried your suggestion to arbitrarily lower the DSP _M2 in order to achieve CLKOUT at 10 MHz. It did not work, but I've managed to lower the clock only to 275 MHz with the following configuration:

    DSP_M 550
    DSP_M2 2
    DSP_N 19
    DSP_CLKCTRL 0x801

    With DSP M2 any higher than 2 the DSP does boot during the boot process.

    Is there any particular reason for this?

    Extra info:

    During U-boot boot, I've also placed two I2C commands to lower the core voltages to 1.1V (OPP100). My goal is to have the product running at OPP100 to minimize heating. The commands are:

    i2c mw 0x2D 0x25 0x2B
    i2c mw 0x2D 0x28 0x2B

    2)
    After lowering the DSP clock to 275 MHz, I've started to get an awful amount of problems related to DSP attachment during boot process. Log is as follows:

    [m3vpss ] 51278: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3video] 51314: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3vpss ] 51328: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3video] 51365: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3vpss ] 51378: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3video] 51416: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3vpss ] 51428: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3video] 51467: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...
    [m3video] 51518: SYSTEM: Attaching to [DSP] Id = A0 return = -11 ...

    I've noticed that this problem always happens after a "hard" software reset: Either caused by watchdog or system glitch.

    The problem persists even after a second watchdog reset. It is only solved after a true electric hard reset, which makes this a very serious problem because this product is supposed to work on remote locations without intervention.

    What may be causing this boot instability? Could you please point the direction to solve this issue, as this one does not allow our product to be released into market?

    Right now I'm considering also to completely turn off the DSP. This is not exactly what we need, but is better than releasing a product that requires human intervention to recover from a faulty condition when it shouldn't.

    Thanks,

    Weber
  • Weber,

    weber de souza calixto said:
    1)
    I've tried your suggestion to arbitrarily lower the DSP _M2 in order to achieve CLKOUT at 10 MHz. It did not work

    Can you provide me register dump of the DSPPLL registers: from DSPPLL_PWRCTRL/0x481C5080 to DSPPLL_STATUS/0x481C50A4

    Are you using DEVOSC 20MHz as source for the DSPPLL? OSC_SRC[31] GEM_PLL_SOURCE = 0x0


    weber de souza calixto said:
    With DSP M2 any higher than 2 the DSP does boot during the boot process.

    Is there any particular reason for this?

    Do you mean DSP core does NOT boot? In u-boot or linux kernel?

    weber de souza calixto said:
    During U-boot boot, I've also placed two I2C commands to lower the core voltages to 1.1V (OPP100). My goal is to have the product running at OPP100 to minimize heating.

    Make sure you are also aligned with the below wiki pages:

    BR
    Pavel

  • Pavel,

    In both cases (DSP clock below 275 MHz and DSP at 275 MHz but sttaled after a hard software reset) the problem appears during linux boot process. The other cores cannot attach do DSP core.

    Below follows the register dump from linux, using devmem2 program. The device is up and running normally, with DSP clock at 275 Mhz.

    Register DSPPLL_PWRCTRL (0x481C5080)

    root@ITSCAM500:~# devmem2 0x481C5080
    /dev/mem opened.
    Memory mapped at address 0x40393000.
    Read at address 0x481C5080 (0x40393080): 0x00000030

    Register DSPPLL_CLKCTRL (0x481C5084)

    root@ITSCAM500:~# devmem2 0x481C5084
    /dev/mem opened.
    Memory mapped at address 0x40125000.
    Read at address 0x481C5084 (0x40125084): 0x271B080F

    Register DSPPLL_TENABLE (0x481C5088)

    root@ITSCAM500:~# devmem2 0x481C5088
    /dev/mem opened.
    Memory mapped at address 0x40248000.
    Read at address 0x481C5088 (0x40248088): 0x00000000

    Register DSPPLL_TENABLEDIV (0x481C508C)

    root@ITSCAM500:~# devmem2 0x481C508C
    /dev/mem opened.
    Memory mapped at address 0x4036a000.
    Read at address 0x481C508C (0x4036a08c): 0x00000000

    Register DSPPLL_M2NDIV (0x481C5090)

    root@ITSCAM500:~# devmem2 0x481C5090
    /dev/mem opened.
    Memory mapped at address 0x402d3000.
    Read at address 0x481C5090 (0x402d3090): 0x00020013

    Register DSPPLL_MN2DIV (0x481C5094)

    root@ITSCAM500:~# devmem2 0x481C5094
    /dev/mem opened.
    Memory mapped at address 0x401f2000.
    Read at address 0x481C5094 (0x401f2094): 0x00000226

    Register DSPPLL_FRACDIV (0x481C5098)

    root@ITSCAM500:~# devmem2 0x481C5098
    /dev/mem opened.
    Memory mapped at address 0x402ab000.
    Read at address 0x481C5098 (0x402ab098): 0x03000000

    Register DSPPLL_BWCTRL (0x481C509C)

    root@ITSCAM500:~# devmem2 0x481C509C
    /dev/mem opened.
    Memory mapped at address 0x4027b000.
    Read at address 0x481C509C (0x4027b09c): 0x00000000

    Register DSPPLL_FRACCTRL (0x481C50A0)

    root@ITSCAM500:~# devmem2 0x481C50A4
    /dev/mem opened.
    Memory mapped at address 0x401c9000.
    Read at address 0x481C50A4 (0x401c90a4): 0xC0000638

    Register DSPPLL_STATUS (0x481C50A4)

    root@ITSCAM500:~# devmem2 0x481C50A4
    /dev/mem opened.
    Memory mapped at address 0x40375000.
    Read at address 0x481C50A4 (0x403750a4): 0xC0000638

    Dsp clock configuration at u-boot:

    #define DSP_N 19
    #define DSP_M 550
    #define DSP_M2 2
    #define DSP_CLKCTRL 0x801

    Weber

  • If the problem is that after setting DSP from 500MHz (default) to 275MHz or 10MHz, cannot attach to DSP core, then you should remove any DSP programming/initialization and remove any attach attempts from the other cores. From what I understand, you will not use the DSP, so you should remove this stuff also, not just lower the clock.

    BR
    Pavel
  • Pavel,

    Yes the problem starts happening after I've changed the DSP clock from 500 MHz to 275 MHz or lower.

    It seems that I have no other option than turning the DSP core off. The main problem with this is usecase compatibility in the future. Eventually we will have to use the DSP core, and it would be better to already have all our usecases compatible.

    Weber