TMS320C6455 starting over PCI problem

Hi Andrew,

Do you load the program to L2 SRAM starting from 0x0080 0000? By default, the CPU will run the code at the beginning of L2. If you place the code to the other offset, you may need to change the vector table (interrupt service table).

The threads as follows may give you some helpful hints:

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/60141/219708.aspx#219708

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/112/p/48692/199298.aspx?PageIndex=1

Sincerely,

Steven

Yes. I chek content of L2 memory - it is identical in both cases, with emulator and throught the HOST.

Thank You, Steeven, for links, I read them. I think there are not my cases. First link tell about vector tables, but program works fine with emulator, so I think vector tables ok. Right?

Second link is about I2C boot, I use PCI boot.

Sincerely, Andrew.

Andrew Chashinoff said:

I chek content of L2 memory - it is identical in both cases, with emulator and throught the HOST.

This is an excellent data point because it tells us that the PCI download process is correct. The two remaining components are:

1. Identical peripheral configuration. This is handled by a GEL file in many cases when using the emulator and must be done by the PCI host during the download process or by the downloaded code. To eliminate this possibility, remove the GEL file from your emulation testing then reset the board, connect the emulator, download the program, and run it. Be sure to turn off the automatic Go Main feature, too. Also, not the address where the cursor is after the download step and before you start to run - tell us what this address is and what label is there, if any.
2. Entry point. CCS sets the entry point from a value in the .out file and will always put the PC there once you have downloaded the program. With PCI boot, the PC is set to 0x00800000, so the entry point or the interrupt vector table needs to be at 0x00800000. The interrupt vector table starts with a branch to the reset vector which is usually _c_int00, and this is why the interrupt vector table being at 0x00800000 makes things work, too.

Andrew Chashinoff said:

Thank You, Steeven, for links, I read them. I think there are not my cases. First link tell about vector tables, but program works fine with emulator, so I think vector tables ok. Right?

Perhaps with what I tried to explain above you will understand why those two links may be exactly what you need. They very likely are exactly your cases. Please reread my post at the end of the first link and read the app note that I referenced there.

Andrew Chashinoff said:

Second link is about I2C boot, I use PCI boot.

The second link takes you to a long thread that includes a post from Bernhard W on Jul 13, 2010, that includes an attachment named Pci6455.zip - that sounds very relevant to your case, right? Maybe it is not, but it is certainly worth considering.

Regards,
RandyP

If this, or the related links, answers your question, please click the  Verify Answer  button below. If not, please reply back with more information.

Thank You for help, Randy.

The problem was caused by interrupt table missing. I don't know that an emulator can start code from anything address. Now all ok.