Reset option for dm648

Mr. Randy thank you for your responee and kind welcome.

My problem is still not solved please answer this supplement question. I want that when my DSP DM648 goes into infinite loop of CSL it automatically resets itself and comes out of this halted situation. The solutions you mentioned like RESETn and PORn pins as well as CCS method doesnt give the automated solution these are manual ways. Please suggest some command or logic I implement in CSL loop so that I get the automated solution.

Thanks

Danish

Hello all

Actaully I am running DSP DM648 in ALE Bypass mode with NDK 1.92. The DSP automatically halts after few hrs of operation. The same prob cointinues with NDK 2. I dnt have any information from TI about NDK. WDT solution only provides software reset wheras I want Hard RESET. There is no peripehral event waiting to occur causing this halt but actually it is an internal DM648 bug that cant be treated(also mentioned in silicon errata). I simply want to know is whether using DM648 in ALE Bypass mode with NDK 1.92/2 can I hard reset the DSP automatically to bring it out from the CSL loop or not?

Regards

Danish

dami said:

There is no peripheral event waiting to occur causing this halt but actually it is an internal DM648 bug that cant be treated(also mentioned in silicon errata).

To which bug "mentioned in silicon errata" do you refer?

I did a quick search and did not find any WDT support in the DM648. But if you have one of the 64-bit timers available and its timer output pin, then you should be able to implement a WDT of your own and connect the timer output to the RESETn pin. Then your code would periodically write to the TIM register to keep the timer from reaching its terminal value, and when you do not do this because of a lockup the timer output pin would assert a hard reset.

Proper engineering care will need to be taken to provide for all the boundary conditions, and I have not tried this other than to make this suggestion. If you try this, please reply back with your success or failure story.

The Silicon Errata is present at http://focus.ti.com.cn/cn/lit/er/sprz263f/sprz263f.pdf please refer to page 7 where at 2.1.3 TI states that data traffic at 3-Port Ethernet Switch Subsystem (3PSW) can cause deadlock situation. This is the stage at which my DSP DM648 halts and goes into infinte CSL loop.

I have read your suggestion regarding Timer and is working on it I will soon relate to you my success or failure story. Kindly see the aforesaid Silicon Errata and tell me if you have any solution.

Thanks

Danish

Usage Note 2.1.3 only applies when the RESETn signal is asserted. The way I read this Usage Note is that when your application is running and you apply RESETn, when the DM648 comes out of reset it may be in a deadlock and may not be able to run until you assert PORn.

I am not sure why there is a relationship between this Usage Note and your "infinite loop of CSL". Can you please explain why you have drawn that conclusion? This must be a very subtle way to hit this particular deadlock condition. Most deadlocks would result in nothing happening in the chip at all, including starting the program to run after RESETn is released.

If you are asserting RESETn and then experiencing this deadlock, then the only solution is what is described in Usage Note 2.1.3 which is to assert PORn.

If you are in an infinite loop in CSL code, then you can halt the DSP in Code Composer Studio to inspect the status and can change the program behavior or PC location. If you are in a deadlock, you usually cannot get control using CCS. I have not debugged this particular issue, but that is true for other deadlock situations I have encountered in the past.

I look forward to hearing about your success with the timer/WDT implementation. You may want to send the timer output to PORn if it is this Usage Note that you must recover from. Otherwise, RESETn will be fine.

Hello Randy

I had started following your advice regarding WDT implemented by using 64-bit timer in DM648 but before i could try it I found this post

Watchdog timer reset issue in DM648

 http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/p/7057/27440.aspx#27440

by your fellow TI employee which clearly forbids us that WDT implementation in DM648 is not possible and its useless to try to implement it. Please read it so that iI can confirm that I am right and its not worthy to try implementing the WDT. Moreover I still have no idea how to get out of my infinite CSL loop problem. Please help me out on this with some other helpful reply.

Also I want to tell you that I am planning to change the value in the program counter(PC) so that it might bring the DSP out of the CSL loop, so please tell me if you know any automated method to change PC value back to the starting value.

Thanks

Danish

I am very glad to see you finding relevant threads in the E2E Forum.

The thread you mentioned explains that there is not a WDT implemented in the DM648. That is what you and I discovered when we read the Timer User's Guide and found no mention of WDT functionality. Some C64x+ devices do have a timer mode that implements a watchdog timer, but this was not implemented in the DM648 and was removed from the documentation that you and I read.

That will not stop you from implementing the same type of functionality in a different way. You will not be able to make a robust WDT like the one in the other C64x+ devices, but you should be able to make one that will reset your device using a standard timer and external wiring from the timer output to the RESETn or PORn pin.

I still have questions, listed in my previous posts, as to why you believe you are hitting this errata issue or why you think you are in a an infinite CSL loop. Those are unrelated issues, and they could require different solutions, although a forced PORn would terminate either.

If you are stuck in an infinite loop, it is either because you are waiting on an event to occur or because you have hit an error and gone through an abort procedure.

My recommendation is to do more debug of your application to figure out why you are hitting the problem that you are hitting. But if you are determined to implement the WDT-like functionality, you still can.

The only ways to change the value in PC is through an unmasked interrupt or an NMI or a pin-induced reset. The reset is the only option for the deadlock condition.

Why do you think you are in the deadlock condition from the errata?

Why do you think you are in an infinite CSL loop?

Thank you Randy for such a detailed analysis of my problem.

I am aware of the solution regarding sort of WDT implementation but currently searching for some better alternative. To the questions you raised I relate to you the following background of the problem I am using NDK 2.0 for Ethernet link. After few hrs of correct operation the DSP halts when I stop the program in CCS and check the status of code execution I always found that my code is struck in CSL loop and it doesnt returns thats why I call it infinite CSL loop. Moreove there is no error in my code and also that no peripheral event is awaited I am saying this because the DSP halts after 5 hrs of correct operation so the only possible conclusion is that Silicon Errata states that the Ethernet Switch Subsystem goes in a deadlock, it is likely the same sort of situation. So i think now you would be pretty clear about the reason of my conclusion. When I manually change the PC value to the starting value when the code is struck in CSL loop the DSP comes out of the halt situation. So therfore I would like to implement NMI for this to make it automatic. But being a newbie I figure out that I cannot do so easily without help therefore would like if u guide me about that.

Thanks

Danish

Mark Depp said:

After few hrs of correct operation the DSP halts when I stop the program in CCS and check the status of code execution I always found that my code is struck in CSL loop and it doesnt returns thats why I call it infinite CSL loop.

Can you provide a snippet of C code to show where the execution is stuck, please? The missing punctuation makes the sentence above slightly ambiguous, so my apologies if I misinterpret what you are describing. When you stop the program in CCS, can you get a stack frame (View Stack) to see which task or ISR is executing? If so, it should be easy to move up to the C code level to find that, or you may have a much better way to show the code where the DSP is in a loop.

Mark Depp said:

the DSP halts after 5 hrs of correct operation

Do you have Ethernet bus analysis equipment or other knowledge of the exact bus transactions to tell you what activity was on the bus prior to the DSP entering this loop? Is there any correlation to the data or packets and the failure? With what is the Ethernet bus communicating?

Mark Depp said:

the only possible conclusion is that Silicon Errata states that the Ethernet Switch Subsystem goes in a deadlock, it is likely the same sort of situation

Usage Note 2.1.3 only applies immediately after the RESETn signal is asserted. You have been running for 5 hours since the last RESETn.
A deadlock cannot be recovered with CCS nor by an NMI or other interrupt. You have full access and control with CCS and can recover by changing the PC.
Therefore, this Usage Note 2.1.3 is not the problem you have encountered nor have you discovered a new deadlock condition.

Mark Depp said:

I would like to implement NMI for this to make it automatic.

Since you have dismissed the idea of implementing a sort of WDT, please explain what you mean by "automatic".

Do you have an indicator LED on your board for debug purposes? Or is there a GPIO that you can access? If so, please try (for evaluation purposes) to create a PRD function that toggles the LED or GPIO once per second or so. When the Ethernet failure occurs, please report whether that LED or GPIO continues to toggle. This might lead to an easier way to implement your NMI or WDT for recovery.

Thank you for your reply

Sorry for this late reply actually I was on leave. I read your post and is preparing a thorough answer which can relate to all your questions. Meanwhile I want to tell you that the root cause of all my problem is that I m using NDK 2.0 and the problem starts when I see the packets received through Ethernet in the DSP memory but is unable to route them back out of the DSP through Ethernet port. Can you give me any idea or code example for this.

Regards

Mark J Depp

For support on NDK 2.0 issues, your best solution is to post a new thread to the BIOS forum under Embedded Software. If there are code examples available, they will be best known to the people supporting that forum. And there could be some helpful postings there already, so be sure to search there and in the TI Wiki Pages for existing information on NDK.

E00C55A8          C$L1:
E00C55A8 0002A120            BNOP.S1       C$L1 (PC+8 = 0xe00c55a8),5
E00C55AC 00000000            NOP          
E00C55B0 00000000            NOP          
E00C55B4 00000000            NOP          
E00C55B8 00000000            NOP          
E00C55BC 00000000            NOP          
E00C55C0          _STS_set:
E00C55C0 000C0362            B.S2          B3
E00C55C4 02102076            STW.D1T2      B4,*-A4[1]
E00C55C8 00006000            NOP           4
E00C55CC 00000000            NOP          
E00C55D0 00000000            NOP          
E00C55D4 00000000            NOP          
E00C55D8 00000000            NOP          
E00C55DC 00000000            NOP 

When my code goes in to halted situation I pause the CCS and found that I m stuck in the above loop. Can i get out of the above loop by any means? Any specific reason of getting stuck  in the above loop?

Where is the Program Counter when you halt? I can assume the C$L1 Branch-to-itself, but there are two Branch instructions shown.

Scroll up in the Disassembly Window to find a meaningful label and to see what code is capable of passing to this point of Branching to this point. And to find out what function this may be.

If interrupts are globally enabled (GIE=1) then any individually enabled interrupt can get you out of any running code loop. Also, NMI can get you out regardless of the GIE and IER settings. And of course Reset, but that is much more intrusive.

I have the same problem, and the details as follow:

Problem:
(1) After correctly running for a few hours, the commucation will stop.
(2) When stopped, the routine will goto a infinite loop, from SYS_Abort -> UTL_doAbort, by HAL routine "CPSW_MACINVECTOR_HOSTPEND".
(3) And at this time, I always found register DMASTATUS -> RX_HOST_ERR_CODE = 0010, it means "OWNERSHIP bit not set in input buffer".
(4) Because the ethernet HAL codes is very complex, I cannot trace the routine.

Hardware:
(1) DM648 with single PHY on SGMII0;

Software:
(1) I've tested NDK1.92/1.94/2.00/2.01, found the same problem.

There are many engineers to ask the similar problem in the internet. I suspect that it is a bug, which could be found only after long time testing.
I've been puzzled about months, and I need your help.
My email: david@machinevision.cn

Thank you.

xiudong shi,

Will you please re-post your post above onto the BIOS forum at http://e2e.ti.com/support/embedded/f/355.aspx ? If this is a bug or has any solution within the NDK, this is where the best people will be most likely to see it.

Please include a link back to this thread so they can refer to it for additional information.

Regards,
RandyP

 RandyP i have emailed NDK people at TI many times and also posted my problem on BIOS forum but in vain. By xiundong shi's post you can imagine that not only me but other people are also facing the similar problem, and it has become recursive you please internally at TI do something for this.

Also to answer your earlier questions here is what i have

Below is the situation i found when the code was halted, the PC is at E00C0228. As far as branching point is concerned it is not traceable because when the code stucks you cannot do anything to trace. Moreover my code is also halted just after the point which earlier mentioned meaning that we have a similar situation. As far as GIE is concerned please provide some documentation from which i can learn how to implement it.

55750434   PRD: end

55750435   SWI: end   PRD_swi (0xe00cfccc) state = done

55750436   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55750437   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

55750438   CLK: current time = 10587221 (0x00a18c55)

55750439   PRD: tick count = 10587221 (0x00a18c55)

55750440   SWI: post  KNL_swi (TSK scheduler) (0xe00cfca0)

55750441   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55750442   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

55750443   CLK: current time = 10587222 (0x00a18c56)

55750444   PRD: tick count = 10587222 (0x00a18c56)

55750445   SWI: post  KNL_swi (TSK scheduler) (0xe00cfca0)

55750446   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55750447   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

55754042   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55754043   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

55754044   CLK: current time = 10588112 (0x00a18fd0)

55754045   PRD: tick count = 10588112 (0x00a18fd0)

55754046   SWI: post  PRD_swi (0xe00cfccc)

55754047   SWI: post  KNL_swi (TSK scheduler) (0xe00cfca0)

55754048   SWI: begin PRD_swi (0xe00cfccc)

55754049   PRD: end

55754050   SWI: end   PRD_swi (0xe00cfccc) state = done

55754051   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55754052   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

55754053   CLK: current time = 10588113 (0x00a18fd1)

55754054   PRD: tick count = 10588113 (0x00a18fd1)

55754055   SWI: post  KNL_swi (TSK scheduler) (0xe00cfca0)

55754056   SWI: begin KNL_swi (TSK scheduler) (0xe00cfca0)

55754057   SWI: end   KNL_swi (TSK scheduler) (0xe00cfca0) state = done

xiudong shi said:

I have the same problem, and the details as follow:

Problem:
(1) After correctly running for a few hours, the commucation will stop.
(2) When stopped, the routine will goto a infinite loop, from SYS_Abort -> UTL_doAbort, by HAL routine "CPSW_MACINVECTOR_HOSTPEND".
(3) And at this time, I always found register DMASTATUS -> RX_HOST_ERR_CODE = 0010, it means "OWNERSHIP bit not set in input buffer".
(4) Because the ethernet HAL codes is very complex, I cannot trace the routine.

Hardware:
(1) DM648 with single PHY on SGMII0;

Software:
(1) I've tested NDK1.92/1.94/2.00/2.01, found the same problem.

There are many engineers to ask the similar problem in the internet. I suspect that it is a bug, which could be found only after long time testing.
I've been puzzled about months, and I need your help.
My email: david@machinevision.cn

Thank you.

Hi peichen dong,

This may be due to a known bug in the DM648 Ethernet driver, although it's certainly possibly that it is another problem.  In any case, I recommend that you apply the following patch to the DM648 Ethernet driver:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ndk/2_00_00/index_FDS.html

Please give that a try.

Steve