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,

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 -------

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-

> 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

_____________________________________

Michael,

Given RJs post, I was under the impression that he did try using the CCS to ascertain the problem and found that a write to an address did not return the same value written.

(the 'crawl' step)

My initial thinking was that RJ is using a commercial board, probably from TI or Spectrum Digital.
If they are using a 'homemade' board, then the probability of a hardware problem is greatly increased.

My later thinking is the project is being run on an emulator rather than actual target hardware.

To me, the original message indicated a problem with linking. (load the program, then the contents of RAM not being as expected.) I have seen this problem over and over where a person, new to CCS, has an error in the .cmd file or is using the wrong CCS startup GEL or has the incorrect processor selected in CCS.

I'm looking forward to more detailed info from RJ to clarify certain aspects of the problem, such as who made the target hardware, how experienced RJ is with CCS and more detail info, such as: boot mode of the target and was the target re-booted after the memory load.

I also think that something has drastically changed between the original RJ post and the latest post.
Because the original post did not show 'ff' in the high order 8 bits of the data.

Given that the original post displayed raw RAM data rather than any 'dis-assembly'; this says to me that RJ is not experienced with the CCS tool. This may indicate a need for a bit of 'hand holding' when assisting RJ in his debug activities.

Also of interest is the method being used for the startup sequence. For instance, which startup file is linked and which method of startup sequence is selected in the build options and (if the 6711 has the capability) does the Endianess match the boot mode of the target hardware.

Hopefully, RJ will either find the solution on his own (and give us feedback) or will be providing the details needed so we can be of significant assistance via email.

BTW:
My background is mostly software, so when a hardware problem looms, I usually call in the hardware guys and we debug it together.

R. Williams

---------- Original Message -----------
From: Michael Dunn
To: Richard Williams
Cc: r...@gmail.com, c...
Sent: Sat, 6 Mar 2010 22:22:15 -0600
Subject: Re: [c6x] Re: 6711D memory load

>
>
> rjedwards,
>
> Please forgive me while I digress and then rant a bit.
> 1. There is a common thread in solving multiple equations with multiple unknowns and troubleshooting [or assisting someone]. You can guess at answers or you can systematically solve [or troubleshoot] for some of the variable values.
> 2. I provided some info and questions to you 2 days ago. You apparently ignored them or tried them and kept the results secret. Either case is not very smart.
>
> Some of us have designed dozens of products and solved 1000s of problems [literally] during our careers. I will again share some advice [you should still refer to my original comments].
>
> For new or revised products you should [1] crawl, then [2] walk, and then [3] run.
>
> I infer from your comments that the hardware has not been completely checked out. Your own post seems to question the robustness of SDRAM.
> STOP trying to troubleshoot an application on hardware that 'may or may not' have working SDRAM.
> 1. crawl - verify memory manually with CCS
> 2. walk - write a simple program. Generate asm listings. Load the program into SDRAM. Verify the contents of SDRAM. Single step the program and verify correct functionality. Run the program and verify correct functionality.
> NOTE: 'Hello World' is NOT a simple program due to stdio. A simple program that stores a few constants in memory and reads them back is a good start.
> 3. run - Create and load a simple subset of your app. Verify functionality and and repeat the process of adding functionality and verifying.
>
> Let us know what you have done and the results. If your problem is not solved, we will have more 'knowns' and it will be easier to home in on the unknowns.
>
> mikedunn
>
> On Sat, Mar 6, 2010 at 1:21 PM, Richard Williams wrote:
>
>
>
> richard,
>
> Here are my suggestions..
> (guesses actually, based on your description of the problem)
> the external RAM is faulty
> the external RAM does not have all the data bits connected.
> the bus receiver/transmitter driver chip for the upper 8 bits is faulty.
> the communication bus is set for less than 32 bits.
> the number of wait states for either the read or the write operation is set too low.
> the data addressing is set for 'near' rather than 'far'.
>
> R. Williams
>
> ---------- Original Message -----------
> From: r...@gmail.com
> To: c...
>
> Sent: Sat, 06 Mar 2010 11:39:17 -0500
> Subject: [c6x] Re: 6711D memory load
>
> >
> >
> > hello again,
> >
> > when loading in data, it is all preceded by 0xff, for example 0x11111111 becomes 0xff111111, so seems highest 8 bits are always saturated. any suggestions?
> >
> > thanks
> > 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
> --
> www.dsprelated.com/blogs-1/nf/Mike_Dunn.php
------- End of Original Message -------

rjedwards,

Please forgive me while I digress and then rant a bit.
1. There is a common thread in solving multiple equations with multiple
unknowns and troubleshooting [or assisting someone]. You can guess at
answers or you can systematically solve [or troubleshoot] for some of the
variable values.
2. I provided some info and questions to you 2 days ago. You apparently
ignored them or tried them and kept the results secret. Either case is not
very smart.

Some of us have designed dozens of products and solved 1000s of problems
[literally] during our careers. I will again share some advice [you should
still refer to my original comments].

For new or revised products you should [1] crawl, then [2] walk, and then
[3] run.

I infer from your comments that the hardware has not been completely checked
out. Your own post seems to question the robustness of SDRAM.
STOP trying to troubleshoot an application on hardware that 'may or may not'
have working SDRAM.
1. crawl - verify memory manually with CCS
2. walk - write a simple program. Generate asm listings. Load the program
into SDRAM. Verify the contents of SDRAM. Single step the program and
verify correct functionality. Run the program and verify correct
functionality.
NOTE: 'Hello World' is NOT a simple program due to stdio. A simple program
that stores a few constants in memory and reads them back is a good start.
3. run - Create and load a simple subset of your app. Verify functionality
and and repeat the process of adding functionality and verifying.

Let us know what you have done and the results. If your problem is not
solved, we will have more 'knowns' and it will be easier to home in on the
unknowns.

mikedunn

On Sat, Mar 6, 2010 at 1:21 PM, Richard Williams wrote:

> richard,
>
> Here are my suggestions..
> (guesses actually, based on your description of the problem)
> the external RAM is faulty
> the external RAM does not have all the data bits connected.
> the bus receiver/transmitter driver chip for the upper 8 bits is faulty.
> the communication bus is set for less than 32 bits.
> the number of wait states for either the read or the write operation is set
> too low.
> the data addressing is set for 'near' rather than 'far'.
>
> R. Williams
>
> *---------- Original Message -----------*
> From: r...@gmail.com
> To: c...
> Sent: Sat, 06 Mar 2010 11:39:17 -0500
> Subject: [c6x] Re: 6711D memory load
>
> >
> >
> > hello again,
> >
> > when loading in data, it is all preceded by 0xff, for example 0x11111111
> becomes 0xff111111, so seems highest 8 bits are always saturated. any
> suggestions?
> >
> > thanks
> > 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
>
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php

richard,

Here are my suggestions..
(guesses actually, based on your description of the problem)
the external RAM is faulty
the external RAM does not have all the data bits connected.
the bus receiver/transmitter driver chip for the upper 8 bits is faulty.
the communication bus is set for less than 32 bits.
the number of wait states for either the read or the write operation is set too low.
the data addressing is set for 'near' rather than 'far'.

R. Williams

---------- Original Message -----------
From: r...@gmail.com
To: c...
Sent: Sat, 06 Mar 2010 11:39:17 -0500
Subject: [c6x] Re: 6711D memory load

>
>
> hello again,
>
> when loading in data, it is all preceded by 0xff, for example 0x11111111 becomes 0xff111111, so seems highest 8 bits are always saturated. any suggestions?
>
> thanks
> 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

hello again,

when loading in data, it is all preceded by 0xff, for example 0x11111111 becomes 0xff111111, so seems highest 8 bits are always saturated. any suggestions?

thanks
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
>
>_____________________________________

_____________________________________

hi guys

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?

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
>
>_____________________________________

_____________________________________