TMS320VC5509A 连接不上仿真器问题查找及归纳

Jacktang

TMS320VC5509A 连接不上仿真器问题查找及归纳 [复制链接]

       在调试5509A程序时发现连接不上仿真器，但换块板子可以，花了一段时间才解决了这个问题，记录下测试过程，并对连不上仿真器的问题进行总结，以便以后碰到此类问题快速解决。

1、问题出现

在调试5509A程序时，CCS软件突然卡死并且断电后连不上仿真器，报错如下

Error connecting to the target: 
Error 0x80000242/-1143 
Fatal Error during: Memory, Initialization, OCS, The memory at 0x000000BE continually indicated it was 'not ready' All memory operations currently in progress were aborted in order to regain control of the processor.
This is considered a catastrophic event, but the debugger should still be able to access memory and CPU registers.
System state has been altered.  It is strongly advised that the processor should be reset before resuming execution,
Sequence ID: 0 
Error Code: -1143 
Error Class: 0x80000242
Board Name: C5509 XDS560 Emulator       Cpu Name: CPU_1

2、尝试解决

2.1 插拔仿真器和电路板电源

一般连接不上仿真器，可能是CPU程序运行有问题了，或者仿真器接口信号不稳定导致的，重新插拔仿真器，重新给电路板上电，就能解决了，但是尝试了很多次发现，并没有什么效果。

2.2 电路板是否正常

 

在论坛上询问，他们建议我“先检查一下CLKIN, RESET信号以及供电电压是否正常？CLKOUT管脚是否有时钟输出，看VC5509A有没有跑起来？”，看来是怀疑电路板设计及焊接问题了，那就测量下，发现电路板供电和信号都正常。

2.3 测量JTAG口的信号

电路板是正常的，那么连接不上仿真器是否是JTAG口的问题呢？再测量下JTAG口的管脚信号

查看文档并测量信号，发现是正常的

2.4 论坛提问

因为我调的程序是烧写EEPROM和SD卡的程序，程序是关于二次引导的内容的，那么是否在调试程序时将DSP弄坏了呢？在论坛上提问，但都觉得是我的电路板的问题。

3、问题解决

在TI的技术E2E™ support forums上提问，终于找到了问题所在，问题是我调试的程序下载到EEPROM后，电路板上电从EEPROM中加载程序并运行，由于运行的程序有问题，DSP被锁住了，每次上电都自动运行程序，然后DSP被锁住。锁住时，DSP就连接不上仿真器了，那么只要更改DSP的bootloader方式，让他上电不从EEPROM中加载程序，DSP就不会锁住，就可以连接仿真器了。
 

The description of this error changed over the years, and you can see a brief discussion about it in the section "Device Hung" in the Debugging JTAG page below (search for the error number):

http://software-dl.ti.com/ccs/esd/documents/ccs_debugging_jtag_connectivity_issues.html

The major issue that may be happening with your new code is that it is causing the device to be locked - usually via a memory bus contention or error that is causing the read or write operation to never complete - thus the message mentions the memory is "not ready". This error message indicates the Debug Probe and the JTAG communications with the device are fine and should be at the correct voltage levels.

The faulty memory address (0xBE) is part of the MMR region and therefore should not be accessed directly by the CPU. Table 3-21 of the device's datasheet does not show any valid register allocated to this address, but something on the code is trying to access it. 

Since I don't have access to your environment, I can only offer some suggestions.

However, one detail that is very uncommon in your setup is the inability to connect to the boards that went through this procedure.

One possible explanation is that the faulty software is loaded to a flash memory on the board, which immediately starts executing its faulty routines and locks up the device. In this case you would need to erase the flash memory on the board or change the boot mode of the device to properly debug this software. 

One additional detail to check is PLL or clock configurations - if the device's PLL is misconfigured starting at a certain point on its execution, this could cause access or control issues by the Debug Probe. 

The most critical scenario would be if the faulty software somehow changed the device configuration and caused some damage to an external interface. This is highly unlikely, unless the peripheral that interfaces with the memory is being re-configured as a GPIO and its pins are suffering excessive current or voltage. 

Hope this helps,