HPI and DSP/BIOS

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'

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'

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.

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'

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.

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'

�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&#4294967295;
Sweden