Randy Yates wrote:
> 
> I searched the TI bug list for "DAT" and only found three entries. One
> was on a DAT_open(), but that was for the 55x family. The second was
> on a "register reordering" problem in DAT_copy() for the C6000 family,

The best I can do is tell you my story...

After installing CCS3.1 I noticed that my DM642 app stopped working. It
is heavily based around TI's vport driver, and all the TI example code
using vport also didn't work, so I guessed that it wasn't my fault.

I reported it to TI EPIC on 30th June, and within a day I was sent a
temporary CSL to replace 2.30.00.12, which fixed the problem. Shortly
afterwards, an official new CSL was released onto the TI website, and
the "user error" bug appeared on the bug list. I replaced the
temporary CSL with the official one without any problems.

I was a bit taken aback by the "user error" comment, if this bug was
"my" bug - after all it broke all TI's demo code too! Still, I wasn't
too fussed since the problem was fixed.

Cheers

mark-r 

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

> Randy Yates wrote:
>
> > I am finding the DAT_copy routine no longer works after upgrading from
> > CCS 2.20.18 to 3.1.?? for the DM642. The memory simply remains
> > uncopied. Has anyone else experienced this situation or otherwise have
> > any suggestions?
>
>
>
> It's a known bug, certainly for c6000. You need to download a new CSL
> from the TI website.

Mark,

I searched the TI bug list for "DAT" and only found three entries. One
was on a DAT_open(), but that was for the 55x family. The second was
on a "register reordering" problem in DAT_copy() for the C6000 family,
but it states that this is not a bug but a user error (apparently in
some cases the source/destination operand(s) should be declared
volatile). The third was a problem with DAT_copy2d(), which I'm
not using.

So, which bug are you referring to?

Also, do you know what "register reordering" means?

Thanks for your help.

--Randy

Bhooshan wrote:

> Randy--
>
> >> Iam assuming you are using DSP/BIOS in your project and that version
> is
> >> 4.9.
>
> >How do you tell the version?
>
>
>
> This is how:
>
> CCS->Help->About->Component Manager->CCSV3.1.19.0->Target
> Content(DSP/BIOS)-> <Individual ISA>

Yes, I'm running DSP/BIOS 4.9 according to this.

> >> If so, when you migrated your project from 2.2 to 3.1 did you get a
> CDB
> >> update message? If not, this could be a reason for this problem.
>
> >How do you "migrate" the project? I simply loaded the old project
> >file (which includes the .cdb configuration) into 3.1 and re-saved.
>
> Well, just as you did. Except when you double click on the .cdb file, it
> should actualy ask you something about "updating the seed file as the seed
> file is from a different version etc" and you say "yes" and save it. TI has
> some documentation on this procedure and they also talk about the
> exceptions for this *automatic* migration (and the procedure to write
> Tconf files in those cases)
>
> Just ensure your CDB is updated by double clicking and saving it after the
> update dialog box appears.

I'll repeat here that I never had any such update dialog appear, and
I'm quite sure I went through the procedure you state.

Did you see Mark Robinson's comment on the DAT_ module having a known
bug?

Regarding cache coherency problems, keep in mind that this code worked
fine under CCS 2.20.18.

Thanks again for your responses.


--Randy

Randy Yates wrote:
> 
> Let's take a simple example. Assume Buffer[] has been cached from
> SDRAM into level 2 cache. Now let's say a PCI slave mode bus transfer
> occurs which writes into Buffer[] in SDRAM (this essentially occurs
> through EDMA transfers). Will the DM642 "know" that external SDRAM has
> changed and invalidate the corresponding tag lines? In other words,
> the next time my program goes to read Buffer[], will it get the latest
> data and not the stale data in level 2 cache?

No. I data is in cache, the CPU will always use the cached version.
It is up to the programmer to ensure that the cached data is not
stale.

> This is what Handy refers to as "snooping" in his book "The Cache
> Memory Book." Does the DM642 use a bus-snooping mechanism to make
> sure cache is invalidated in such scenarios?

I think snooping has been dropped from PCI version 2.2, so it's
doubtful whether the DM642 will support it.

> The current situation is that BufferA and BufferB are in SDRAM. A
> PCI slave mode bus transfer occurs that writes into BufferA. This
> triggers (via a semaphore pend on a flag updated in the PCI
> interrupt handler) a process to issue a DAT_copy from BufferA to
> BufferB. However, BufferB never changes. That is a more detailed
> explanation of the current problem.

DMA transfers always bypass the cache, so your PCI write will
update the external RAM, and the DMA will copy the correct data
from buffer A to buffer B (given the bug fixed CSL, see other
post). If you then use CPU reads to access buffer B, you may read
stale data, so before reading you must invalidate the cache for
buffer B. Alternatively, if possible, place buffer B in internal
RAM.

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

Randy Yates wrote:
> 
> I am finding the DAT_copy routine no longer works after upgrading from
> CCS 2.20.18 to 3.1.?? for the DM642. The memory simply remains
> uncopied. Has anyone else experienced this situation or otherwise have
> any suggestions?

It's a known bug, certainly for c6000. You need to download a new CSL
from the TI website.

Cheers

mark-r

-- 
"Let's meet the panel. You couldn't ask for four finer comedians -
so that answers your next question..."
 -- Humphrey Lyttleton

"Bhooshan Iyer" <bhooshaniyer@gmail.com> writes:

> Randy--
>
>>> Iam assuming you are using DSP/BIOS in your project and that version
> is
>>> 4.9.
>>
>>How do you tell the version?
>
> This is how:
>
> CCS->Help->About->Component Manager->CCSV3.1.19.0->Target
> Content(DSP/BIOS)-> <Individual ISA>

OK, thanks - I'll check on Monday.

>>> If so, when you migrated your project from 2.2 to 3.1 did you get a
> CDB
>>> update message? If not, this could be a reason for this problem.
>>
>>How do you "migrate" the project? I simply loaded the old project
>>file (which includes the .cdb configuration) into 3.1 and re-saved. 
>
> Well, just as you did. Except when you double click on the .cdb file, it
> should actualy ask you something about "updating the seed file as the seed
> file is from a different version etc" and you say "yes" and save it. 

That never happened, and I distinctly remember opening the .cdb file when
I first opened the old 2.x project under 3.1. Does it only ask if it
sees a problem?

> TI has
> some documentation on this procedure and they also talk about the 
> exceptions for this *automatic* migration (and the procedure to write
> Tconf files in those cases)

TI has a LOT of documentation. Could you be more specific (like an SPRU
number)?

> Just ensure your CDB is updated by double clicking and saving it after the
> update dialog box appears.
>>> The GUI config of CSL using GCONF/TCONF in DSP/BIOS 
>>> which was possible earlier is
>>> not possible now due to TI abandaning  support for graphical 
>>> configuration of peripherals.
>
>> Actually the version I have of 3.1 DOES have the gconf 
>> and gconfgen utilities available. 
>
> Well it is a little more complicated than that. TI stopped GUI config of
> peripherals completely in CCS3.0 after a lond deleberation. This was done
> primarily because the peripherals became lot more complex since the time
> DSP/BIO GUI config was introduced for ease of use.TI also claimed that
> lots of its customers anyways end up using TCONF scripts rather than the
> GCONF once they get started. But after a lot of hue and cry from 3p's like
> us TI decided to bring back the GCONF in CCS3.1 to promote ease of use for
> casual DSP/BIOS users but fundamentaly the architecture is changed TCONF
> script based. ie the GCONF is converted to TCONF internaly. Anyways,
> support for CSL inside DSP/BIOS has been abandoned completely if am not
> mistaken.

I don't think this project is using any "CSL inside DSP/BIOS." They
are simply using some of the modules. (EDMA_, DAT_, CACHE_, etc.).

>>> Finally, there are some cache initializations done before this?
>>
>>Yes. What about them?
>
> Then you should also worry if there are some cache coherency issues due to
> which this(failure of DAT_COPY) is happening as well.

This is where I fall off the edge of a cliff. I'm very confused about the
interactions of cache with software operation. 

Let's take a simple example. Assume Buffer[] has been cached from
SDRAM into level 2 cache. Now let's say a PCI slave mode bus transfer
occurs which writes into Buffer[] in SDRAM (this essentially occurs
through EDMA transfers). Will the DM642 "know" that external SDRAM has
changed and invalidate the corresponding tag lines? In other words,
the next time my program goes to read Buffer[], will it get the latest
data and not the stale data in level 2 cache?

This is what Handy refers to as "snooping" in his book "The Cache
Memory Book." Does the DM642 use a bus-snooping mechanism to make
sure cache is invalidated in such scenarios?

The current situation is that BufferA and BufferB are in SDRAM. A
PCI slave mode bus transfer occurs that writes into BufferA. This
triggers (via a semaphore pend on a flag updated in the PCI
interrupt handler) a process to issue a DAT_copy from BufferA to
BufferB. However, BufferB never changes. That is a more detailed
explanation of the current problem.

Thanks again for your responses, Bhooshan. It is great to be able
to discuss these things with someone.
-- 
%  Randy Yates                  % "The dreamer, the unwoken fool - 
%% Fuquay-Varina, NC            %  in dreams, no pain will kiss the brow..."
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

Randy--

>> Iam assuming you are using DSP/BIOS in your project and that version
is
>> 4.9.
>
>How do you tell the version?

This is how:

CCS->Help->About->Component Manager->CCSV3.1.19.0->Target
Content(DSP/BIOS)-> <Individual ISA>

>> If so, when you migrated your project from 2.2 to 3.1 did you get a
CDB
>> update message? If not, this could be a reason for this problem.
>
>How do you "migrate" the project? I simply loaded the old project
>file (which includes the .cdb configuration) into 3.1 and re-saved. 

Well, just as you did. Except when you double click on the .cdb file, it
should actualy ask you something about "updating the seed file as the seed
file is from a different version etc" and you say "yes" and save it. TI has
some documentation on this procedure and they also talk about the 
exceptions for this *automatic* migration (and the procedure to write
Tconf files in those cases)

Just ensure your CDB is updated by double clicking and saving it after the
update dialog box appears.
>> The GUI config of CSL using GCONF/TCONF in DSP/BIOS 
>> which was possible earlier is
>> not possible now due to TI abandaning  support for graphical 
>> configuration of peripherals.

> Actually the version I have of 3.1 DOES have the gconf 
> and gconfgen utilities available. 

Well it is a little more complicated than that. TI stopped GUI config of
peripherals completely in CCS3.0 after a lond deleberation. This was done
primarily because the peripherals became lot more complex since the time
DSP/BIO GUI config was introduced for ease of use.TI also claimed that
lots of its customers anyways end up using TCONF scripts rather than the
GCONF once they get started. But after a lot of hue and cry from 3p's like
us TI decided to bring back the GCONF in CCS3.1 to promote ease of use for
casual DSP/BIOS users but fundamentaly the architecture is changed TCONF
script based. ie the GCONF is converted to TCONF internaly. Anyways,
support for CSL inside DSP/BIOS has been abandoned completely if am not
mistaken.

>> Finally, there are some cache initializations done before this?
>
>Yes. What about them?

Then you should also worry if there are some cache coherency issues due to
which this(failure of DAT_COPY) is happening as well.

--Bhooshan
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

Hi Bhooshan,

Thank you for responding. Let me ask a question or two below.

"Bhooshan Iyer" <bhooshaniyer@gmail.com> writes:

> Randy--
>
>>I am finding the DAT_copy routine no longer works after upgrading from
>>CCS 2.20.18 to 3.1.?? for the DM642. The memory simply remains
>>uncopied. Has anyone else experienced this situation or otherwise have
>>any suggestions?
>
> I dont have a direct answer to that, just a few may be not so helpful
> hints.
>
> Iam assuming you are using DSP/BIOS in your project and that version is
> 4.9.

How do you tell the version?

> If so, when you migrated your project from 2.2 to 3.1 did you get a CDB
> update message? If not, this could be a reason for this problem.

How do you "migrate" the project? I simply loaded the old project
file (which includes the .cdb configuration) into 3.1 and re-saved. 

> Check out this Q&A from TI:
>
> "How do customers who have old CSL configuration files migrate? 
> When customers update to a new release without support for CSL
> configuration, the CDB update will check for previously configured CSL
> peripherals. If found, it will notify the user that CSL configuration is
> no longer supported and then generate two new files that contain the CSL
> code that had been provided before. The customer will then be required to
> add these two new files to their project"
>
>
> Anyways,now do you know that the different ways in which CSL was used in
> CCS2.2 and can be used in CCS3.1 are different by atleast one way? The GUI
> config of CSL using GCONF/TCONF in DSP/BIOS which was possible earlier is
> not possible now due to TI abandaning  support for graphical configuration
> of peripherals.

Actually the version I have of 3.1 DOES have the gconf and gconfgen utilities
available. 

> Though the CSL versions are theoretically independent of BIOS versions, to
> be sure you could try downloading a more appropriate version of CSL for
> your target?
>
> Finally, there are some cache initializations done before this?

Yes. What about them?
-- 
%  Randy Yates                  % "And all that I can do
%% Fuquay-Varina, NC            %  is say I'm sorry, 
%%% 919-577-9882                %  that's the way it goes..."
%%%% <yates@ieee.org>           % Getting To The Point', *Balance of Power*, ELO
http://home.earthlink.net/~yatescr

Randy--

>I am finding the DAT_copy routine no longer works after upgrading from
>CCS 2.20.18 to 3.1.?? for the DM642. The memory simply remains
>uncopied. Has anyone else experienced this situation or otherwise have
>any suggestions?

I dont have a direct answer to that, just a few may be not so helpful
hints.

Iam assuming you are using DSP/BIOS in your project and that version is
4.9.

If so, when you migrated your project from 2.2 to 3.1 did you get a CDB
update message? If not, this could be a reason for this problem.

Check out this Q&A from TI:

"How do customers who have old CSL configuration files migrate? 
When customers update to a new release without support for CSL
configuration, the CDB update will check for previously configured CSL
peripherals. If found, it will notify the user that CSL configuration is
no longer supported and then generate two new files that contain the CSL
code that had been provided before. The customer will then be required to
add these two new files to their project"


Anyways,now do you know that the different ways in which CSL was used in
CCS2.2 and can be used in CCS3.1 are different by atleast one way? The GUI
config of CSL using GCONF/TCONF in DSP/BIOS which was possible earlier is
not possible now due to TI abandaning  support for graphical configuration
of peripherals.

Though the CSL versions are theoretically independent of BIOS versions, to
be sure you could try downloading a more appropriate version of CSL for
your target?

Finally, there are some cache initializations done before this?

--Bhooshan
		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com