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 |