• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 96 subscribers
  • Views 690 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 error connecting to DM6443

Andreas Maier
Prodigy 100 points

Hello,

I'm quite new to this subject, so I hope you can help me:

We developed a board based on DM6443. We got it working but now it does not respond at all. We got the message:

Error connecting to the target:
Error 0x80000244/-2131
Fatal Error during: Register, Initialization, OCS, 
Cannot access register at 0x00000000

Sequence ID: 0
Error Code: -2131
Error Class: 0x80000244

We use Code Composer Studio v3.3 and JTAG Emulator XDS560

I guess maybe some instruction in the GEL Files caused an error. I used davincievm_arm.gel and davincievm_dsp.gel  from Spectrum Digital. The difference between our board and the EVM is a different DDR2-SDRAM and different NAND-Flash, also we use a SRAM on CS3.

I also changed the instructions in these GEL-files to match our memory devices but this makes no difference.

Thanks in advance,

Andreas

  • 0
    Prodigy 100 points

    Hello,

    I just tried interfacing via UART0 and DVFlasher. Erasing the NAND seems to work:

    -----------------------------------------------------
      TI DVFlasher Host Program for DM644x
      (C) 2007, Texas Instruments, Inc.
    -----------------------------------------------------


    Platform is Windows.
    Globally erasing NAND flash.


    Attempting to connect to device COM1...
    Press any key to end this program at any time.


    Waiting for DVEVM...
    BOOTME commmand received. Returning ACK and header...
    ACK command sent. Waiting for BEGIN command...
      DVEVM: BEGIN
    BEGIN commmand received. Sending CRC table...
    CRC table sent. Waiting for DONE...
    DONE received. Sending the UART UBL file...
    DONE received. UART UBL file was accepted.
    UART UBL Transmitted successfully.

      DVEVM: TI UBL Version: 1.143, Flash type: NAND
      DVEVM: Booting PSP Boot Loader
      DVEVM: PSPBootMode = UART

    Waiting for UBL on DVEVM...
    UBL's BOOTPSP commmand received. Returning CMD and command...
    CMD value sent.
      DVEVM: Initializing NAND flash...
      DVEVM: Manufacturer ID = 0x00000020
      DVEVM: Device ID = 0x000000A1
      DVEVM: Pages Per Block = 0x00000040
      DVEVM: Number of Blocks = 0x00000400
      DVEVM: Bytes Per Page = 0x00000800
      DVEVM: Unprotecting blocks 0x00000001 through 0x000003FF.
      DVEVM: Erasing blocks 0x00000001 through 0x000003FF.
      DVEVM: Erase completed successfully.
      DVEVM: Protecting the entire NAND flash.
      DVEVM: DONE

    Operation completed successfully.

    When I use the program Serial Flasher erasing doesn't work and when I try to flash an ubl I get:

    -----------------------------------------------------
      TI Serial Flasher Host Program for DM644x
      (C) 2009, Texas Instruments, Inc.
      Ver. 1.50
    -----------------------------------------------------


    Platform is Windows.
    Flashing NAND with ubl_dm644x_nand.bin and u-boot-567-nand.bin.


    Attempting to connect to device COM1...
    Press any key to end this program at any time.


    Waiting for the DM644x...
    BOOTME commmand received. Returning ACK and header...
    ACK command sent. Waiting for BEGIN command...
      Target: BEGIN
    BEGIN commmand received. Sending CRC table...
     100% [ ]
      CRC table sent....



    Waiting for DONE...
    DONE received. Sending the UBL...
     100% [ ]
      UBL sent....


    DONE received. UBL was accepted.
    UBL transmitted successfully.


    Waiting for SFT on the DM644x...
      Target: Starting UART Boot...
      Target: BOOTUBL
    BOOTUBL commmand received. Returning CMD and command...
    CMD value sent. Waiting for DONE...
      Target: DONE
    DONE received. Command was accepted.
    Sending the UBL image
    Waiting for SENDIMG sequence...

     

    Then it waits.

    Hope, this helps. Thanks.

    Andreas

  • 0 in reply to Andreas Maier
    Genius 4530 points

    Hi Andreas,

    Go to the command prompt and go to the specific directory where the emulator drivers are installed.

    type the command dbgjtag (use dbgjtag --help for more options )and try posting the error messages here. It might help in getting to the root of the problem.

    Regards,

    Sid

  • 0 in reply to Sid
    Prodigy 100 points

    Hi Sid,

    thanks for the answer. I played a little with dbgjtag. These are the results:

    This utility has selected an XDS560 class product.
    This utility will load the program 'xds560.out'.
    This utility will operate on port address '0x0'.
    The emulator program is named 'xds560.out'.
    The emulator program is version '35.23.10.2'.
    The controller has a version number of '4' (0x0004).
    The controller has an insertion length of '0' (0x0000).
    The cable+pod has a version number of '6' (0x0006).
    The cable+pod has a capability number of '9' (0x0009).
    The local memory has a base address of '0' (0x000000).
    The local memory has a word capacity of '32768' (0x008000).


    The IR/DR path-length tests used blocks of up-to 512 32-bit words.
    The IR/DR validation tests used blocks of up-to 512 32-bit words.

    The IR/DR scan-path tests used 22 frequencies.
    The IR/DR scan-path tests used 2.250MHz as the maximum frequency.
    The IR/DR scan-path tests used 1.703MHz as the final frequency.

    -----[Measure the source and frequency of the final JTAG TCLKR input]------

    The frequency of the JTAG TCLKR input is measured as 1.702MHz.

    The frequency of the JTAG TCLKR input and TCLKO output signals are similar.
    The target system likely uses the TCLKO output from the emulator PLL.

    -----[Test the source and frequency of the JTAG TCLK]----------------------

    The frequency of the JTAG TCLKR input is measured as 1.701MHz.


    The result of the scan and frequency double test was all question marks (?), only at about 5.5MHz were some zeros (0).
    That looks strange to me.

    The result of the pathlength scan was:

    This scan-path length test uses blocks of 512 32-bit words.

    -----[The results of the scan-path length test on the JTAG IR and DR]------

    The test for the JTAG IR instruction scan-path length succeeded.
    The JTAG IR instruction scan-path length is 14 bits.

    The test for the JTAG DR bypass scan-path length succeeded.
    The JTAG DR bypass scan-path length is 3 bits.

    Is this correct? I read something about DR=1 and IR=4 for ARM9 and IR=38 for C64x+ (sprp603.pdf)

    The brokenpath-test and the integrity-test both said, everything is correct.

    Regards,

    Andreas

  • 0 in reply to Andreas Maier
    Genius 4530 points

    Hi Andreas,

    The results of scan and frequency double test are certainly aberrant from the original expectations.

    Are you using your own custom board?

    The pull-ups/pull-downs/series termination rsistances on JTAG connections like TCK,TDI,TDO might not be correct value. Try checking the same.

    Regards,

    Sid

  • 0 in reply to Sid
    Prodigy 100 points

    Hi Sid,

    I use my own custom board.

    I changed the series resistor in the RTCK line and it worked (successful run of the frequency double test). But when I disconnected the board and started again it was the same problem as before. The frequency of the RTCK is fixed at about 1.8MHz and does not sweep with the TCK.

    Regards,

    Andreas

  • 0 in reply to Andreas Maier
    Genius 4530 points

    Hi Andreas,

    Good to hear about your progress.

    Problem seems to be a hardware issue still.

    Try changing/connecting external pull-ups/series resistances to TDI and TDO.

    Regards,

    Sid

  • 0 in reply to Sid
    Prodigy 100 points

    Hello,

    just in case someone is interested: It was a problem with the level of TRST. Now it works.

    Thanks.

    Andreas

  • 0 in reply to Andreas Maier
    Genius 4530 points

    Hi Andreas,

    Could you elaborate in a little more detail about what you mean be "level of TRST".

    Was it becoming low when accessing the processor?

    How did you overcome this level problem?

    Regards,

    Sid

  • 0 in reply to Sid
    Prodigy 100 points

    I just started examining this problem and yet I can't tell what is the problem.
    I compared the behaviour of the EVM and of my own board with respect to TRSTN:
    When TRSTN has a 2.2k Pull-Up it is high (1.8V) and goes low (0V) for 1ms at the start of the test.
    When TRSTN has a 10k Pull-Down it is low, goes high for 25ms and then low for 1ms.
    While the EVM is working with both configurations, my own board just works with the pull-down resistor.
    I couldn't find any other differences between the signals of both boards.
    If you have any ideas, please tell me. But as it is now working, I will now focus on other aspects.

    Regards,

    Andreas