Reply by Roger Larsson September 3, 20032003-09-03
�ine Canby wrote:

> Hallo everyone, > > I think I might have isolated the problem somewhat. I loaded the > following program with CCS to my board - > > #include "audiocfg.h" > #include <csl_cache.h> > > #define HOST_RECEIVE_HAND_SHAKING_INFO 0x55555555 > > #pragma DATA_SECTION(handShakingBuffer, "HandShake") > int handShakingBuffer[HS_BUFFER_LEN]; > > Void main() > { > CACHE_flush(CACHE_L2ALL, (void *)0, 0); > > handShakingBuffer[0]++; > > while(handShakingBuffer[4] != HOST_RECEIVE_HAND_SHAKING_INFO); > > return; > } > > I then ran to cursor, stopping at the first line. I then placed a > watch on handShakingBuffer and it contained the values - > > [0] 0200C069 > [1] 027FFFEA > [2] 02100277 > [3] 02000C29 > [4] 0238002A > [5] 020388EB > > I then flushed and the values remained the same. And finally I > incremented handShakingBuffer and its watch became 0200C06A as > expected. > > As I was saying before when I load this program with my windows > application, I always read the following values (same as above) in > handShakingBuffer using HPI - > > [0] 0200C069 > [1] 027FFFEA > [2] 02100277 > [3] 02000C29 > [4] 0238002A > [5] 020388EB > > even if my dsp program sets the handShakingBuffer elements with > arbitary values. For example - > > Void main() > { > > handShakingBuffer[0] = ID_0; > handShakingBuffer[1] = ID_1; > handShakingBuffer[2] = ID_2; > handShakingBuffer[3] = 0; > handShakingBuffer[4] = 0; > > CACHE_flush(CACHE_L2ALL, (void *)0, 0);
Data in Internal SRAM might remain in L1 cache... I am not sure that flushing L2 will help. Well one year has passed since I dug into this mess (cache & HPI erratas) My assignment then was to write a library for loading program and data transfers over HPI - host was not Windows. /RogerL -- Roger Larsson Skellefte&#2013265925; Sweden
Reply by John McCabe September 1, 20032003-09-01
On 30 Aug 2003 10:30:03 -0700, aine_canby@yahoo.com
(=?ISO-8859-1?Q?=C0ine_Canby?=) wrote:

>Hallo everyone,
I have sent you email on this one. Hope it helps (I think it does!!). It's all in the EMIF configuration, or rather, the lack of it! Best Regards John McCabe To reply by email replace 'nospam' with 'assen'
Reply by August 30, 20032003-08-30
Hallo everyone,

I think I might have isolated the problem somewhat. I loaded the
following program with CCS to my board -

#include "audiocfg.h"
#include <csl_cache.h>

#define HOST_RECEIVE_HAND_SHAKING_INFO	0x55555555

#pragma DATA_SECTION(handShakingBuffer, "HandShake")
int handShakingBuffer[HS_BUFFER_LEN];

Void main()
{
  CACHE_flush(CACHE_L2ALL, (void *)0, 0); 
  
  handShakingBuffer[0]++;
 	
  while(handShakingBuffer[4] != HOST_RECEIVE_HAND_SHAKING_INFO);  
      
  return;                 
}

I then ran to cursor, stopping at the first line. I then placed a
watch on handShakingBuffer and it contained the values -

[0] 0200C069
[1] 027FFFEA
[2] 02100277
[3] 02000C29
[4] 0238002A
[5] 020388EB

I then flushed and the values remained the same. And finally I
incremented handShakingBuffer and its watch became 0200C06A as
expected.

As I was saying before when I load this program with my windows
application, I always read the following values (same as above) in
handShakingBuffer using HPI -

[0] 0200C069
[1] 027FFFEA
[2] 02100277
[3] 02000C29
[4] 0238002A
[5] 020388EB

even if my dsp program sets the handShakingBuffer elements with
arbitary values. For example -

Void main()
{
  
    handShakingBuffer[0] = ID_0;
    handShakingBuffer[1] = ID_1;
    handShakingBuffer[2] = ID_2;
    handShakingBuffer[3] = 0;
    handShakingBuffer[4] = 0;

    CACHE_flush(CACHE_L2ALL, (void *)0, 0);  
    
    while(handShakingBuffer[4] != HOST_RECEIVE_HAND_SHAKING_INFO);  
      
    return;                 
}

still gives me 0x0200C069 etc. This tells me that my windows
application is working correctly and that there is something wrong
with my dsp/bios memory configuration. In otherwords, the dsp program
is being loaded by my windows program, but it is not executing.
Perhaps this has something to do with HPI reset.

So just to recap, the program above has a memory configuration of - 

ENTRY POINT SYMBOL: "_c_int00"  address: 800009a0


MEMORY CONFIGURATION

                  name            origin    length      used    attr  
 fill
         ----------------------  --------  ---------  --------  ---- 
--------
         ResetVector             00000000   00000020  00000020  RWIX
         HandShake               00000020   00000018  00000018  RWIX
         SDRAM                   80000000   10000000  00005ebd  RWIX


SECTION ALLOCATION MAP

 output                                  attributes/
section   page    origin      length       input sections
--------  ----  ----------  ----------   ----------------
.vers      0    00000000    00000038     COPY SECTION
                  00000000    00000038     audiocfg.obj (.vers)

.clk       0 


I have 3 way caching enabled, and HWI is set to generate reset vector
at address 0. In the memory section manager, I have -

BIOS data - all set for SDRAM
BIOS code - all set for SDRAM
Compiler Sections - all set for SDRAM
Load Address - no options highlighted.

Remember also that I can actually this to work with my application be
simply deleting the memory segments -

ResetVector          
HandShake  

and setting SDRAM's base to 0, but this is not good practice.

Thanks again,

Aine.

C6711DSK, revision 1.3.
Reply by John McCabe August 28, 20032003-08-28
On 27 Aug 2003 10:18:58 -0700, aine_canby@yahoo.com
(=?ISO-8859-1?Q?=C0ine_Canby?=) wrote:

>John mentioned that SDRAM isn't consistent when using HPI, but I'm not >sure that thats my problem.
There are also a number of issues with the HPI in relation to automatic increments and so forth. You might want to check the errata for the chip which can be found on the TI website.
>I'm now trying to organise my memory correctly. I have set SDRAM back >to 0x80000000 and kept the lenght at 0x10000000. The space is >code/data. I've also added two new segments - > >ResetVector - >base: 0x00000000 >length: 0x00000020 >space: data >and > >HandShake - >base: 0x00000020 >length: 0x00000018 >space: data
Sounds reasonable funnily enough :-)
>These changes (the new segments) are not working. Every time my API >tries to read from handshakingBuffer (0x00000020) I now get the values >- > >0x200C069 >0x27FFFEA >0x2100277 > >The values should be, and were most of the time with my origional >inconsistent program - > >0x12345678 >0xf1f2f3f4 >0x08070605
Possibly an obvious question, but you have changed your host program to read from 0x20 instead of 0x0 haven't you?
>Every time I run the program I get those 3 exact same values - >0x200C069 - when I read from 0x00000020. Even when I power down - >those values never change. Could some other variable or something be >writing to these addresses? I tried changing the base of HandShake to >0x000003d8, which was where handshakeBuffer was mapped to when I had >only SDRAM. Again I had no luck with this change, I think that time I >got the values -
Try flushing the cache after you write to the handshaking buffer just in case. Best Regards John McCabe To reply by email replace 'nospam' with 'assen'
Reply by August 27, 20032003-08-27
Hi again all,

As I was saying in my last post, I have had success in handshaking
between the C6711DSK and my PC, using DSP/BIOS. The problem I'm now
having is that this isn't always consistent. So I might run my PC
application many times and all will be well, then all of a sudden the
handshaking values will be all wrong and I will have to power cycle
and run the program many times before its starts working again.

John mentioned that SDRAM isn't consistent when using HPI, but I'm not
sure that thats my problem.

My DSP program for reminders (this is just a skeleton) -


#include "audiocfg.h"
#include <csl_cache.h>

#define HS_BUFFER_LEN	6
#define ID_0			0x12345678
#define ID_1			0xf1f2f3f4
#define ID_2			0x08070605
#define HOST_RECEIVE_HAND_SHAKING_INFO 0x55555555

#pragma DATA_SECTION(handShakingBuffer, "HandShake")
int handShakingBuffer[HS_BUFFER_LEN];

Void main()
{
  handShakingBuffer[0] = ID_1;
  handShakingBuffer[1] = ID_1;
  handShakingBuffer[2] = ID_2;
    
//  CACHE_flush(CACHE_L2ALL, (void *)0, 0);
  while(handShakingBuffer[4] != HOST_RECEIVE_HAND_SHAKING_INFO);  
    
  return;                 
}

My inconsistent DSP program was organised as follows -

I had one memory segment called SDRAM whose base I set from 0x80000000
to 0x00000000, and I set the cache to 3 way. I also set the generate
reset vector at 0x0. I realise now that changing SDRAM's base doesn't
make a whole lot of sense, but that change got my handshaking working.

I'm now trying to organise my memory correctly. I have set SDRAM back
to 0x80000000 and kept the lenght at 0x10000000. The space is
code/data. I've also added two new segments -

ResetVector -
base:   0x00000000
length: 0x00000020
space:  data
and 

HandShake -
base:   0x00000020
length: 0x00000018
space:  data

Parts of my map -

MEMORY CONFIGURATION

                  name            origin    length      used    attr  
 fill
         ----------------------  --------  ---------  --------  ---- 
--------
         ResetVector             00000000   00000020  00000020  RWIX
         HandShake               00000020   00000018  00000018  RWIX
         SDRAM                   80000000   10000000  00005e9d  RWIX

HandShake   0    00000020    00000018     UNINITIALIZED
                 00000020    00000018     audio.obj (HandShake)


00000000   TSK$
00000000   _HWI_RESET
00000000   _GBL_CACHE

0000000a   HWI_INT10
0000000b   HWI_INT11
0000000b   _HWI_INT11
0000000c   HWI_INT12
0000000c   _HWI_INT12
0000000d   _HWI_INT13
0000000d   HWI_INT13
0000000e   _HWI_INT14
0000000e   HWI_INT14
0000000f   HWI_INT15
0000000f   _HWI_INT15
00000020   _handShakingBuffer
00000020   CLK_TCR
00000042   GBL_FOOTPRINT
00000100   HST_MAXFRAMEALLOWED
00000200   LOG_system$size
00000400   TSK_STACKSIZE
00000400   trace$size
00000400   __STACK_SIZE

80004758   _RTDX_Set_IER
80004800   LOG_system$buf
80005000   trace$buf
ffffffff   _SDRAM
ffffffff   _ResetVector
ffffffff   ResetVector
ffffffff   SDRAM
ffffffff   _HandShake
ffffffff   HST_DSMBUFSEG
ffffffff   HandShake
ffffffff   RTDX_DATAMEMSEG

These changes (the new segments) are not working. Every time my API
tries to read from handshakingBuffer (0x00000020) I now get the values
-

0x200C069
0x27FFFEA
0x2100277

The values should be, and were most of the time with my origional
inconsistent program -

0x12345678
0xf1f2f3f4
0x08070605

Every time I run the program I get those 3 exact same values -
0x200C069 - when I read from 0x00000020. Even when I power down -
those values never change. Could some other variable or something be
writing to these addresses? I tried changing the base of HandShake to
0x000003d8, which was where handshakeBuffer was mapped to when I had
only SDRAM. Again I had no luck with this change, I think that time I
got the values -

0x00008000
0x0
0x0

Why might I be having problems with these new MEM segments? The L2
MARS bitmask is 0x0001. I'm not using any CSL - I'm not configuring
EMIF in anyway. I'm not using any interrupts.

Any ideas what might problem might be?

I realise that my knowledge of the C6711 is poor and that a course
whould be of great benifit with regard to understanding it more, but
I'm almost finished my Masters project - I only really need to get my
VC++ MFC application working properly with my board - I've all my
demodulation schemes working well on the board itself.

Thanks as usual,

Aine.
Reply by John McCabe August 20, 20032003-08-20
On Wed, 20 Aug 2003 16:14:08 +0000 (UTC), john@nospam.demon.co.uk
(John McCabe) wrote:

>3) Right click on the memory section manager and select "Insert MEM". >This will create a new memory section for you called "MEM0". In the >settings for this section set the comment to "Internal RAM", base >address to 0x00000000, size to 0x00004000, don't create a heap, and >set the "Space" as "data", apply it then rename the section to >"InternalRAM".
Alternatively, based on some of your earlier comments, you could create two memory section, as follows: "ResetVector" Base: 0x00000000 Size: 0x00000020 No heap. "Handshake" Base: 0x00000020 Size: 0x00003FE0 No heap And use your pragma as follows: #pragma DATA_SECTION(handShakingBuffer, "Handshake") int handShakingBuffer[HS_BUFFER_LEN]; and guarantee that the base address of the handshaking buffer is 0x00000020. Best Regards John McCabe To reply by email replace 'nospam' with 'assen'
Reply by John McCabe August 20, 20032003-08-20
On 20 Aug 2003 08:14:10 -0700, aine_canby@yahoo.com
(=?ISO-8859-1?Q?=C0ine_Canby?=) wrote:

>WE HAVE BLASTOFF! > >OK, Its working now. I had to do a lot of fiddling around in order for >it to work, so I'll give details of what I did. > >First of all I set - > >"Generate RESET vector at address 0" > >as directed by John, but when I rebuilt I got an error saying that >this was outside the memory space. I then checked my MEM, which >contained 1 MEM segment called SDRAM which had a base address at >0x80000000. I tried to change this to 0x00000000 but it was forced >back to 0x80000000 due to a conflict with the cache - I dont >understand why!
Because you had the settings such that the whole of internal memory was cache, and the DSP/BIOS configuration tool requires you to change that before you can use internal memory as RAM.
>So then I went into memory settings and disabled -
>"Configure L2 memory settings"
>I was then able to set SDRAM's base to 0x00000000. At this stage my >DSP-BIOS program was working with my windows app. Then I went back >into global settings and re-enabled - > >"Configure L2 memory settings" > >I then rebuilt and tested again with my app, and all was fine.
What would be good for you is to: 1) Set the cache configuration to 3-way. That frees up the bottom 16kbytes of internal memory for use as RAM. In my experience you ned to place any data shared with the PC in this area; access to SDRAM from the HPI port is extremely inconsistent. 2) Ensure that SDRAM's settings are reset to its defaults of base 0x80000000 and size 0x10000000 3) Right click on the memory section manager and select "Insert MEM". This will create a new memory section for you called "MEM0". In the settings for this section set the comment to "Internal RAM", base address to 0x00000000, size to 0x00004000, don't create a heap, and set the "Space" as "data", apply it then rename the section to "InternalRAM".
>Why was the SDRAM set at base 0x80000000?
Because the base address of the SDRAM on the C6711 DSK is at address 0x80000000. Changing that to 0x00000000 will confuse the hell out of things if your program exceeds 64k, because your compiler/linker will think there is RAM at addresses where there really isn't.
>Were the cache settings stored at 0x00000000?
No. With 4-way caching enabled the whole of the 64k internal memory space, starting at address 0x00000000 is used as Level 2 cache. 3-way uses 48k from 0x00004000 upwards and so on.
>Should my caching be working correctly now?
You haven't said what you set them to! If you have set it to SRAM you won't be getting any caching whatsoever. If you have set it to n-way, it may be working. Depends on whether you rewrite the Cache Configuration Register when (if) you reinitialise your EMIF settings. Are you doing this as a personal thing or a work thing? Either way, there is a load of documentation supplied with CCS on stuf like this; select "Help" => "User Manual" and you should be presented with a web page with links to the manuals that have been installed on your system. If it is for work, I would recommend, at the very least, encouraging your employer to send you on the 1 day C6711 DSK Workshop (if it is still available) http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=1DW000060 Best Regards John McCabe To reply by email replace 'nospam' with 'assen'
Reply by August 20, 20032003-08-20
WE HAVE BLASTOFF!

OK, Its working now. I had to do a lot of fiddling around in order for
it to work, so I'll give details of what I did.

First of all I set -

"Generate RESET vector at address 0"

as directed by John, but when I rebuilt I got an error saying that
this was outside the memory space. I then checked my MEM, which
contained 1 MEM segment called SDRAM which had a base address at
0x80000000. I tried to change this to 0x00000000 but it was forced
back to 0x80000000 due to a conflict with the cache - I dont
understand why!

So then I went into memory settings and disabled -

"Configure L2 memory settings"

I was then able to set SDRAM's base to 0x00000000. At this stage my
DSP-BIOS program was working with my windows app. Then I went back
into global settings and re-enabled -

"Configure L2 memory settings"

I then rebuilt and tested again with my app, and all was fine.


I've always used the same cdb file, which was included in the
tutorials - I then alter this file as I need McBSPs,  EDMA , PIPs etc.
I do this basically because I dont now all the details of this file
yet, being a novice and all. Why was the SDRAM set at base 0x80000000?
Were the cache settings stored at 0x00000000? Should my caching be
working correctly now?

Thanks very much for your help everyone,

Take care,

Aine.




john@nospam.demon.co.uk (John McCabe) wrote in message news:<3f433545.3087870@news.btclick.com>...
> On 19 Aug 2003 13:51:38 -0700, aine_canby@yahoo.com > (=?ISO-8859-1?Q?=C0ine_Canby?=) wrote: > > >Sorry for the big posts but this problem is driving me mad - surely > >DSP/BIOS would make things easier not harder. I am checking the hpi > >return values, for example - > > > >if (dsk6x_coff_load(hBd,coffNam,bVerbose,bClr,bDump)) > > exit(4); > > > >All of the hpi function succeed for both the DSP/BIOS and the > >non-DSP/BIOS DSP programs. > > > >With regard to status registers, is there a way I could monitor the > >dsp board even though my windows application has control of the > >parallel port, instead of Code Composer Studio. I compile my code on > >CCS, but my application uploads the .out to the dsp board. CSS message > >box read "JAG communication error", because it does not have control > >of the port. > > Have you tried my suggestions re. the cache? > > Here's another idea I've just remembered was an issue with me... > > Go into the DSP/BIOS configuration. In the "Scheduling" section. right > click on the "HWI - blah blah" entry and select "Properties". Check > the box that says "Generate RESET vector at address 0". Compile and > try again. > > > Best Regards > John McCabe > > To reply by email replace 'nospam' with 'assen'
Reply by Vic August 20, 20032003-08-20
Hi Aine,
with regret I see mine expirience can't help you: powest TMS5402,
without any OS, with selfmaden hard&soft debug tool, CCS use only
simulator. There is only common debug's methods advice. But i have
more questions as answers.
 Is BIOS needed for you, why?

Some details are unclear(maybe from sorrowful fact: i am't native
english).

> parallel port, instead of Code Composer Studio. I compile my code on > CCS, but my application uploads the .out to the dsp board. CSS message > box read "JAG communication error", because it does not have control > of the port.
Upload&work over JTAG or how?
> All of the hpi function succeed for both the DSP/BIOS and the > non-DSP/BIOS DSP programs.
Why you talk about?
> With regard to status registers, is there a way I could monitor the > dsp board even though my windows application has control of the > parallel port, instead of Code Composer Studio.
As i understand by definition CCS use JTAG pins, anothers use your program in TMS & Win application, its haven't intersection.
> The only communication my application can recieve from the board is > the setting of the handshaking buffer, and this isn't working for my > DSP/BIOS program.
As i understand you haven't start. To begin usually i make program 'set/reset XF' deadloop and see by oscylloscope this pin.
> I could turn on a led, but that means playing with the EMIF which I know >>>nothing about. I was able to > toggle the leds in a non-dsp/bios program, but it is so prone to > errors - due to timing delays or something like that.
Delays can change only time turn on/off LED; what is EMIF?
> Anyway, I'm really not sure what to do and would love some more ...
It is beatiful, will continue over mail if you don't mind. Cheers Victor
Reply by John McCabe August 20, 20032003-08-20
On 19 Aug 2003 13:51:38 -0700, aine_canby@yahoo.com
(=?ISO-8859-1?Q?=C0ine_Canby?=) wrote:

>Sorry for the big posts but this problem is driving me mad - surely >DSP/BIOS would make things easier not harder. I am checking the hpi >return values, for example - > >if (dsk6x_coff_load(hBd,coffNam,bVerbose,bClr,bDump)) > exit(4); > >All of the hpi function succeed for both the DSP/BIOS and the >non-DSP/BIOS DSP programs. > >With regard to status registers, is there a way I could monitor the >dsp board even though my windows application has control of the >parallel port, instead of Code Composer Studio. I compile my code on >CCS, but my application uploads the .out to the dsp board. CSS message >box read "JAG communication error", because it does not have control >of the port.
Have you tried my suggestions re. the cache? Here's another idea I've just remembered was an issue with me... Go into the DSP/BIOS configuration. In the "Scheduling" section. right click on the "HWI - blah blah" entry and select "Properties". Check the box that says "Generate RESET vector at address 0". Compile and try again. Best Regards John McCabe To reply by email replace 'nospam' with 'assen'