|
We recently
upgraded the CSL to 2.31.00.5.
This broke
code which had been working for months, just as we needed to prepare trial units
for
an
important customer.
After much
delving in the CSL source we found that someone has once again changed the
way
DMA source
and destination addresses are set!
About a
year ago the dmacdsau and dmacssau members were made
redundant, since the whole 24 (32) bit addresss was passed in dmacdsal
or dmacssal, masquerading as a function pointer
in order to allow 32-bit range.
At that
time this caused us lots of grief because nothing was said in the release notes
to alert users
to the
change (see case #31780731, e.g. my mail of 19th April 2003), and
the help was not updated.
We of
course then changed our code, everywhere removing code involving the redundant
upper address parts.
Now you
have sort of reverted to the old way: dmacdsal and dmacssal
are still fake 32-bit pointers,
but only
the low 16 bits are used, while all higher bits have to again be passed in
dmacdsau or dmacssau.
Once again
without a word of warning in the release notes.
So we had
to spend a lot of man hours finding out what you have done to mess up our
previously
working
code, at a very critical time.
Another gripe is that Releasenote.htm contains
an explanation of how to set up the build environment to use the new CSL - it
doesn't work that way at all, as anyone who has actually used it in CCS
would know. I can give you details of our workaround if anyone is
interested.
This gives
a very poor impression of the way your development team
works.
 Paul Pignon, CTOBorthwick Pignon Solutions http://bps.co.ee Tartu Science Park Riia 185 51014 Tartu Estonia Office +372 7 302641 Mob +372 53 463942 |
|
|
C55xx CSL 2.31.00.5 - DMA addressing changed again!
Started by ●April 23, 2004
Reply by ●April 23, 20042004-04-23
|
Paul- Yes we all know that these things happen. It is a common experience with embedded system and IC tools vendors, and TI is no exception. But my question to you, as a CTO who is complaining: why spend so many man-hours? Why are your engineers not asking questions on the groups? Is that not the one of the MAIN purposes of the tech groups? You could have documented this problem and had your answers in a day. The way engineering works has changed dramatically due to the Internet. Certainly a lot of American companies have a hard time to accept this -- they are afraid of of revealing IP on the groups, which is dumb, outdated, yr-2000 thinking. Instead, they continue to move slowly, while the rest of the world gets work done more efficiently, and products to market faster. Well, they will learn the hard way. But I would have thought that in Estonia, you are up on the curve. Your engineers should be on the groups day-in, day-out. Why not? I have been on the DSP groups for years, and not once have I seen a question from BPS, not once. In this situation, TI's tools are definitely not the problem. -Jeff Paul Pignon wrote: > We recently upgraded the CSL to 2.31.00.5.This broke code which had been working > for months, just as we needed to prepare trial units foran important customer.After > much delving in the CSL source we found that someone has once again changed the > wayDMA source and destination addresses are set!About a year ago the dmacdsau and > dmacssau members were made redundant, since the whole 24 (32) bit addresss was > passed in dmacdsal or dmacssal, masquerading as a function pointer in order to > allow 32-bit range.At that time this caused us lots of grief because nothing was > said in the release notes to alert usersto the change (see case #31780731, e.g. my > mail of 19th April 2003), and the help was not updated.We of course then changed > our code, everywhere removing code involving the redundant upper address parts.Now > you have sort of reverted to the old way: dmacdsal and dmacssal are still fake > 32-bit pointers,but only the low 16 bits are used, while all higher bits have to > again be passed in dmacdsau or dmacssau. Once again without a word of warning in > the release notes.So we had to spend a lot of man hours finding out what you have > done to mess up our previouslyworking code, at a very critical time. Another gripe > is that Releasenote.htm contains an explanation of how to set up the build > environment to use the new CSL - it doesn't work that way at all, as anyone who has > actually used it in CCS would know. I can give you details of our workaround if > anyone is interested.This gives a very poor impression of the way your development > team works.Paul Pignon, CTO > Borthwick Pignon Solutions > http://bps.co.ee > Tartu Science Park > Riia 185 > 51014 Tartu > Estonia > Office +372 7 302641 > Mob +372 53 463942 |
|
|
Reply by ●April 27, 20042004-04-27
|
Jeff, That's an interesting perspective on the situation, but ultimately shouldn't the company who provided the CSL be responsible for helping their customers solve problems that they may be having with their product? I agree one should use all available resources wisely before "re- inventing the wheel", but the first place I would to start is by calling/contacting the CSL provider (TI) and asking for tech support. Paul did not indicate whether he attempted this route or not, but I don't think it is TI's intention to have its customer's rely on user groups and bulletin boards for tech support. -Shawn Steenhagen Software Specialist www.appliedsignalprocessing.com --- In , Jeff Brower <jbrower@s...> wrote: > Paul- > > Yes we all know that these things happen. It is a common experience with embedded > system and IC tools vendors, and TI is no exception. > > But my question to you, as a CTO who is complaining: why spend so many man-hours? > Why are your engineers not asking questions on the groups? Is that not the one of > the MAIN purposes of the tech groups? You could have documented this problem and had > your answers in a day. > > The way engineering works has changed dramatically due to the Internet. Certainly a > lot of American companies have a hard time to accept this -- they are afraid of of > revealing IP on the groups, which is dumb, outdated, yr-2000 thinking. Instead, they > continue to move slowly, while the rest of the world gets work done more efficiently, > and products to market faster. Well, they will learn the hard way. > > But I would have thought that in Estonia, you are up on the curve. Your engineers > should be on the groups day-in, day-out. Why not? I have been on the DSP groups for > years, and not once have I seen a question from BPS, not once. In this situation, > TI's tools are definitely not the problem. > > -Jeff > > Paul Pignon wrote: > > > We recently upgraded the CSL to 2.31.00.5.This broke code which had been working > > for months, just as we needed to prepare trial units foran important customer.After > > much delving in the CSL source we found that someone has once again changed the > > wayDMA source and destination addresses are set!About a year ago the dmacdsau and > > dmacssau members were made redundant, since the whole 24 (32) bit addresss was > > passed in dmacdsal or dmacssal, masquerading as a function pointer in order to > > allow 32-bit range.At that time this caused us lots of grief because nothing was > > said in the release notes to alert usersto the change (see case #31780731, e.g. my > > mail of 19th April 2003), and the help was not updated.We of course then changed > > our code, everywhere removing code involving the redundant upper address parts.Now > > you have sort of reverted to the old way: dmacdsal and dmacssal are still fake > > 32-bit pointers,but only the low 16 bits are used, while all higher bits have to > > again be passed in dmacdsau or dmacssau. Once again without a word of warning in > > the release notes.So we had to spend a lot of man hours finding out what you have > > done to mess up our previouslyworking code, at a very critical time. Another gripe > > is that Releasenote.htm contains an explanation of how to set up the build > > environment to use the new CSL - it doesn't work that way at all, as anyone who has > > actually used it in CCS would know. I can give you details of our workaround if > > anyone is interested.This gives a very poor impression of the way your development > > team works.Paul Pignon, CTO > > Borthwick Pignon Solutions > > http://bps.co.ee > > Tartu Science Park > > Riia 185 > > 51014 Tartu > > Estonia > > Office +372 7 302641 > > Mob +372 53 463942 > > > > |
Reply by ●April 28, 20042004-04-28
|
Thanks to Paul the change in the api has been spotted. A small note: one of the oldest (and having one of the largest software collections) network resourses, netlib.org once in the old times had an email interface to the ftp service. Once an email inquiry were sent the server returned the software asked for in an email's attachement, preceeded with the words: "Caveat receiptor. Anything free comes with no guarantee" -- AN > Date: Tue, 27 Apr 2004 13:54:55 -0000 > From: "sks_dsp" <> > Subject: Re: C55xx CSL 2.31.00.5 - DMA addressing changed again! > > Jeff, > That's an interesting perspective on the situation, but ultimately > shouldn't the company who provided the CSL be responsible for helping > their customers solve problems that they may be having with their > product? > > I agree one should use all available resources wisely before "re- > inventing the wheel", but the first place I would to start is by > calling/contacting the CSL provider (TI) and asking for tech support. > > Paul did not indicate whether he attempted this route or not, but I > don't think it is TI's intention to have its customer's rely on user > groups and bulletin boards for tech support. > > -Shawn Steenhagen > Software Specialist > www.appliedsignalprocessing.com > > --- In , Jeff Brower <jbrower@s...> wrote: > > Paul- > > > > Yes we all know that these things happen. It is a common > experience with embedded > > system and IC tools vendors, and TI is no exception. > > > > But my question to you, as a CTO who is complaining: why spend so > many man-hours? > > Why are your engineers not asking questions on the groups? Is that > not the one of > > the MAIN purposes of the tech groups? You could have documented > this problem and had > > your answers in a day. > > > > The way engineering works has changed dramatically due to the > Internet. Certainly a > > lot of American companies have a hard time to accept this -- they > are afraid of of > > revealing IP on the groups, which is dumb, outdated, yr-2000 > thinking. Instead, they > > continue to move slowly, while the rest of the world gets work done > more efficiently, > > and products to market faster. Well, they will learn the hard way. > > > > But I would have thought that in Estonia, you are up on the curve. > Your engineers > > should be on the groups day-in, day-out. Why not? I have been on > the DSP groups for > > years, and not once have I seen a question from BPS, not once. In > this situation, > > TI's tools are definitely not the problem. > > > > -Jeff > > > > Paul Pignon wrote: > > > > > We recently upgraded the CSL to 2.31.00.5.This broke code which > had been working > > > for months, just as we needed to prepare trial units foran > important customer.After > > > much delving in the CSL source we found that someone has once > again changed the > > > wayDMA source and destination addresses are set!About a year ago > the dmacdsau and > > > dmacssau members were made redundant, since the whole 24 (32) bit > addresss was > > > passed in dmacdsal or dmacssal, masquerading as a function > pointer in order to > > > allow 32-bit range.At that time this caused us lots of grief > because nothing was > > > said in the release notes to alert usersto the change (see case > #31780731, e.g. my > > > mail of 19th April 2003), and the help was not updated.We of > course then changed > > > our code, everywhere removing code involving the redundant upper > address parts.Now > > > you have sort of reverted to the old way: dmacdsal and dmacssal > are still fake > > > 32-bit pointers,but only the low 16 bits are used, while all > higher bits have to > > > again be passed in dmacdsau or dmacssau. Once again without a > word of warning in > > > the release notes.So we had to spend a lot of man hours finding > out what you have > > > done to mess up our previouslyworking code, at a very critical > time. Another gripe > > > is that Releasenote.htm contains an explanation of how to set up > the build > > > environment to use the new CSL - it doesn't work that way at all, > as anyone who has > > > actually used it in CCS would know. I can give you details of our > workaround if > > > anyone is interested.This gives a very poor impression of the way > your development > > > team works.Paul Pignon, CTO > > > Borthwick Pignon Solutions > > > http://bps.co.ee > > > Tartu Science Park > > > Riia 185 > > > 51014 Tartu > > > Estonia > > > Office +372 7 302641 > > > Mob +372 53 463942 > > > > > > |
Reply by ●April 28, 20042004-04-28
|
Hi Shawn- > That's an interesting perspective on the situation, but ultimately > shouldn't the company who provided the CSL be responsible for helping > their customers solve problems that they may be having with their > product? > > I agree one should use all available resources wisely before "re- > inventing the wheel", but the first place I would to start is by > calling/contacting the CSL provider (TI) and asking for tech support. > > Paul did not indicate whether he attempted this route or not, but I > don't think it is TI's intention to have its customer's rely on user > groups and bulletin boards for tech support. Yes I would agree. And TI will respond, but it can take time. My thinking is purely practical and from a management perspective -- as soon as it becomes clear it's something like a bug caused by a tools update (i.e. not your own design problem or coding error), ask both TI and on groups and try not to spend to much time exploring. BTW, Paul later clarified that his crew only spent about 4 hrs before figuring out what undocumented change TI had done, which is not bad at all. -Jeff > --- In , Jeff Brower <jbrower@s...> wrote: > > Paul- > > > > Yes we all know that these things happen. It is a common > experience with embedded > > system and IC tools vendors, and TI is no exception. > > > > But my question to you, as a CTO who is complaining: why spend so > many man-hours? > > Why are your engineers not asking questions on the groups? Is that > not the one of > > the MAIN purposes of the tech groups? You could have documented > this problem and had > > your answers in a day. > > > > The way engineering works has changed dramatically due to the > Internet. Certainly a > > lot of American companies have a hard time to accept this -- they > are afraid of of > > revealing IP on the groups, which is dumb, outdated, yr-2000 > thinking. Instead, they > > continue to move slowly, while the rest of the world gets work done > more efficiently, > > and products to market faster. Well, they will learn the hard way. > > > > But I would have thought that in Estonia, you are up on the curve. > Your engineers > > should be on the groups day-in, day-out. Why not? I have been on > the DSP groups for > > years, and not once have I seen a question from BPS, not once. In > this situation, > > TI's tools are definitely not the problem. > > > > -Jeff > > > > Paul Pignon wrote: > > > > > We recently upgraded the CSL to 2.31.00.5.This broke code which > had been working > > > for months, just as we needed to prepare trial units foran > important customer.After > > > much delving in the CSL source we found that someone has once > again changed the > > > wayDMA source and destination addresses are set!About a year ago > the dmacdsau and > > > dmacssau members were made redundant, since the whole 24 (32) bit > addresss was > > > passed in dmacdsal or dmacssal, masquerading as a function > pointer in order to > > > allow 32-bit range.At that time this caused us lots of grief > because nothing was > > > said in the release notes to alert usersto the change (see case > #31780731, e.g. my > > > mail of 19th April 2003), and the help was not updated.We of > course then changed > > > our code, everywhere removing code involving the redundant upper > address parts.Now > > > you have sort of reverted to the old way: dmacdsal and dmacssal > are still fake > > > 32-bit pointers,but only the low 16 bits are used, while all > higher bits have to > > > again be passed in dmacdsau or dmacssau. Once again without a > word of warning in > > > the release notes.So we had to spend a lot of man hours finding > out what you have > > > done to mess up our previouslyworking code, at a very critical > time. Another gripe > > > is that Releasenote.htm contains an explanation of how to set up > the build > > > environment to use the new CSL - it doesn't work that way at all, > as anyone who has > > > actually used it in CCS would know. I can give you details of our > workaround if > > > anyone is interested.This gives a very poor impression of the way > your development > > > team works.Paul Pignon, CTO > > > Borthwick Pignon Solutions > > > http://bps.co.ee > > > Tartu Science Park > > > Riia 185 > > > 51014 Tartu > > > Estonia > > > Office +372 7 302641 > > > Mob +372 53 463942 |
