6711D memory load

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

_____________________________________ Start a New Thread

Richard,

On Thu, Mar 4, 2010 at 1:53 PM, wrote:

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

I'm not sure what the problem is - first you should verify that SDRAM is
working.

1. Display the memory at 0x80000000 in CCS. Modify the first location and
refresh the window.
Did it work??
2. a. Fill memory from 0x80000000 to 0x80001000 with 0s.
b. Write the pattern 0x10000000 at 0x8000100.
c. Set the PC to 0x80000000 and hit run. It should execute the Nops and
stop when it sees the sw bp at 0x8000100.
Did this work??
This should get you started verifying the hw.

mikedunn

>
> thanks
> Richard
>
>

--
www.dsprelated.com/blogs-1/nf/Mike_Dunn.php Start a New Thread

Richard,

There are several possibilites as to the cause of the problem.

First, what start address is listed in the .map file?
is it 0x800...?

Second, what does your .cmd file indicate
(you could embed the file contents here in a email by copy/paste)

Third, do the instructions at _c_int00 consist of a s1 b main?

I would start by examining the .map file to assure that the data is not overlaying the code.

Then I would single step the program from _c_int00.
to determine if it branches to the startup code and that the startup code is correct.

BTW:
the 6711 is a multi core DSP.
You 'may' need to have the CCS version 4.0 or later to properly access the DSP.

R. Williams

---------- Original Message -----------
From: r...@gmail.com
To: c...
Sent: Thu, 04 Mar 2010 14:53:52 -0500
Subject: [c6x] 6711D memory load

>
>
> 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
> Start a New Thread

Richard Williams,

6711 multicore?? I suspect some numbers got confused/scrambled somewhere.
I believe that the 6711 is single core and older than most elementary school
students.

mikedunn

On Thu, Mar 4, 2010 at 6:09 PM, Richard Williams wrote:

> Richard,
> There are several possibilites as to the cause of the problem.
>
> First, what start address is listed in the .map file?
> is it 0x800...?
>
> Second, what does your .cmd file indicate
> (you could embed the file contents here in a email by copy/paste)
>
> Third, do the instructions at _c_int00 consist of a s1 b main?
>
> I would start by examining the .map file to assure that the data is not
> overlaying the code.
>
> Then I would single step the program from _c_int00.
> to determine if it branches to the startup code and that the startup code
> is correct.
>
> BTW:
> the 6711 is a multi core DSP.
> You 'may' need to have the CCS version 4.0 or later to properly access the
> DSP.
> R. Williams
>
> *---------- Original Message -----------*
> From: r...@gmail.com
> To: c...
> Sent: Thu, 04 Mar 2010 14:53:52 -0500
> Subject: [c6x] 6711D memory load
>
> >
> >
> > 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 Start a New Thread

michael,

My error,
I should check before opening my mouth.

R. Williams

---------- Original Message -----------
From: Michael Dunn
To: Richard Williams
Cc: r...@gmail.com, c...
Sent: Fri, 5 Mar 2010 07:54:38 -0600
Subject: Re: [c6x] 6711D memory load

> Richard Williams,
>
> 6711 multicore?? I suspect some numbers got confused/scrambled somewhere. I believe that the 6711 is single core and older than most elementary school students.
>
> mikedunn
>
> On Thu, Mar 4, 2010 at 6:09 PM, Richard Williams wrote:
>
>
>
> Richard,
>
> There are several possibilites as to the cause of the problem.
>
> First, what start address is listed in the .map file?
> is it 0x800...?
>
> Second, what does your .cmd file indicate
> (you could embed the file contents here in a email by copy/paste)
>
> Third, do the instructions at _c_int00 consist of a s1 b main?
>
> I would start by examining the .map file to assure that the data is not overlaying the code.
>
> Then I would single step the program from _c_int00.
> to determine if it branches to the startup code and that the startup code is correct.
>
> BTW:
> the 6711 is a multi core DSP.
> You 'may' need to have the CCS version 4.0 or later to properly access the DSP.
>
> R. Williams
>
> ---------- Original Message -----------
> From: r...@gmail.com
> To: c...
> Sent: Thu, 04 Mar 2010 14:53:52 -0500
> Subject: [c6x] 6711D memory load
>
> >
> >
> > 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 ------- Start a New Thread

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

_____________________________________ Start a New Thread

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

_____________________________________ Start a New Thread

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 Start a New Thread

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 Start a New Thread

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 ------- Start a New Thread