SPI success by specifying mode of unrelated pins

I have a mega2560 controlling four actuators. Comms is through a 'mega compatible' 5100 shield with the SD card (which I am not using). Actuator drive is through PWM H-Bridges. Actuator positions are read through four SPI quadrature encoders. Actuator position is retained when powered off by battery backed 23LCV512 SRAM. It works fine (after much buggeration).

On the SPI bus I have the four encoders, the Ethernet device, the SD card device(unused) and the battery-backed RAM.

The RAM was an afterthought (the original plan was an SD card, but I figured the reliabilty of literally hundreds of instances in the overall installation would not be ideal). The RAM's not complicated but in this application it proved to be a pig. It works fine now but....

Step one, read the RAMs default setup from the mode register. Should be 0x40 but was zero (software and 'scope). The select pin for this device is 42 (triggering on pin42 going low to see the SPI MISO on the 'scope). To cut a long story short I have to have pins 22->28 all set to OUTPUT for this to work (obvs the other devices select pins are set high (including the SD card))

Pins 22->31 are connected to a x10 DIP switch for part of the devices' MAC addresses so after setting them to OUTPUT for a successful RAM initialisation I set them to INPUT_PULLUP so that the MAC address can be read. After it is read I then have to set then back to OUTPUT so that the RAM can continue to operate. Which it does. The whole lot can be powered down and back up and it all works, every time.

Question is. Why? None of the pins from 22->28 are performing any other function and it is clear that there is no electrical connection to these pins other than the intended DIP switch. Also, as far as I can tell all the other SPI devices work correctly under any circumstances.

There is also an Ethernet bootloader which I modified from arduino-netboot to support DHCP rather than just BOOTP. This seems to work just fine.

I can't think of any mechanism that might cause this. However succesful this method is I'm not happy not knowing why it works. Any suggestions?


This continues to be a pain in the arse. The previous description held true for many reboots until the RAM finally wouldn't respond at all and its output remained in the high-impedance state. I powered everything off and disconnected the battery from the RAM. I left the battery disconnected and switched it back on again at which point it started working again. I removed all the pinMode statements and just let it boot in the raw state, set up the necessary outputs only, recompiled, rebooted and it still worked. I reconnected the battery, stored some stuff in the RAM. Switched off and rebooted and it still worked.

I think I'm on my own with this one. I've got some more work to do segregating supplies and getting some prototype PCBs integrated. If I ever reach a conclusion I'll revisit this. Sorry to have bothered you.