V4.0 -- Won't boot if IDL2 switch active.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Switch unit off
2. Switch 3-way switch (IDL) to third (lowest) position
3. Switch unit on

System won't boot up. In my case, I get garbage all over the screen. There's no 
watch-dog reset or anything. It's just dead.

The DIAG screen indicates that ID01 and IDL2 are both functioning properly 
besides.

IDL2 is connected to PB), also labelled PCINT0 and /SS. Is there some function 
this pin does at system boot time if it's grounded?

Original issue reported on code.google.com by gru...@gmail.com on 23 Sep 2011 at 11:02

[GoogleCodeExporter]

Correction: IDL2 is connected to PB0 (pin 19).

Original comment by gru...@gmail.com on 23 Sep 2011 at 11:03

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 23 Sep 2011 at 11:03

• Changed title: V4.0 -- Won't boot if IDL2 switch active.

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Original comment by gru...@gmail.com on 26 Sep 2011 at 9:15

• Changed state: Verified