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.

CCS/TMS320DM8167: Our customized board, not evm.

Part Number: TMS320DM8167

Tool/software: Code Composer Studio

Hi,

I have a problem like below picture. It suddenly occurred while running firmware few hours. I don't use any OS (such as TI RTOS).

I don't know why it occurred and how I debug to fix this. I have several boards, but they did not occur the problem except one. Only one board had this issue.

Please help me to reply any comment, If you have any idea about this.

Thank you in advance.

  • Hi Seonghun,

    Can you provide more details about the firmware that you are running and causing the error?

    From what I understand you are using CCStudio with your own software? You are not using DM816x TI EZSDK or DVR RDK?

    Please provide more info regarding the software that you are using.

    Regards,
    Pavel
  • Hi Pavel,

    Yes, I'm using own software and board, not using EZSDK or RDK.

    ARM side is programmed for the peripherals(like PCI, Flash, and RAM, ...) and the industrial network.

    DSP side is programmed for the motion algorithm.

    ARM and DSP are using Mailbox for interconnecting between them.

    My board uses DDR3 of 4 with 256M size. (Total 1G size)

    Please reply any comment, if you need to know to understand about my question.

    Thank you in advance.

    Regards.

  • Seonghun,

    From what I understand, you are running your own software (firmware, motion algorithm) on the C647x DSP and after few hours running, the C647x DSP core hang.

    I would suggest you to inspect the C674x DSP clock source, check Main PLL registers settings and compare the values between working and non-working board, check for differences. Compare also C674x DSP PRCM related registers values: CM_GEM_CLKSTCTRL, CM_ACTIVE_GEM_CLKCTRL, RM_ACTIVE_RSTCTRL, RM_ACTIVE_RSTST

    See also below e2e thread:

    e2e.ti.com/.../415727

    Regards,
    Pavel
  • Hi Pavel,

    Thank you for the reply. I think I missed the description for you to understand what I had a problem. I have a question before I do check the clock. I have several same boards and they contain same F/W. Only one board has fail like upper issue. Do I check the clock in this environment? Is it meaningful?

    Regards,
    SH
  • SH,

    Yes, I think the root cause might be in the clock signal stability. Check Main PLL (FAPLL) (sysclk1, main pll clock 1) clock , as explained in previous post. Be advised that DSP, GEM, and C674x are used interchangeably.

    Make sure also the failing board part number is the same as working boards.

    C674x DSP is located in Active power domain, thus make sure DM816x device do not transition from Active state to Low power standby state when issue occur.

    You can also run the evm816x.gel file and check if Main PLL and C674x functions run fine on the failing board.

    Another thing you can check is DDR3 memory, refer to the below e2e thread for details:

    processors.wiki.ti.com/.../Sitara_Linux_Training:_Tuning_the_DDR3_Timings_on_BeagleBoneBlack

    e2e.ti.com/.../1046142

    e2e.ti.com/.../1067409

    Regards,
    Pavel
  • Hi Pavel,

    I revised Main PLL and DDR PLL register in gel file, and I got below error after several hours running..

    Please kindly let me know what is the next step.

    Thank you in advance.

    Regards,

    SH

  • Seonghun Choi said:

    I revised Main PLL and DDR PLL register in gel file, and I got below error after several hours running..

    Please kindly let me know what is the next step.

    I do not see anything applied from the previous post, so the next step would be to switch back to the previous post.

    How do you verify that DSP clock is still active when the issue occur? Have you inspect the DSP PRCM registers? How do you verify that Main PLL is still active and locked when the issue occur? How do you verify that DDR3 is properly set up (software leveling is correct)?

    I would suggest you also to try running the software without using CCS/JTAG (if possible), as the issue might be related to JTAG and the related EMU pins. Check the JTAG related pins (EMU pins are part of this group) with scope and compare between working and not working board/case.

    See the below pointers regarding EMU pins debug guidelines:

    Regards,
    Pavel

  • Hi Pavel,

    Thank you for the comment. I will check the clock more deeply which I designed.

    Regards,

    SH