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.

CCS3.3 menu command 'reset' and 'restart' could restore the CPU to initial state completely?

My target is DM648, with the development of CCS3.3 + SR11 + code generation tools 7.0.4.

Now we have a algorithm running on my target. If we have target board power down and power up again, download the program through emulator, the CPU load averages to 22% when the algorithm is running freely. Then if we 'halt', 'reset' and 'restart' using CCS menu command, restarted algorithm will run again, but the CPU load increase to 91%.

I think the menu command 'reset' and 'restart' could not restore all the necessary resources on the chip. There must be something is missing probably.

 

  • Hi,

    This behaviour is heavily dependent on the device, but one of the details that may be happening in your case is incomplete peripheral initialization. In a typical CCS debug environment, a great deal of hardware initialization is performed by GEL scripts that configure PLLs, the EMIF, PINMUX, etc at the moment the target is connected. Therefore issuing a simple Reset from the CCS screen may cause the peripherals to run at its reset values and, particularly to the EMIF, its speed can be greatly reduced due to waitstates.

    The same scenario can happen with external devices connected to the DSP peripherals - I used to experience slowdowns on the Ethernet communications after a reset, caused by incomplete initialization of the external PHY of older DM648 EVM boards.  

    Therefore during the debug phase I usually do a disconnect --> hard reset on the board (by reset button or power cycle) --> connect. When testing for production you must copy the GEL script source code entirely to your project and thus perform complete hardware initialization.

    Hope this helps,

    Rafael

     

  • Depending on the CCS version and device specific support, the debug driver may implement two different resets:

    1. CPU Reset (SW) is, as the name implies, a software reset of the cpu. It sets the CPSR to supv mode, and sets the PC to the reset vector. It is quite deterministic.

    2. CPU Reset (HW) is, in this case, an Icecrusher hardware reset. The behavior is completely controlled by which subsystems the design team tied to the icecrusher reset.

    The software reset will not complete reset the hardware logic. You would need to follow Rafel's recommendation from his post. 

    You can refer to the following post for more details.

    https://myportal.ti.com:443/portal/dt?provider=TIPassLoginSingleContainer&lt=myti&j5=2&j3=1&goto=https%3A%2F%2Ffedid.ext.ti.com%3A443%2Ffedout%2Fe2e%2Findex.cgi

     

    Regards,

    Ning

  • The link in your post:

    https://myportal.ti.com:443/portal/dt?provider=TIPassLoginSingleContainer&lt=myti&j5=2&j3=1&goto=https%3A%2F%2Ffedid.ext.ti.com%3A443%2Ffedout%2Fe2e%2Findex.cgi

    will lead me to login first and then to e2e.ti.com finally, and I could not found the recommendations by Rafel.

    Can you please check it?

  • Hi Rafael,      I have some more information on this topic.      When my system is running without my algorithm (just bypass my algorithm), reset/restart will success all the time. And if I firstly bypass my algorithm and then download the original program(with my algorithm), and it could still success. However once I run the original program, and then reset/restart could not get the original program working ever.   Since my algorithm just uses DSP core only(pure C program, not using EDMA or other peripherals, just the DSP core), and I can see that the basic system (VPort, VICP, Ethernet, EDMA) could be reset/restart successfully, why it could fail if pulsing my algorithm? I have added cache initialization at my program entry point, what else should I pay attention to?      It is a very rare thing, and I need some more advice. Thank you!