EINFOCHIPS EVMC6457L and LE, CCS V.5 gel file doesn't work

Will,

Welcome to the TI E2E forum. I hope you will find many good answers here and in the TI.com documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

From the eInfochips.website, it looks like the GEL files are provided through the MCSDK. Please make sure you have the latest version of MCSDK 2 [rp: MCSDK 1 for C64x+  devices] and that you are using the GEL file from that release.

Why do you suspect the GEL file is causing your problems? You can make a local copy to use in your workspace or project folder, and you can edit functions out to eliminate a problem or to narrow down the location.

You should also look at your DIP switch settings and emulator Target Configuration file to make sure everything is set correctly.

Regards,
RandyP

Randy,

      thank you for your response.  I let this sit in the background, but have looked at the problem again.  The gel file breaks down when the Power and Sleep Controller attempts to look at the MDSTAT2 Register to see the current state.  It is always 3, or "Enabled".  It requires repeating two steps to get the failure to occur.  

 1.  "Debug As" your program, the gel file should work and perform the PSC operation without error.  Exit the debug session. 

2.  Again, "Debug As" your program.  The gel file will this time fail with a "Core is Hung" message. 

 If I comment out the call to enable the PSC for EMIF64, I can download as many times as I want and let the gel file set everything up. 

I'm reading a few other posts that people state something similiar--You mentioned in one post to look at the PRCM.  I can't find this register/settings in the documentation. 

Also, the MC SDK 2.0 doesn't appear to be released for the C6457 (a 64x+ processor).  Here is the link I looked at to see what was available for the C6457:  http://www.ti.com/tool/bioslinuxmcsdk 

The documentation states something interesting--I can basically depend on the state of EMIF 64 to be enabled unless its a "never-gated" domain.   When would this occur?  I'm wondering how relevant it would be to a future non-evm board, for a modified gel file and bootloader. 

Thanks,

Here's the code that fails:

Set_PSC_State(unsigned int pd,unsigned int id,unsigned int state)

{

unsigned int* mdctl;

unsigned int* mdstat;

unsigned int* pdctl;

int ret=0;

mdctl = ( unsigned int* )(PSC_MDCTL_BASE + ( 4 * id ));

mdstat = ( unsigned int* )( PSC_MDSTAT_BASE + ( 4 * id ));

pdctl = ( unsigned int* )(PSC_PDCTL_BASE + ( 4 * id ));

// WM: Note: if you put a return statement here, you can run as many times as you like.  This if statement, even broken apart into separate values/components,

// WM: still causes the crashing.  The only remedy is to return from the function before checking the MDCTL reg for EMIF64. 

// If state is already set, do nothing

if ( ( *mdstat & 0x1f ) == state )

{

GEL_TextOut( "Set_PSC_State: mdstat %x\n",,,,, *mdstat);

return(0);

}

William,

What is the name of the GEL file you are using?

William Martin

the MC SDK 2.0 doesn't appear to be released for the C6457 (a 64x+ processor).

No idea what I was thinking. But MCSDK 1.0 is for the C64x+ parts, while MCSDK 2.0 is for the C66x parts. You want MCSDK 1.0, and I edited my post above for this. The Getting Started Guide is here. It only mentions being tested with CCSv4, so I will get this thread moved to the BIOS Forum where they may have the latest information on the MCSDK 1.0.

William Martin

The documentation states something interesting--I can basically depend on the state of EMIF 64 to be enabled unless its a "never-gated" domain.

Please give us some specifics on "the documentation" and where it states what you found interesting. I am thinking the datasheet, but I guess wrong a lot.

Regards,
RandyP

William,

What CCS version are you using? I want to verify we are looking at the same GEL file

Juan,

     Thank you for your response.  We are using version CCS 5.1. 

Will

Hi Will,

Can you try upgrading to CCS 5.2?  Our CCS expert tells me there should be working GEL files for the L/LE eInfochips boards.

Also, please note the caution on this wiki regarding "update" feature on CCS 5.1

Hi Juan, 

     Taking from your note about installs, I uninstalled 5.1 and installed 5.2.  The configuration file I created using the Blackhawk XDS560v2 USB Mezzanine Emulator, using the TMDSEVM6457L Board.  The text box below the board or device selection affirms my selection with this string "eInfochips C6457 Lite EVM Board". 

This creates two devices "Device1" and "ICEPICK_C_0".  The gel file for device 1 is "..\..\emulation\boards\evmc6457l\gel\evmc6457l.gel".  There is no gel file for the ICEPICK choice.    When I connect to the board, it tells me I have to make up my mind and use only one so I choose "device_6", which is the cpu properties selection below "Device 1". 

The error I get when connecting is:  

"Error connecting to the target:
(Error -1265 @ 0x0)
Device ID is not recognized or is not supported by driver. Confirm device and emulator configuration is correct, or update device driver.
(Emulation package 5.0.681.0)

Also, the Gel file that was copied in for Version 5.2's only difference is the Date Time stamp in the comments.  The new one is 30 seconds older than the other.

Is there a chance the file that supposedly fixes this issue can be posted to the forum?  

1805.evmc6457l.gel

 Juan, going a different route--if I use the TMSDC6457 configuration, the outcome is slightly different.  No device ID errors. 

But,

If I dont use a gel file, my program runs (because POST runs first and sets up everything as the I2C EEPROM bootloader)

If I use this a gel file, as specified in the  configuration file below (ccxml), I get this upon loading my program---it goes straight to abort without getting to main().

[C64XP_0] 0xe0100018

A2=0x0 A3=0xe04a77b8

A4=0xe0100078 A5=0xe050e4a4

A6=0xe0507e68 A7=0x1

A8=0x0 A9=0x0

A10=0xe0100078 A11=0x20

A12=0xffff A13=0xe035d898

A14=0xe01b5c1c A15=0xe01b5cc8

A16=0x2 A17=0x0

A18=0xe0507d54 A19=0x20

A20=0xfe A21=0x811a06a2

A22=0x20928416 A2[C64XP_0] 3=0x10381606

A24=0x5090d4d2 A25=0xe01c0c44

A26=0xe01c0c48 A27=0xe01c0c50

A28=0xe01c0c50 A29=0xe01b5c10

A30=0x0 A31=0x0

B0=0x1 B1=0x0

B2=0x1 B3=0xe036e308

B4=0x20 B5=0xe0507ef0

B6=0xe01b5e00 B7=0x0

B8=0x0 B9=0x1

B10=0xe050e4a0 B11=0xe050e4a4

B12=0x30 B13=0x[C64XP_0] 0

B14=0xe05082c8 B15=0xe0507ee0

B16=0xe050e4a0 B17=0xe0507ed8

B18=0x0 B19=0x400

B20=0x0 B21=0x0

B22=0x80 B23=0x2000080

B24=0x81 B25=0x40080

B26=0x0 B27=0xe01c0c44

B28=0xe01c0c48 B29=0x0

B30=0xe01b5c70 B31=0xf

NTSR=0x1000c

ITSR=0x0

IRP=0x0

SSR=0x0

AMR=0x0

R[C64XP_0] ILC=0x0

ILC=0x0

Exception at 0xe04a77b8

EFR=0x2 NRP=0xe04a77b8

Internal exception: IERR=0x2

Fetch packet exception

ti.sysbios.family.c64p.Exception: line 248: E_exceptionMin: pc = 0x00000000, sp = 0xe0507ee0.

xdc.runtime.Error.raise: terminating [C64XP_0] execution

The XML configuration file looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<configurations XML_version="1.2" id="configurations_0">

<configuration XML_version="1.2" id="Blackhawk XDS560v2-USB Mezzanine Emulator_0">

<instance XML_version="1.2" desc="Blackhawk XDS560v2-USB Mezzanine Emulator_0" href="connections/BH-XDS560v2-USB_Mezzanine.xml" id="Blackhawk XDS560v2-USB Mezzanine Emulator_0" xml="BH-XDS560v2-USB_Mezzanine.xml" xmlpath="connections"/>

<connection XML_version="1.2" id="Blackhawk XDS560v2-USB Mezzanine Emulator_0">

<instance XML_version="1.2" href="drivers/tixds560icepick_c.xml" id="drivers" xml="tixds560icepick_c.xml" xmlpath="drivers"/>

<instance XML_version="1.2" href="drivers/tixds560c64xp.xml" id="drivers" xml="tixds560c64xp.xml" xmlpath="drivers"/>

<platform XML_version="1.2" id="platform_0">

<instance XML_version="1.2" desc="TMS320C6457_0" href="devices/C6457.xml" id="TMS320C6457_0" xml="C6457.xml" xmlpath="devices"/>

<device HW_revision="1" XML_version="1.2" description="TMS320C6457 - This configuration contains full peripheral register specifications." id="TMS320C6457_0" partnum="TMS320C6457">

<router HW_revision="1.0" XML_version="1.2" description="ICEPICK_C Router" id="ICEPICK_C_0" isa="ICEPICK_C">

<subpath id="Subpath_1">

<cpu HW_revision="" XML_version="1.2" description="" id="C64XP_0" isa="TMS320C64XP">

<property Type="filepathfield" Value="..\..\..\..\Arbeit\ai3ifs\OFS\build\AI3_CC_MC\GEL_Files\EVM\evmc6457l.gel" id="GEL File"/>

</cpu>

</subpath>

</router>

</device>

</platform>

</connection>

</configuration>

</configurations>

Will,

As you know I have asked our CCS team to look into this.  Just to make sure we are all in the same page, in previous communication you suggested your tried this in Linux and WindowsXP.  What is your ultimate goal or what are you mostly using to report the results above?

Also, I see you are using a BalckHawk 560v2 emulator from the xml file you posted above.  Along with the CCSv5.2 installation, a BH560v2 Config Utilty is included by default to test out your emulator stack is working properly (JTAG properly connected and driver installed correctly).  You may want to run this utilty just to double check and eliminate variables.

Hi Juan,

     The ultimate goal is to have a working configuration for developer's to work with in CCS V.5.1 that would allow configuration of hardware for the EINFOCHIPS C6457 EVM board, which ultimately, would be changed to work with a proprietary board.  

     I probably confused the issue by stating I've tried the updates for the MC SDK which included a linux released version to see if I could get an update to the file and configuration.  We are primarily Windows only.   MC SDK 1.08, with the Keystone Emulator updates. 

     Re:  Connection to board.  I understand your suggestion.  I did roll back to CCS V.5.1 last night because I was getting a set of errors during build with CCS v5.2, that don't happen in my version of CGT for 5.1 (Undefined Symbols for mainly STD library type functions, which is another thread entirely!).   I think they may all be related to the template instantation issue to some varying degree, unless someone knows otherwise. 

    Suffice to say, we can connect to boards as long as we use the POST in EEPROM, which sets up register, and the ccxml isn;t tied to any GEL File.