Forums

TI Chip Support Library DAT_ Module Problems in CCS 3.1

Started by Randy Yates September 30, 2005
Hi,

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

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