Hi Guru's,
I have come across something weird. I have a bit of code on an Atmega2560
that does three things: is initialises two timers in CTC mode, it
initialises the SPI port to talk to an SD card and it enables the SD card
interface chip by setting PB5 high. This port pin is on the same port (B) as
the SPI interface and the secondary function of this port pin is OC1A.
The following code initialises things:
void main( void )
{
/* init SPI interface */
DDRB = (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB5); /* enable SPI outputs */
PORTB |= (1<<PB4) | (1<<PB5); /* enable pull-up on SD Card Detect signal
and enable SD driver */
SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR1); /* enable SPI, master mode, slow
clock */
SPSR = (1<<SPI2X); /* double SPI clock speed */
/* initialize Timer0 as system timer tick @ 10ms */
TCCR0A = (1<<WGM01); /* mode 2, CTC */
TCCR0B = (1<<CS02) | (1<<CS00); /* CK/1024 */
OCR0A = T0_CMP; /* set interval (see hardware.h) */
TIMSK0 |= (1<<OCIE0A); /* enable T0 Compare Match A interrupt */
/* initialize Timer1 as utility timer tick @ 50ms */
TCCR1B = (1<<WGM12) | (1<<CS12) | (1<<CS10); /* mode 4, CTC, CK/1024) */
OCR1A = T1_CMP; /* set interval (see hardware.h) */
TIMSK1 |= (1<<OCIE1A); /* enable T1 Compare Match A interrupt */
SEI();
wait(3);
for(;;)
{
}
}
When this code enters the wait function, suddenly PB5 is reset to 0.
When I examine this in AVRStudio I see, while I am stepping through the
wait() function, that the moment TCNT1 jumps from 0 to 1, PB5 gets reset to
0. It looks as if PB5/OC1A toggles on a compare event, although none of the
COMnx have been set to output the event on PB5.
The weirdest thing is this: this happens in the complete application running
on the hardware and in the AVRstudio simulator. A small test application
that only tests the SD interface does shows the same problem in the
simpulator but not on the hardware.
I'm completely lost here...
Regards,
Meindert
Silicon bug in Atmega2560?
Started by ●May 14, 2009
Reply by ●June 10, 20092009-06-10
I can't believe noone has come across this besides me..... I got two responses on avrfreaks.net... "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote in message news:4a0c00ca$0$194$e4fe514c@news.xs4all.nl...> Hi Guru's, > > I have come across something weird. I have a bit of code on an Atmega2560 > that does three things: is initialises two timers in CTC mode, it > initialises the SPI port to talk to an SD card and it enables the SD card > interface chip by setting PB5 high. This port pin is on the same port (B)as> the SPI interface and the secondary function of this port pin is OC1A. > > The following code initialises things: > > void main( void ) > { > /* init SPI interface */ > DDRB = (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB5); /* enable SPI outputs*/> PORTB |= (1<<PB4) | (1<<PB5); /* enable pull-up on SD Card Detectsignal> and enable SD driver */ > SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR1); /* enable SPI, master mode,slow> clock */ > SPSR = (1<<SPI2X); /* double SPI clock speed */ > > /* initialize Timer0 as system timer tick @ 10ms */ > TCCR0A = (1<<WGM01); /* mode 2, CTC */ > TCCR0B = (1<<CS02) | (1<<CS00); /* CK/1024 */ > OCR0A = T0_CMP; /* set interval (see hardware.h) */ > TIMSK0 |= (1<<OCIE0A); /* enable T0 Compare Match A interrupt*/> > /* initialize Timer1 as utility timer tick @ 50ms */ > TCCR1B = (1<<WGM12) | (1<<CS12) | (1<<CS10); /* mode 4, CTC, CK/1024) */ > OCR1A = T1_CMP; /* set interval (see hardware.h) */ > TIMSK1 |= (1<<OCIE1A); /* enable T1 Compare Match A interrupt*/> > SEI(); > wait(3); > for(;;) > { > } > } > > When this code enters the wait function, suddenly PB5 is reset to 0. > When I examine this in AVRStudio I see, while I am stepping through the > wait() function, that the moment TCNT1 jumps from 0 to 1, PB5 gets resetto> 0. It looks as if PB5/OC1A toggles on a compare event, although none ofthe> COMnx have been set to output the event on PB5. > > The weirdest thing is this: this happens in the complete applicationrunning> on the hardware and in the AVRstudio simulator. A small test application > that only tests the SD interface does shows the same problem in the > simpulator but not on the hardware. > I'm completely lost here... > > Regards, > Meindert > >
Reply by ●June 10, 20092009-06-10
Meindert Sprang ha scritto:>> The weirdest thing is this: this happens in the complete application > running >> on the hardware and in the AVRstudio simulator.Silicon bug ... in the AVRstudio simulator ? regards -- lowcost
Reply by ●June 11, 20092009-06-11
"lowcost" <die.spam@invalid.com> wrote in message news:h0oiuf$3qu$1@nnrp-beta.newsland.it...> Meindert Sprang ha scritto: > >> The weirdest thing is this: this happens in the complete application > > running > >> on the hardware and in the AVRstudio simulator. > > Silicon bug ... in the AVRstudio simulator ?Well, whatever you and I want to call it, the bug appears both on the processor and the simulator. Meindert
Reply by ●June 11, 20092009-06-11
On Thu, 11 Jun 2009 08:35:41 +0200, "Meindert Sprang" <ms@NOJUNKcustomORSPAMware.nl> wrote:>"lowcost" <die.spam@invalid.com> wrote in message >news:h0oiuf$3qu$1@nnrp-beta.newsland.it... >> Meindert Sprang ha scritto: >> >> The weirdest thing is this: this happens in the complete application >> > running >> >> on the hardware and in the AVRstudio simulator. >> >> Silicon bug ... in the AVRstudio simulator ? > >Well, whatever you and I want to call it, the bug appears both on the >processor and the simulator. > >Meindert >It could well be that the simulator code is derived from the silicon HDL - I know that some of the earlier atmel IC's used the same HDL as the real silicon in an FPGA.
Reply by ●June 11, 20092009-06-11
"Mike Harrison" <mike@whitewing.co.uk> wrote in message news:12m135t1t014ac0rk1j5ad2r180cjgnf4s@4ax.com...> On Thu, 11 Jun 2009 08:35:41 +0200, "Meindert Sprang"<ms@NOJUNKcustomORSPAMware.nl> wrote:> > >"lowcost" <die.spam@invalid.com> wrote in message > >news:h0oiuf$3qu$1@nnrp-beta.newsland.it... > >> Meindert Sprang ha scritto: > >> >> The weirdest thing is this: this happens in the complete application > >> > running > >> >> on the hardware and in the AVRstudio simulator. > >> > >> Silicon bug ... in the AVRstudio simulator ? > > > >Well, whatever you and I want to call it, the bug appears both on the > >processor and the simulator. > > > >Meindert > > > > It could well be that the simulator code is derived from the silicon HDL -I know that some of the> earlier atmel IC's used the same HDL as the real silicon in an FPGA.My thoughts exactly. Which should make it easy for the guys at Atmel to find the bug.... Meindert
Reply by ●June 11, 20092009-06-11
Hi, in my opinion You forgot to initialize stack pointer. As soon as You call a function stack is used. If stack pointer is not set to correct RAM area, return from function will fail. What about interrupts handler ? I see You enable interrupts just before calling 'wait(3)' - are interrupts handlers defined ? Best Regards AK Meindert Sprang pisze:> Hi Guru's, > > I have come across something weird. I have a bit of code on an Atmega2560 > that does three things: is initialises two timers in CTC mode, it > initialises the SPI port to talk to an SD card and it enables the SD card > interface chip by setting PB5 high. This port pin is on the same port (B) as > the SPI interface and the secondary function of this port pin is OC1A. > > The following code initialises things: > > void main( void ) > { > /* init SPI interface */ > DDRB = (1<<PB0) | (1<<PB1) | (1<<PB2) | (1<<PB5); /* enable SPI outputs */ > PORTB |= (1<<PB4) | (1<<PB5); /* enable pull-up on SD Card Detect signal > and enable SD driver */ > SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR1); /* enable SPI, master mode, slow > clock */ > SPSR = (1<<SPI2X); /* double SPI clock speed */ > > /* initialize Timer0 as system timer tick @ 10ms */ > TCCR0A = (1<<WGM01); /* mode 2, CTC */ > TCCR0B = (1<<CS02) | (1<<CS00); /* CK/1024 */ > OCR0A = T0_CMP; /* set interval (see hardware.h) */ > TIMSK0 |= (1<<OCIE0A); /* enable T0 Compare Match A interrupt */ > > /* initialize Timer1 as utility timer tick @ 50ms */ > TCCR1B = (1<<WGM12) | (1<<CS12) | (1<<CS10); /* mode 4, CTC, CK/1024) */ > OCR1A = T1_CMP; /* set interval (see hardware.h) */ > TIMSK1 |= (1<<OCIE1A); /* enable T1 Compare Match A interrupt */ > > SEI(); > wait(3); > for(;;) > { > } > } > > When this code enters the wait function, suddenly PB5 is reset to 0. > When I examine this in AVRStudio I see, while I am stepping through the > wait() function, that the moment TCNT1 jumps from 0 to 1, PB5 gets reset to > 0. It looks as if PB5/OC1A toggles on a compare event, although none of the > COMnx have been set to output the event on PB5. > > The weirdest thing is this: this happens in the complete application running > on the hardware and in the AVRstudio simulator. A small test application > that only tests the SD interface does shows the same problem in the > simpulator but not on the hardware. > I'm completely lost here... > > Regards, > Meindert > >
Reply by ●June 11, 20092009-06-11
Meindert Sprang wrote:> "Mike Harrison" <mike@whitewing.co.uk> wrote: >> "Meindert Sprang" >>> "lowcost" <die.spam@invalid.com> wrote: >>>... snip ...>>> >>>> Silicon bug ... in the AVRstudio simulator ? >>> >>> Well, whatever you and I want to call it, the bug appears both >>> on the processor and the simulator. >> >> It could well be that the simulator code is derived from the >> silicon HDL - I know that some of the earlier atmel IC's used >> the same HDL as the real silicon in an FPGA. > > My thoughts exactly. Which should make it easy for the guys at > Atmel to find the bug....What's the complaint? I would want the simulator to _accurately_ simulate the actual processor. -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section.
