Gwyn-

> Thanks for the suggestion.
> 
> Since I sent that last email I have made a little progress:
> 
> I had previously tried the system at various CPU Speeds. I am able to test
> the kernel up to 192Mhz(12Mhz*16) the core and USB all appeared to work
> fine.
> 
> I downloaded the CCS V3.3 which incidentally only arrived with V2.0 if the
> C55xx image lib. When I updated to V2.3 of the image lib I eventually found
> that my DCT buffers were not correctly aligned causing the DCT to work but
> process the data incorrectly. I now have a system that is working with the
> CCS V3.3 a result... sort of. (I have a batch of 300x 5509A boards on their
> way at least I know I can get these working)
> 
> My original CCS V2.21 will not compile working code. I find that the
> routines
> IMG_fdct_8x8(data, tmpBuffer);
> IMG_jpeg_quantize(data, zig_zag, Q_table, outData);
> IMG_jpeg_vlc(outData, pOutBuffer, VLC_status, 0);
> 
> All exhibit some sort of "hanging" behaviour.
> With a probe on XF I can set XF H before the routine and L after, when I run
> my test, XF will remain H and the system will re-boot.

It re-boots?  Gee, that ought to be easy -- at least you're not looking for a small
bit-exactness hiding somewhere.  Just single step through the "IMG_reboot" routine
(sorry, couldn't resist) and find out where your code heads for the hills. 
Single-stepping without source takes some time, but I imagine with 300 boards
depending on this, you've got the time.  Once you go through the code a bit you can
figure out where are the 'safe' sections and use breakpoints to skip ahead, and then
it goes a lot faster.

-Jeff

> I have all interrupts disabled.
> 
> EPIC suggested -vcore:2.2 and I also have -d:CHIP_5509A instead of
> -d:CHIP_5509 set in the compiler.
> 
> Any bright ideas?
> 
> Gwyn
> 
> -----Original Message-----
> From: Jeff Brower [mailto:j...@signalogic.com]
> Sent: 26 March 2007 18:33
> To: Gwyn Evans
> Cc: c...@yahoogroups.com
> Subject: Re: [c55x] Migration problems 5509 to 5509A
> 
> Gwyn-
> 
> > I wonder if there is any one out there who has run in to the same problems
> > that I have while upgrading from 5509 to 5509A.
> >
> > My system is stable and works well with the 5509 but I recently had a
> sample
> > batch of boards back with the 5509A and they caused some problems, most of
> > which I Was able to solve. (I2C and DMA)
> >
> > The DSP is running at 96Mhz so I reduced the core voltage to 1.2v.
> 
> My guess would be there is no compiler, library, or other tools related
> issue, as the two devices run exactly the same
> instruction set.  What happens if you take the 5509 cards and run at 100 MHz
> (still under limit for 5509A at 1.2V).
> You should have enough real-time margin in your code to do that.  Do you
> then see flaky behavior with original 5509
> cards?
> 
> As you can see, I'm speculating that your "code dependent" issues are
> actually there on both processors, but you're
> just getting lucky not to see them on 5509 because some code or memory
> timing is so close to the edge.
> 
> -Jeff
> 
> > The three routines in question are:
> >
> > IMG_fdct_8x8(data, tmpBuffer);
> >
> > IMG_jpeg_quantize(data, zig_zag, Q_table, outData);
> >
> > IMG_jpeg_vlc(outData, (int*)pOutBuffer, VLC_status, 0);
> >
> > Since I am capturing still images I get pseudo random data, I have known
> the
> > IMG_fdct_8x8 to be flaky when presented with 0x00 and 0xff but that was
> > sorted out in a release some time ago.
> >
> > Is there anything special I need to do when compiling for the 5509A?
> >
> > Are the imageLib V2.3 compiled for the 5509A?
> >
> > Is there something I’m missing?
> >
> > I have an embedded system which uses the 55ximagex.lib V2.3, and CCS 2.21
> > (Integrated Development V2.20)
> >
> >
> > Thanks in advance,
> >
> > Gwyn
> >
> > Gwyn Evans
> > Mobile Video Systems
> > Drachenseestr 12
> > 81373 München
> > +4989491689 (Tel)
> > +491733510658 (Mobile)
> > +498936105615 (Fax)