avr-chat
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-chat] AVR and accelerometers


From: Shashank Chintalagiri
Subject: Re: [avr-chat] AVR and accelerometers
Date: Sun, 18 Nov 2007 15:31:49 +0530

Would electrically isolating the SPI bus from the MCU during
programming be possible/help solve the problem? I was thinking a
tristate bus which is controlled by the reset pin of the SPI
programming interface should be able to do just that, although with
the addition of another IC on the board and on the bus lines, which
also means the IC would have to respond fast enough to the SPI data
signals when the SPI signals are going through it.

On Nov 18, 2007 7:18 AM, Michael Hennebry
<address@hidden> wrote:
> On Fri, 16 Nov 2007, Bob Paddock wrote:
>
> > Now with that stage set we have the entrance of Mr. Murphy.
> >
> > During the exchange between the programming software/hardware
> > communicating with the AVR to load its program, Mr. Murphy throws
> > in a some data bits on the MOSI (SDA/SDI/SDO) line, that are
> > properly clocked (SCL/SPC), from the perspective of the 302, so
> > that the 302 sees its own address.
> >
> > As a now properly selected 302, from the view of the 302, it is
> > obligated to generate an ACK on the SDA/SDI/SDO line.
>
> If one really wants, I think that there is a way around that:
> Find out what data bytes cause the problem and avoid them during ISP.
> Avoiding them and still getting them into
> flash would require writing some pages twice.
> Once for the odd 0s and once for the evens might do the trick.
> If it works, at most 8 passes will be necessary..
> If one can't do ~(1<<0), ... ~(1<<7) and the ISP command bytes,
> the problem is not solveable.
>
> I did write "really wants".
>
> > Remember the programming software is talking to the AVR using
> > this same line as MOSI. This ACK from the 302 does not belong on
> > the MOSI line at this time, creating contention on the MOSI
> > line. This causes the programming software to abort the transfer
> > because the AVR data was found to be corrupted during the
> > verification cycle (just as likely the verification cycle is what
> > is corrupted, but that you may be able to recover from).
>
> --
> Mike   address@hidden
> "Horse guts never lie."  -- Cherek Bear-Shoulders
>
>
>
>
> _______________________________________________
> AVR-chat mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>



-- 
________________________________
Chintalagiri Shashank
Junior Undergraduate
Department of Physics
Indian Institute of Technology, Kanpur

address@hidden
address@hidden
http://home.iitk.ac.in/~chintal
________________________________

I don't believe in If anymore
        If is for children
        Building Daydreams
-Roger Whitaker




reply via email to

[Prev in Thread] Current Thread [Next in Thread]