IDLE Mode for C5509A

Hi,

i hope anyone can help me concerning the idle-mode of the 5509A.
The ISTR Register shows me 3F - everthing idle that i want but
the VCore yet comsumes 12 mA.
The problem occurs both when starting the programm in the emulator
and starting it from SPI.
Also i have switched off RTDX in my BIOS Config File.

Could the problem be the USBDPLL?
Im not sure if i understood right the diagramm in SPRA078C for
disabling the internal oscillator. I have a 20 MHZ external Crystal and
dont use USB for anything (except the JTAG Emulator).
Im using the folowing code:
CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
*(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
*(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
*(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
*(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
*(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
*(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
*(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
*(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
*(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
*(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
*(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
*(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
*(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
for (i=0;i<50;i++) {asm(" NOP");} //waiting
asm(" IDLE");
for (i=0;i<`;i++) {asm(" NOP");} //waiting
PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
asm(" IDLE");
//after waking up the programs resumes here, that works

Thanks for your help!

Christoph Start a New Thread

Christoph-

> i hope anyone can help me concerning the idle-mode of the 5509A.
> The ISTR Register shows me 3F - everthing idle that i want but
> the VCore yet comsumes 12 mA.
> The problem occurs both when starting the programm in the emulator
> and starting it from SPI.
> Also i have switched off RTDX in my BIOS Config File.
>
> Could the problem be the USBDPLL?
> Im not sure if i understood right the diagramm in SPRA078C for
> disabling the internal oscillator. I have a 20 MHZ external Crystal and
> don't use USB for anything (except the JTAG Emulator).

Ok, but what about the JTAG emulator? If you have JTAG circuitry active on the DSP,
then how much power does it consume?

I suggest to run some small, self-contained, non-JTAG dependent code, and then make
some measurements.

As a side note, the if this is a DSK card, the USB connection on the card doesn't
actually use the 5509A USB peripheral. The card USB interface connects to
proprietary Spectrum Digital circuitry that is non-documented (no, not even in the
published schematic) and from there controls the JTAG interface on the DSP. To me
that says even if you run without JTAG + CCS active, you still don't really know what
you're getting. Who knows what the Spectrum Digital circuitry is doing with the DSP
at any given time? Non-documented black hole, not exactly in the spirit of the word
"Starter" in "DSP Starter Kit". Any DSK card with the 320DA250 "audio DSP" device
and Actel FPGA on it has this problem.

-Jeff
> Im using the folowing code:
>
> CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
> CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
> CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
> *(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
> *(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
> *(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
> *(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
> *(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
> *(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
> *(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
> *(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
> *(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
> *(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
> *(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
> *(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
> *(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
> PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
> for (i=0;i<50;i++) {asm(" NOP");} //waiting
> asm(" IDLE");
> for (i=0;i<`;i++) {asm(" NOP");} //waiting
> PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
> asm(" IDLE");
> //after waking up the programs resumes here, that works
>
> Thanks for your help!
>
> Christoph
> Start a New Thread

Hello all,



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.



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 Im 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 Mchen

+4989491689 (Tel)

+491733510658 (Mobile)

+498936105615 (Fax)



Start a New Thread

Hi Jeff,

thanks for your help.

Im using a self designed board - no DSK. And i also dont have
the JTAG Emulator on board but only the JTAG connectors. I use
the Blackhawk JTAG Emulator that is connected externally.
Besides the board has special pins only for the measurements
of VCore current comsumption.

Could it be, that JTAG is active in any way and causes the high
current comsumption?
Actually i dont use JTAG - i compile the code, transfer it to the
SPI-Flash and boot from there (without connection to the Emulator).

Or do i have to configure something more in the cdb File?

I really dont know what to do further..
Id be glad if you would have any idea.

Thanks a lot,

Christoph

Christoph-
>
>> i hope anyone can help me concerning the idle-mode of the 5509A.
>> The ISTR Register shows me 3F - everthing idle that i want but
>> the VCore yet comsumes 12 mA.
>> The problem occurs both when starting the programm in the emulator
>> and starting it from SPI.
>> Also i have switched off RTDX in my BIOS Config File.
>>
>> Could the problem be the USBDPLL?
>> Im not sure if i understood right the diagramm in SPRA078C for
>> disabling the internal oscillator. I have a 20 MHZ external Crystal and
>> don't use USB for anything (except the JTAG Emulator).
>
>Ok, but what about the JTAG emulator? If you have JTAG circuitry active on the DSP,
>then how much power does it consume?
>
>I suggest to run some small, self-contained, non-JTAG dependent code, and then make
>some measurements.
>
>As a side note, the if this is a DSK card, the USB connection on the card doesn't
>actually use the 5509A USB peripheral. The card USB interface connects to
>proprietary Spectrum Digital circuitry that is non-documented (no, not even in the
>published schematic) and from there controls the JTAG interface on the DSP. To me
>that says even if you run without JTAG + CCS active, you still don't really know what
>you're getting. Who knows what the Spectrum Digital circuitry is doing with the DSP
>at any given time? Non-documented black hole, not exactly in the spirit of the word
>"Starter" in "DSP Starter Kit". Any DSK card with the 320DA250 "audio DSP" device
>and Actel FPGA on it has this problem.
>
>-Jeff
>> Im using the folowing code:
>>
>> CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
>> CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
>> CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
>> *(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
>> *(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
>> *(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
>> *(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
>> *(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
>> *(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
>> *(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
>> *(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
>> *(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
>> *(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
>> *(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
>> *(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
>> *(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
>> PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
>> for (i=0;i asm(" IDLE");
>> for (i=0;i PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
>> asm(" IDLE");
>> //after waking up the programs resumes here, that works
>>
>> Thanks for your help!
>>
>> Christoph
>> Start a New Thread

Christoph-

> Im using a self designed board - no DSK. And i also dont have
> the JTAG Emulator on board but only the JTAG connectors. I use
> the Blackhawk JTAG Emulator that is connected externally.
> Besides the board has special pins only for the measurements
> of VCore current comsumption.
>
> Could it be, that JTAG is active in any way and causes the high
> current comsumption?
> Actually i dont use JTAG - i compile the code, transfer it to the
> SPI-Flash and boot from there (without connection to the Emulator).

Ok, but then I don't understand your previous comment:

"...I don't use USB for anything (except the JTAG Emulator)."

Exactly how is USB on the C5509A connected on your board? To what? This comment was why I thought you might have a
DSK card. You have to be more clear about your USB -- even you in your previous e-mail mention that as a suspect for
extra current draw.

-Jeff

> Or do i have to configure something more in the cdb File?
>
> I really dont know what to do further..
> Id be glad if you would have any idea.
>
> Thanks a lot,
>
> Christoph
>
> Christoph-
>>
>>> i hope anyone can help me concerning the idle-mode of the 5509A.
>>> The ISTR Register shows me 3F - everthing idle that i want but
>>> the VCore yet comsumes 12 mA.
>>> The problem occurs both when starting the programm in the emulator
>>> and starting it from SPI.
>>> Also i have switched off RTDX in my BIOS Config File.
>>>
>>> Could the problem be the USBDPLL?
>>> Im not sure if i understood right the diagramm in SPRA078C for
>>> disabling the internal oscillator. I have a 20 MHZ external Crystal and
>>> don't use USB for anything (except the JTAG Emulator).
>>
>>Ok, but what about the JTAG emulator? If you have JTAG circuitry active on the DSP,
>>then how much power does it consume?
>>
>>I suggest to run some small, self-contained, non-JTAG dependent code, and then make
>>some measurements.
>>
>>As a side note, the if this is a DSK card, the USB connection on the card doesn't
>>actually use the 5509A USB peripheral. The card USB interface connects to
>>proprietary Spectrum Digital circuitry that is non-documented (no, not even in the
>>published schematic) and from there controls the JTAG interface on the DSP. To me
>>that says even if you run without JTAG + CCS active, you still don't really know what
>>you're getting. Who knows what the Spectrum Digital circuitry is doing with the DSP
>>at any given time? Non-documented black hole, not exactly in the spirit of the word
>>"Starter" in "DSP Starter Kit". Any DSK card with the 320DA250 "audio DSP" device
>>and Actel FPGA on it has this problem.
>>
>>-Jeff
>>> Im using the folowing code:
>>>
>>> CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
>>> CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
>>> CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
>>> *(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
>>> *(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
>>> *(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
>>> *(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
>>> *(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
>>> *(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
>>> *(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
>>> *(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
>>> *(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
>>> *(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
>>> *(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
>>> *(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
>>> *(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
>>> PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
>>> for (i=0;i asm(" IDLE");
>>> for (i=0;i PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
>>> asm(" IDLE");
>>> //after waking up the programs resumes here, that works
>>>
>>> Thanks for your help!
>>>
>>> Christoph
>> Start a New Thread

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 Im 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 Mchen
> +4989491689 (Tel)
> +491733510658 (Mobile)
> +498936105615 (Fax) Start a New Thread

Hi,

sorry for my imprecision - i dont use USB on the board.
I have the JTAG connection pins on the board and use an external
JTAG emulator.
Meantime i think ive come a little bit further. i noticed that
although i deactivated rtdx and hst in the cdb File im still able
to poll the memory and the registers in the memory map.
is that ok? is it possible that i need a different cdb file?
i use the c55xx.cdb.

any ideas?
Thanks for your help

Christoph

Christoph-
>
>> Im using a self designed board - no DSK. And i also dont have
>> the JTAG Emulator on board but only the JTAG connectors. I use
>> the Blackhawk JTAG Emulator that is connected externally.
>> Besides the board has special pins only for the measurements
>> of VCore current comsumption.
>>
>> Could it be, that JTAG is active in any way and causes the high
>> current comsumption?
>> Actually i dont use JTAG - i compile the code, transfer it to the
>> SPI-Flash and boot from there (without connection to the Emulator).
>
>Ok, but then I don't understand your previous comment:
>
> "...I don't use USB for anything (except the JTAG Emulator)."
>
>Exactly how is USB on the C5509A connected on your board? To what? This comment was why I thought you might have a
>DSK card. You have to be more clear about your USB -- even you in your previous e-mail mention that as a suspect for
>extra current draw.
>
>-Jeff
>
>> Or do i have to configure something more in the cdb File?
>>
>> I really dont know what to do further..
>> Id be glad if you would have any idea.
>>
>> Thanks a lot,
>>
>> Christoph
>>
>> Christoph-
>> >
>> > > i hope anyone can help me concerning the idle-mode of the 5509A.
>> > > The ISTR Register shows me 3F - everthing idle that i want but
>> > > the VCore yet comsumes 12 mA.
>> > > The problem occurs both when starting the programm in the emulator
>> > > and starting it from SPI.
>> > > Also i have switched off RTDX in my BIOS Config File.
>> > >
>> > > Could the problem be the USBDPLL?
>> > > Im not sure if i understood right the diagramm in SPRA078C for
>> > > disabling the internal oscillator. I have a 20 MHZ external Crystal and
>> > > don't use USB for anything (except the JTAG Emulator).
>> >
>> > Ok, but what about the JTAG emulator? If you have JTAG circuitry active on the DSP,
>> > then how much power does it consume?
>> >
>> > I suggest to run some small, self-contained, non-JTAG dependent code, and then make
>> > some measurements.
>> >
>> > As a side note, the if this is a DSK card, the USB connection on the card doesn't
>> > actually use the 5509A USB peripheral. The card USB interface connects to
>> > proprietary Spectrum Digital circuitry that is non-documented (no, not even in the
>> > published schematic) and from there controls the JTAG interface on the DSP. To me
>> > that says even if you run without JTAG + CCS active, you still don't really know what
>> > you're getting. Who knows what the Spectrum Digital circuitry is doing with the DSP
>> > at any given time? Non-documented black hole, not exactly in the spirit of the word
>> > "Starter" in "DSP Starter Kit". Any DSK card with the 320DA250 "audio DSP" device
>> > and Actel FPGA on it has this problem.
>> >
>> > -Jeff
>> > > Im using the folowing code:
>> > >
>> > > CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
>> > > CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
>> > > CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
>> > > *(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
>> > > *(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
>> > > *(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
>> > > *(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
>> > > *(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
>> > > *(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
>> > > *(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
>> > > *(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
>> > > *(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
>> > > *(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
>> > > *(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
>> > > *(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
>> > > *(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
>> > > PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
>> > > for (i=0;i asm(" IDLE");
>> > > for (i=0;i PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
>> > > asm(" IDLE");
>> > > //after waking up the programs resumes here, that works
>> > >
>> > > Thanks for your help!
>> > >
>> > > Christoph
>> > Start a New Thread

-Hi all, and Jeff

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.

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...
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 Im 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 Mchen
> +4989491689 (Tel)
> +491733510658 (Mobile)
> +498936105615 (Fax)

Start a New Thread

Christoph-

> sorry for my imprecision - i don't use USB on the board.
> I have the JTAG connection pins on the board and use an external
> JTAG emulator.

Ok.

> Meantime i think ive come a little bit further. i noticed that
> although i deactivated rtdx and hst in the cdb File i'm still able
> to poll the memory and the registers in the memory map.
> is that ok?

Are you saying that without RTDX enabled, you measure decreased power consumption?
Please confirm we're still discussing your original issue -- 12 mA in idle mode that
you want to reduce. In any case, if you can live without RTDX during your debug then
I see no problem with leaving it that way.

> is it possible that i need a different cdb file?
> i use the c55xx.cdb.

Yes it's possible, but it would be a vendor issue. They should know and have
recommendations in this area.

-Jeff

> Christoph-
> >
> >> Im using a self designed board - no DSK. And i also don't have
> >> the JTAG Emulator on board but only the JTAG connectors. I use
> >> the Blackhawk JTAG Emulator that is connected externally.
> >> Besides the board has special pins only for the measurements
> >> of VCore current comsumption.
> >>
> >> Could it be, that JTAG is active in any way and causes the high
> >> current comsumption?
> >> Actually i dont use JTAG - i compile the code, transfer it to the
> >> SPI-Flash and boot from there (without connection to the Emulator).
> >
> >Ok, but then I don't understand your previous comment:
> >
> > "...I don't use USB for anything (except the JTAG Emulator)."
> >
> >Exactly how is USB on the C5509A connected on your board? To what? This comment was why I thought you might have a
> >DSK card. You have to be more clear about your USB -- even you in your previous e-mail mention that as a suspect for
> >extra current draw.
> >
> >-Jeff
> >
> >> Or do i have to configure something more in the cdb File?
> >>
> >> I really dont know what to do further..
> >> Id be glad if you would have any idea.
> >>
> >> Thanks a lot,
> >>
> >> Christoph
> >>
> >> Christoph-
> >> >
> >> > > i hope anyone can help me concerning the idle-mode of the 5509A.
> >> > > The ISTR Register shows me 3F - everthing idle that i want but
> >> > > the VCore yet comsumes 12 mA.
> >> > > The problem occurs both when starting the programm in the emulator
> >> > > and starting it from SPI.
> >> > > Also i have switched off RTDX in my BIOS Config File.
> >> > >
> >> > > Could the problem be the USBDPLL?
> >> > > Im not sure if i understood right the diagramm in SPRA078C for
> >> > > disabling the internal oscillator. I have a 20 MHZ external Crystal and
> >> > > don't use USB for anything (except the JTAG Emulator).
> >> >
> >> > Ok, but what about the JTAG emulator? If you have JTAG circuitry active on the DSP,
> >> > then how much power does it consume?
> >> >
> >> > I suggest to run some small, self-contained, non-JTAG dependent code, and then make
> >> > some measurements.
> >> >
> >> > As a side note, the if this is a DSK card, the USB connection on the card doesn't
> >> > actually use the 5509A USB peripheral. The card USB interface connects to
> >> > proprietary Spectrum Digital circuitry that is non-documented (no, not even in the
> >> > published schematic) and from there controls the JTAG interface on the DSP. To me
> >> > that says even if you run without JTAG + CCS active, you still don't really know what
> >> > you're getting. Who knows what the Spectrum Digital circuitry is doing with the DSP
> >> > at any given time? Non-documented black hole, not exactly in the spirit of the word
> >> > "Starter" in "DSP Starter Kit". Any DSK card with the 320DA250 "audio DSP" device
> >> > and Actel FPGA on it has this problem.
> >> >
> >> > -Jeff
> >> > > Im using the folowing code:
> >> > >
> >> > > CHIP_RSET(IFR0,0xFFFF); //Clear IFR0
> >> > > CHIP_RSET(IFR1,0xFFFF); //Clear IFR1
> >> > > CHIP_FSET(IER1,INT1,1), //Enable INT1 as WakeUp Interrupt
> >> > > *(ioport volatile unsigned int *)0x6c00 = 0x8000; // Clockout disable in External Bus Selection Register
> >> > > *(ioport volatile unsigned int *)0x1E00 = 0x2000; // set USB DPLL to x4 in USB DPLL register
> >> > > *(ioport volatile unsigned int *)0x1E00 = 0x210; // set lock bit
> >> > > *(ioport volatile unsigned int *)0x7000 = 0x4; // activate USB (USB Reset = 1) in USB IDLE Control register
> >> > > *(ioport volatile unsigned int *)0x67FC |= 0x80; // pull DP high in USB CTL
> >> > > *(ioport volatile unsigned int *)0x7000 = 0x5; // activate USB and enable USB idle (USB Reset =1, USB Idle = 1)
> >> > > *(ioport volatile unsigned int *)0x6C00 = 0xC000; // Clockout & osc disable in External Bus Selection Register
> >> > > *(ioport volatile unsigned int *)0x3C09 = 0x1000; // IDLE IIC with ICMDR
> >> > > *(ioport volatile unsigned int *)0x2812 |=0x4000; // IDLE McBSP0 with PCR0
> >> > > *(ioport volatile unsigned int *)0x2C12 |=0x4000; // IDLE McBSP1 with PCR1
> >> > > *(ioport volatile unsigned int *)0x3012 |=0x4000; // IDLE McBSP2 with PCR2
> >> > > *(ioport volatile unsigned int *)0x1002 |= 0x8000; // IDLE Timer0 with TCR0
> >> > > *(ioport volatile unsigned int *)0x2402 |= 0x8000; // IDLE Timer1 with TCR1
> >> > > PWR_RSET(ICR,0x2E); // Setting ICR idle for all except CPU and CLK
> >> > > for (i=0;i asm(" IDLE");
> >> > > for (i=0;i PWR_RSET(ICR,0x3F); //Setting everything idle in ICR
> >> > > asm(" IDLE");
> >> > > //after waking up the programs resumes here, that works
> >> > >
> >> > > Thanks for your help!
> >> > >
> >> > > Christoph Start a New Thread

Garbiel-

>>Are you saying that without RTDX enabled, you measure decreased power consumption?
>>Please confirm we're still discussing your original issue -- 12 mA in idle mode that
>>you want to reduce. In any case, if you can live without RTDX during your debug then
>>I see no problem with leaving it that way.
>
> No, what I wanted to say was that I was surprised at the fact, that obviously
> the RTDX communication is still working and that I supposed that my cdb File
> didnt disable RTDX. I of course can live without RTDX during emulation.
> And I think that RTDX is the last thing I have to handle so that the idle mode
> works right.
>
> I would be very glas, if you had further ideas about this problem.

Which problem? I asked you to confirm the discussion in the para above and you didn't. And you cut off our previous
dialog from this message -- are you expecting me to go back and look up your posts?

Effective communication is absolutely required to be successful in engineering. It's your reponsibility to describe
the problem in detail, make sure each message stands on its own, and come back with requested information promptly.
Otherwise you can't expect help.

-Jeff Start a New Thread