can not upload sketch via Wifi while shield is plugged in

I have problems uploading sketches via Wifi while a shield is plugged in. The shield (handmade) connects the Yun with a RFMxx module, I'm using the ICSP header for this, wiring see http://lowpowerlab.com/wp-content/uploads/2012/12/rfm12B-arduino-moteino-atmega328_5V_connections.png ICSP see http://www.arduino.cc/en/uploads/Reference/ICSPHeader.jpg

While uploading I get this error message

avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

/usr/bin/run-avrdude: line 5: can't open /tmp/efuse: no such file
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

After removing the shield I can upload sketches without any problems.

I can also use the same shield with an Uno and uploading sketches with this attached shield. So it must be a Yun specific problem.

I have not seen any advice to taking off shields while programming the Yun so I ask myselfe (or you ;-) is this a specific circumstance with my RFMxx module or a general problem I can handle with a workaround. Would be nice to can the Yun re-programm without any manual access only over Wifi and without pluging and un-plugging shields.

When uploading a sketch to an Uno, you are uploading code over the USB connection, using the internal bootloader code. Same thing when uploading a sketch to a Yun using USB.

But when uploading to a Yun over the network, you are uploading the sketch using the ICSP connection (the Linux processor acts like a programming pod.) So it sounds like you have a hardware port conflict.

How exactly do you have things connected to the ICSP header? What are you using as a chip select line? Does your MISO line driver go into a tri-state condition when not selected? It sounds like you might be taking some liberties and always driving MISO thinking your device is the only one on the bus -- this is not true.

Thanks for your explanation. I’m using D9 as RFMxx SPI CS: MISO is directly connected to SD0 of the RFMxx module.

ShapeShifter:
Does your MISO line driver go into a tri-state condition when not selected? It sounds like you might be taking some liberties and always driving MISO thinking your device is the only one on the bus – this is not true.

Don’t know “tri-state condition when not selected”, is this a hardware thing? Have to check the datasheet to the RFM69 CW http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf

Look at page 44 of the datasheet, it has a crucial line on it:

A transfer always starts by the NSS pin going low. MISO is high impedance when NSS is high.

A tri-state condition means that the signal is not driving the signal high or low, it is in a third state that has a high impedance so as to allow other circuits to drive the line. It looks like the chip properly goes into a high impedance state when the chip select signal (D9 in your case) is not active. So, as long as D9 is high when you are trying to load code, it should work.

While loading code, all of the Arduino processor pins should automatically be tri-stated, so everything is floating. Perhaps the radio module is not detecting this properly. Adding a pull-up resistor (something in the 10k range?) may help the module realize that the SPI interface is not active, thereby putting MISO in the tri-state condition so it doesn't affect the SPI bus. Without a pullup, the radio module might think the floating chip select input is low, thereby causing it to drive the MISO output, and thereby conflicting with the code loader's use of the signal?

Ahh, thanks! Because the RFMxx module operates on 3.3v and the Yun is 5V I added a voltage divider with 4K7 to the CS pin and 10K to ground. Could this cause problems and I have to tweak this.

That is absolutely the problem. While the Arduino processor is being loaded, D9 is floating, taking the 4.7 k resistor out of the picture. What you're left with is the 10k resistor to ground, which acting like a pull-down, keeping the chip selected and the MISO output active. That active output is conflicting with the Linux processor's programming output, as both are trying to drive the line at the same time. In such a scenario, neither side wins.

You will need a more sophisticated level shifter, one that allows the module's side of the signal to be pulled high when the Arduino output is floating. Perhaps adding an NPN transistor? Make the 10k a pull-up going to your module and the transistor collector. Use the 4.7k between D9 and the transistor base. Ground the transistor emitter. When D9 is active, the transistor conducts and pulls the module CS low, otherwise the transistor is off and the resistor pulls it high. You will need to invert the HIGH/LOW state of your D9 output in your code.

Many thanks for the advice, I have some prototypes layouted and printed already, so I will add it to my todos for the next review. Interesting what "simple" things can cause in the end.

Yes, it often takes several board revisions to get to a final "product" and it always seems to be the simple things that cause the most trouble. >:(