Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 53 subscribers
  • Views 689 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: In the programming and debugging of DSP5509A, will the DSP be damaged internally, so that the simulator cannot be connected?

user4731232
Prodigy 20 points

Tool/software: Code Composer Studio

Now I am programming with the company's 5509A board, which has been steadily produced and sold as a product for 6 years. Now I need to modify some functions.

The function I debuged is write code to i2c EEPROM(code in it is to secondary boot from SD) and SD card.CCS software stuck twice when I running the program, after I restart software and recharge the circuit boards, the simulator cannot be connected (it cannot be connected after repeated attempts).It is ok to change a board.Due to this unknown problem, I have made the two boards cannot be connected to the simulator (I don't know how to fix the two boards).

It can be sure that  the emulator is ok(Other same boards can be connecter),and the design of circuit board is ok(This circuit board is under stable production and sales).what I am not sure about is what's wrong with the circuit board right now(Is the DSP broken?is the JTAG  broken?).All I do is to modify the code and debug it,I feel that there will be no problem with JTAG circuit.I want to know will the debugger break DSP internals?

I need suggestions for what I should to test the circuit board,Do I need to measure the voltage of JTAG port?What is the voltage normal if I need to measure the voltage of JTAG port.

Here is my current working environment: CCS 3.3 and xds560

The information that the emulator cannot be connected: 

 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

  • 0
    TI__Guru**** 169224 points

    Hi,

    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,

    Rafael

  • 0 in reply to desouza
    Prodigy 20 points

    Thank you very much！I can connect the emulator by changing the way of bootloader.