Closed GoogleCodeExporter closed 8 years ago
Correction: IDL2 is connected to PB0 (pin 19).
Original comment by gru...@gmail.com
on 23 Sep 2011 at 11:03
Original comment by gru...@gmail.com
on 23 Sep 2011 at 11:03
Pin 19 /SS is tied up with the SPI bus. Said bus is shared with the in-circuit
serial programming bus (ISP). Holding this pin low at start-up must be driving
the ISP system into an inappropriate state.
Regardless, /SS is usually used for SPI chip select operations -- that is, as a
/CS. Note that we have SD_CS connected to PB4 instead, however.
Thus, for both these reasons now understood, we need to swap IDL2 with SD_CS.
Original comment by gru...@gmail.com
on 24 Sep 2011 at 2:55
Changes are already done and ready to commit, however we need to find
documentation of this effect the /SS pin is having to be truly sure to avoid
any further disasters. I cannot be happy till I see it in a datasheet. A quick
Google search yeilds nothing, as did a scan through the 2560 datasheet. Need to
find the ISP protocol sheet.
Cam.
Original comment by camw3...@googlemail.com
on 24 Sep 2011 at 11:20
Strange thing is according to the datasheet the SPI hardware is disabled at
boot, and the /SS pin doesn't get used for ISP. Does not compute !
Still looking for the ISP protocol sheet.
Original comment by camw3...@googlemail.com
on 24 Sep 2011 at 11:58
Found the ISP datasheet:
http://www.atmel.com/atmel/acrobat/doc0943.pdf
It makes no mention of the /SS pin, not even as a consideraton. Also the CPU
has to be held in RESET for the ISP to work, so it's hard to imagine that it's
an ISP issue.
Maybe something to do with HVPP (High Voltage Parallel Programming) interface ??
Original comment by camw3...@googlemail.com
on 24 Sep 2011 at 2:02
Found it where I started in the ATMega2560 datasheet:
When the SPI is configured as a Master (MSTR in SPCR is set), the user can
determine the direction of the SS pin.
If SS is configured as an output, the pin is a general output pin which does
not affect the SPI system. Typically, the pin will be driving the SS pin of the
SPI Slave.
If SS is configured as an input, it must be held high to ensure Master SPI
operation. If the SS pin is driven low by peripheral circuitry when the SPI is
configured as a Master with the SS pin defined as an input, the SPI system
interprets this as another master selecting the SPI as a slave and starting to
send data to it. To avoid bus contention, the SPI system takes the following
actions:
1. The MSTR bit in SPCR is cleared and the SPI system becomes a Slave. As a
result of
the SPI becoming a Slave, the MOSI and SCK pins become inputs.
2. The SPIF Flag in SPSR is set, and if the SPI interrupt is enabled, and the
I-bit in SREG is set, the interrupt routine will be executed.
Thus, when interrupt-driven SPI transmission is used in Master mode, and there
exists a possibility that SS is driven low, the interrupt should always check
that the MSTR bit is still set. If the MSTR bit has been cleared by a slave
select, it must be set by the user to re-enable SPI Master mode.
Bugger it's ok as an general purpose output but duff as an input. Please let
this be the last V4.0 error or I may have to tender my resignation :(
Original comment by camw3...@googlemail.com
on 24 Sep 2011 at 2:26
Yup. "Duff as an input". I discovered the same. So it's when the code goes to
initialise the SD card I guess. The SPI bus is stuck in slave mode, which is nt
expected, hence things go bad.
But of course, we need an SD_CS (output) anyway, so we should use this pin as
intended.
Here's how it needs to end up.
Pin 19 (/SS) = SD_CS
Pin 23 (PB4) = IDL2_SW
Pin 25 (OC1B) = PPM_OUT
I'll add Cam's photo of this mod to the Build Your Own Board (PcbAssembly) wiki
page. Thanks Cam.
(We both cut the SD_CS track in about exactly same place, which I found
interesting. Great minds thinking alike? Or just the obvious choice. Perhaps
we'll never know. :P)
Original comment by gru...@gmail.com
on 25 Sep 2011 at 12:14
Original comment by gru...@gmail.com
on 26 Sep 2011 at 9:15
Original issue reported on code.google.com by
gru...@gmail.com
on 23 Sep 2011 at 11:02