DSPRelated.com
Forums

6711D memory load

Started by rjed...@gmail.com March 4, 2010
Richard-

> the map file seems fine. we originally developed the device
> using the c6711b but switched to c6711d. the main
> difference is the PLL in the 6711d.
>
> when try to write to memory through ccs, for example, selecting
> a variable in our code, eg NUM = 1 (set in code), when
> displayed in watch window value is something like 0xff000067.
> if we write a different value to NUM such as 2 it does
> not change to that value.
>
> basically it appears that random values appear where code and
> data should be placed. any suggestions?

Sounds like you *had* a nice, working board based on C6711B from 2002 or so time-frame. Is that correct?

What is your CLKOUT value? Most C6711 designs run the SDRAM clock from one of the CLKOUT pins so this would be a
really key thing to measure. Seems to me you didn't check it yet...

As a general note, from a hardware perspective PLL is one of a few major, significant changes from C6711B to C6711D.
It looks to me like you guys need to zoom in on your hardware differences, not software.

-Jeff

>>we have developed an audio application based around the c6711 D dsp. We are using the XDS560 emulator and ccs 2.1.
>> We can successfully load the program onto the audio device through load program on ccs. and when loaded the cursor
>> appears at c_int00. But when the program is run it just goes to a series of nops. When we look at the our c code
>> and and asm generated under the view-> mixed asm option we get:
>>
>>*(int*) PLL_CSR &=~CSR_PLLEN; /*my c code, assembler generated for this instruction by ccs below*/
>>800033D4 1AA43D11 .word 0X1aa43d11
>>800033D8 BFEA3656 .word 0Xbfea3656
>>800033Dc BBE911D2 .word 0Xbbe911d2
>>
>>we can see from above that the TI generated assembler commands are missing and just words at the memory locations We
>> are loading our program into external ram at starting at address 0x800...
>>
>>why cannot we see the underlying assembler? is there something wrong in our EMIF so the program is not loaded
>> correctly into our external SRAM?
>>
>>thanks
>>Richard

_____________________________________
hi

we had a desighn working on the 6711b but have changed to c6711d. we are using a osc at 100 mhz for dsp and 50 mhz for emif. clkout therefore is at 50mhz. we have programmed to bypass the pll, both with gel and on the source code, have checked the correct pins on scope and correct frequenices are there, have also checked the register values and are as expected.

we are using a x560 emulator to debug our hardware. we have tried the many suggestions from the replies. but we find that when debugging when we enter values into memory locations through ccs the values are corrupted usually in the upper 8 bits. how could a problem with pll cause such a problem? unfortunately we are not hardware guys and have a urgent deadline...

cheers
richard

hi
>
>we have developed an audio application based around the c6711 D dsp. We are using the XDS560 emulator and ccs 2.1. We can successfully load the program onto the audio device through load program on ccs. and when loaded the cursor appears at c_int00. But when the program is run it just goes to a series of nops. When we look at the our c code and and asm generated under the view-> mixed asm option we get:
>
>*(int*) PLL_CSR &=~CSR_PLLEN; /*my c code, assembler generated for this instruction by ccs below*/
>800033D4 1AA43D11 .word 0X1aa43d11
>800033D8 BFEA3656 .word 0Xbfea3656
>800033Dc BBE911D2 .word 0Xbbe911d2
>
>we can see from above that the TI generated assembler commands are missing and just words at the memory locations We are loading our program into external ram at starting at address 0x800...
>
>why cannot we see the underlying assembler? is there something wrong in our EMIF so the program is not loaded correctly into our external SRAM?
>
>thanks
>Richard
>
>_____________________________________

_____________________________________
Richard,

All sdram memory takes a certain amount of time for the address to settle, the data to be written, etc.
Most of the time, the CPU is running at a far faster speed than the memory can actually handle.
This speed difference is compensated for by inserting wait states in the SDRAM read and write cycles.
Since you have not indicated that your code is modifying the default wait state values, and you are by-passing the PLL (which limits and stabilizes the actual CPU clock rates)
I suspect the SDRAM needs more wait states added, perhaps both in the read and write cycles.

Is there anything in the errata for the 6711a and 6711d that would have any effect on the external memory I/O communications and/or on the communications with the x560 emulator?

If all that was done was a chip swap between the working system and the failing system, then it has to be because of the differences between the two chips (and the errors in the chips, as outlined in the errata.

R. Williams

---------- Original Message -----------
From: r...@gmail.com
To: c...
Sent: Mon, 08 Mar 2010 07:56:05 -0500
Subject: [c6x] Re: 6711D memory load

>
>
> hi
>
> we had a desighn working on the 6711b but have changed to c6711d. we are using a osc at 100 mhz for dsp and 50 mhz for emif. clkout therefore is at 50mhz. we have programmed to bypass the pll, both with gel and on the source code, have checked the correct pins on scope and correct frequenices are there, have also checked the register values and are as expected.
>
> we are using a x560 emulator to debug our hardware. we have tried the many suggestions from the replies. but we find that when debugging when we enter values into memory locations through ccs the values are corrupted usually in the upper 8 bits. how could a problem with pll cause such a problem? unfortunately we are not hardware guys and have a urgent deadline...
>
> cheers
> richard
>
> hi
> >
> >we have developed an audio application based around the c6711 D dsp. We are using the XDS560 emulator and ccs 2.1. We can successfully load the program onto the audio device through load program on ccs. and when loaded the cursor appears at c_int00. But when the program is run it just goes to a series of nops. When we look at the our c code and and asm generated under the view-> mixed asm option we get:
> >
> >*(int*) PLL_CSR &=~CSR_PLLEN; /*my c code, assembler generated for this instruction by ccs below*/
> >800033D4 1AA43D11 .word 0X1aa43d11
> >800033D8 BFEA3656 .word 0Xbfea3656
> >800033Dc BBE911D2 .word 0Xbbe911d2
> >
> >we can see from above that the TI generated assembler commands are missing and just words at the memory locations We are loading our program into external ram at starting at address 0x800...
> >
> >why cannot we see the underlying assembler? is there something wrong in our EMIF so the program is not loaded correctly into our external SRAM?
> >
> >thanks
> >Richard
> >
> >_____________________________________
> >
> >
------- End of Original Message -------
Richard-

> we had a desighn working on the 6711b but have changed to c6711d. we are using a osc at 100 mhz for dsp and 50 mhz
> for emif. clkout therefore is at 50mhz. we have programmed to bypass the pll, both with gel and on the source code,
> have checked the correct pins on scope and correct frequenices are there, have also checked the register values and
> are as expected.

You're using separate clocks for DSP and EMIF? Why? Did you do this on the C6711B design, or is this a change?

-Jeff

> we are using a x560 emulator to debug our hardware. we have tried the many suggestions from the replies. but we find
> that when debugging when we enter values into memory locations through ccs the values are corrupted usually in the
> upper 8 bits. how could a problem with pll cause such a problem? unfortunately we are not hardware guys and have a
> urgent deadline...
>
> cheers
> richard
>
> hi
>>
>>we have developed an audio application based around the c6711 D dsp. We are using the XDS560 emulator and ccs 2.1.
>> We can successfully load the program onto the audio device through load program on ccs. and when loaded the cursor
>> appears at c_int00. But when the program is run it just goes to a series of nops. When we look at the our c code
>> and and asm generated under the view-> mixed asm option we get:
>>
>>*(int*) PLL_CSR &=~CSR_PLLEN; /*my c code, assembler generated for this instruction by ccs below*/
>>800033D4 1AA43D11 .word 0X1aa43d11
>>800033D8 BFEA3656 .word 0Xbfea3656
>>800033Dc BBE911D2 .word 0Xbbe911d2
>>
>>we can see from above that the TI generated assembler commands are missing and just words at the memory locations We
>> are loading our program into external ram at starting at address 0x800...
>>
>>why cannot we see the underlying assembler? is there something wrong in our EMIF so the program is not loaded
>> correctly into our external SRAM?
>>
>>thanks
>>Richard

_____________________________________
Richard-

> we had a desighn working on the 6711b but have changed to c6711d. we are using a osc at 100 mhz for dsp and 50 mhz
> for emif. clkout therefore is at 50mhz. we have programmed to bypass the pll, both with gel and on the source code,
> have checked the correct pins on scope and correct frequenices are there, have also checked the register values and
> are as expected.

You're using separate clocks for DSP and EMIF? Why? Did you do this on the C6711B design, or is this a change?

-Jeff

> we are using a x560 emulator to debug our hardware. we have tried the many suggestions from the replies. but we find
> that when debugging when we enter values into memory locations through ccs the values are corrupted usually in the
> upper 8 bits. how could a problem with pll cause such a problem? unfortunately we are not hardware guys and have a
> urgent deadline...
>
> cheers
> richard
>
> hi
>>
>>we have developed an audio application based around the c6711 D dsp. We are using the XDS560 emulator and ccs 2.1.
>> We can successfully load the program onto the audio device through load program on ccs. and when loaded the cursor
>> appears at c_int00. But when the program is run it just goes to a series of nops. When we look at the our c code
>> and and asm generated under the view-> mixed asm option we get:
>>
>>*(int*) PLL_CSR &=~CSR_PLLEN; /*my c code, assembler generated for this instruction by ccs below*/
>>800033D4 1AA43D11 .word 0X1aa43d11
>>800033D8 BFEA3656 .word 0Xbfea3656
>>800033Dc BBE911D2 .word 0Xbbe911d2
>>
>>we can see from above that the TI generated assembler commands are missing and just words at the memory locations We
>> are loading our program into external ram at starting at address 0x800...
>>
>>why cannot we see the underlying assembler? is there something wrong in our EMIF so the program is not loaded
>> correctly into our external SRAM?
>>
>>thanks
>>Richard

_____________________________________