• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 53 subscribers
  • Views 1464 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.

Issue on dm648 and XDS510

RaúlSánchez Siles
Prodigy 160 points


Hello:

We created our custom DM648 based board. We took the development kit and stripped things like ethernet and pci bridge. We kept the rest and fundamental parts as close as possible, mostly the same. We are trying to setup the board to start software development, but we are having trouble with the JTAG part.

We installed the XDS510USB plus drivers from the lyrtech web, setup up CCS3.3(SR11) with the lyrtech provided "CCS SD510USB_EVMDM648.ccs" script file which makes CCS adds a chain like this: "SD510USB - DM658 Emulator"->DM648_0->ICEPICK_C_0->DSP->C6400PLUS_0" where the driver used is the sdgo6400usb_plus.dvr file

With this configuration we can connect to jtag to the target but connection is very unstable. Devices are configured with the GEL file and we can inspect memory and other internal register space sometimes. We even got to load a simple memory test program which executes successfully. But as soon as we try to run more complex applications jtag communication seems to break. The simpler case is when we write to memory. CCS pops up a dialog with this error:

"""

Trouble Halting Target CPU:
Error 0x00000020/-1202
Error during: Execution,

CPU pipeline is stalled and the CPU is 'not ready'. This means
that the CPU has performed an access which has not
completed, and the CPU is waiting. The target may need to be
reset. The user can choose 'Yes' to force the CPU to be 'ready'.
When this is done, the user will have the ability to examine
the target memory and registers to determine the cause of the
CPU stall. If CPU hang is caused by application and it has been
forced to be 'ready', the CPU should not be run without a reset.

  Yes        - force CPU ready (might corrupt the code)
  Disconnect    - disconnect CCS so that it can be reset
  Retry        - attempt the command again
"""

Sometimes we choose Yes and we can carry on, some others not. Most of the times we need to reset the DM648 and try again to go on. The furthest we got was being able to debug the memory test application step by step, placing breakpoints, but little more from that.

Another error we got in the same style is this:

"""

Trouble Reading Memory Block at 0xe0000000 on Page 0 of Length 0x158:
Error 0x00000002/-1202
Error during: Memory,

"""

This is a regular (working) GEL output excerpt:

"""

Connecting Target...
Setup Cache...
L1P = 32K   L1D = 32K   L2 = ALL SRAM  
Setup Cache... Done.
PLL1 Setup...
PLL1 Setup for DSP @ 810 MHz, SYSCLK2 = 202.5 MHz, SYSCLK4 = 202.5 MHz.
PLL1 Setup... Done.
Power on all PSC modules and DSP domains...
In DVR mode.
Power on all PSC modules and DSP domains... Done.
DDR2 Setup for 32 bits DDR @ 260.0 MHz...
DDR2 Setup... Done.
Set Board and DSP Pin Mux...

"""

We then try to make dbgjtag application run to get more info about the issue, like this: "dbgjtag -f brddat\ccBrd0.dat -rv -T observe"
"""
-----[Print the reset-command software log-file]-----------------------

This utility has selected an XDS510 class product.
This utility will load the adapter 'xds510.dll'.
This utility will operate on port address '0x0240'.
The controller does not use a programmable FPGA.

An error occurred while hard opening the controller.

-----[An error has occurred and this utility has aborted]--------------

This error is generated by TI's USCIF driver.

The value is '-180' (0xffffff4c).
The title is 'SC_ERR_CTL_NO_TRG_POWER'.

The explanation is:
The controller has detected a target power loss.
The user must turn-on or connect the power supply for the target.
"""

We get the same error on all dbgjtag commands we have issued so far.

We also tried changing CCS setup to use the c64xxplus_xds510_0x240.ccs script so we got a chain like this: "C64xx+ XDS510 Emulator->C6400PLUS_0" using tixds6400_plus.dvr which leads CCS to the same error message as above just inside CCS when we try to connect to the target.

We tested that PD pin in the JTAG connector provides the 3.3V for VCC, it does. We suspected also about DDR memory controller misconfiguration but we double checked them and since the memory works when jtag is not broken we assume it's valid. Besides when we try to connect to target, the GEL initialization procedure fails when trying to program DDR controller registers which are not on RAM, so this is a point against JTAG.

Needless to say that we followed the regular connection steps power cycling target, JTAG emulator, CCS and even the whole host machine.

Is the jtag chain configuration correct for the DM648 and XDS510USB plus? Could anyone provide ideas on how to debug the situation and getting what's needed to be fixed?

Thanks.

  • 0
    Genius 4530 points

    Hi,

    The fact that the drivers are getting loaded properly indicates a hardware problem, possibly.

    Are you sure that your clock or other signals on JTAG dont have high-valued resistors in series? or high-valued pull-ups on VCC?

    Regards,

    Sidharth

  • 0 in reply to Sid
    Prodigy 160 points

    Hello Sidhart, Thanks for your comments.
    The JTAG part is based on the JTAG schematic in development kit. Series resistors are 42.2Ohm which you find there, some OR gates to mask clocks when emulator is not connected(plus 33Ohm for TCK and TCKRET) and just a GND pull-up for the connector to detect actual connection.
    Regards,

  • 0 in reply to RaúlSánchez Siles
    Prodigy 160 points

    Following the investigation, look the problem is more bound to DDR setup. I went to the L2 cache zone and tried writing there from Code Composer. I had no problems writing there, and CPU pipeline message didn't appear so far.

    I manage to get the DSP stabilized when I do a RAM write, get the pipeline stalled message, pressing yes and waiting for some seconds. After this RAM looks responsive. I then load an application to ram and start debugging. I start from the CINT_00 code (I think it's the reset int vector). I trace step by step and when I get to this instruction:

    {{{E5BA84C4 01C28162            ADDKPC.S2     0xE5BA83C8 (PC-248 = 0xe5ba83c8),B3,4}}}

    On the second trace try I go back to the Rom bootloader code, which I soppose means a reset or any kind of exception. I'm trying to find out what this exactly means inspecting the interrupt controller registers.

    By the way, the DDR controller register values are:

    SDCFG: 0x00530A32
    SDRFC: 0x000003F6
    SDTIM1: 0x42DB5399
    SDTIM2: 0x0123C722
    BPRIO: 0x000000FF
    DMCCTL: 0x50006406

    Mind that we are using an industrial range RAM, (2x)MT47H64M16HR-3 IT with 5 CAS latency. We are using the same GEL code as the development kit provides, with the timing parameters needed in this case. We tried the same configuration with 4CL. DDR clock is 26MHz.

    Any other ideas?

    Thanks in advance.

    Pd.: maybe this topic doesn't belong to the Code Composer section anymore.

  • 0 in reply to RaúlSánchez Siles
    Genius 4530 points

    Hi,

    One more question,

    Are you getting this error when building/linking your program?

    If yes, post your cmd file here too

    Regards,

    Sidharth

  • 0 in reply to Sid
    Prodigy 160 points

    Hello Sidarth:

    In fact the error is not related to building or linking the smal testing app, but just when I connect jtag. I mean it's the execution that fails.

    Regards,

  • 0 in reply to RaúlSánchez Siles
    Genius 4530 points

    Hi,

    I agree that execution fails on connecting jtag.

    but cmd file defines the memory sections where different elements of the code like block symbols, temporary variables, etc. will be stored during code execution.

    Overwriting one of the memories with the other can even generate an invliad breakpoint resulting in an error as suggested by you above.

    Regards,

    Sidharth

  • 0 in reply to Sid
    Prodigy 160 points

    Hello,

    I understand your point now, but I'm afraid that's not the problem. This is the section layout for the linker:

    MEMORY
    {
        L2RAM        org=0x00A00000 len=0x00040000 /* L2 RAM/Cache */
        L1P_CACHE1    org=0x00E00000 len=0x00006000 /* L1P RAM/cache */
        L1P_CACHE2    org=0x00E06000 len=0x00001C00 /* L1P RAM/cache */
        L1D_CACHE1    org=0x00F00000 len=0x00006000 /* L1D RAM */
        L1D_CACHE2    org=0x00F06000 len=0x00001C00 /* L1D RAM */
        L1_STACK    org=0x00F07C00 len=0x00000400 /* STACK in L1D */
        DRAM        org=0xE0000000 len=0x10000000 /* DDR RAM */
        AEMIF        org=0xA0000000 len=0x08000000 /* AEMIF CS2 region */
    }

    SECTIONS
    {
        .text       > L2RAM
        .const      > L2RAM
        .bss        > L2RAM
        .far        > L2RAM
        .switch        > L2RAM
        .stack      > L2RAM
        .data       > L2RAM
        .cinit        > L2RAM
        .sysmem        > L2RAM
        .cio        > L2RAM
        .ddr_mem    > DRAM
        .aemif_mem  > AEMIF
    }

     

    Regards,

  • 0 in reply to RaúlSánchez Siles
    Prodigy 160 points

    Hello:

    I think we get the reason why we had those problems. The cpu pipeline stall looks a problem with the gel, but more exactly the reason is quite related to enabling EMIF when it was not present. Specificly this was the piece of code we removed to get the board finally working:

    Set_BEmif( int bus_width )
    {
        GEL_TextOut( "EMIFB setup ( %d bits bus )... \n",,,,, bus_width );

        // Only in DVR mode
        if( BOOTCFG & 0x40000)
        {
            // Gives power to emif3b just in case
            Set_PSC_State(PD0, LPSC_EMIFB, PSC_ENABLE);

            if (bus_width == 8)
            {
                // Configure async EMIF 8 bits, max wait cycles
                EMIFB_CE2CFG = 0x0FFFFFFC;
                EMIFB_CE3CFG = 0x0FFFFFFC;
            }
            else
            {
                // Configure async EMIF 16 bits, max wait cycles
                EMIFB_CE2CFG = 0x00310181;
                EMIFB_CE3CFG = 0x0FFFFFFD;
            }

            // Adjust TA for flash mem
            EMIFB_AWCC = 0x40000380;
        }
        else
        {
            GEL_TextOut( "Not available in non DVR mode. \n" );
        }

        GEL_TextOut( "EMIFB setup... Done.\n" );
    }

     

    I would still appreciate if someone could explain why this code stalls pipeline when EMIF is not present. Altought it's quite sensible not enabling EMIF when it's not present, I don't see a clear reason why the stalls happen.

    Regards,