Ethernet software bug - SPI access & external interrupts [imported]

[cmaglie]

This is Issue 384 moved from a Google Code project.
Added by 2010-10-21T12:39:08.000Z by akiba.fr...@gmail.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

What steps will reproduce the problem?

1. Use a library that has SPI access inside an ISR.
2. Run the "Webserver" Ethernet example.
3. Trigger the SPI interrupt on second device while webserver is running.

What is the expected output? What do you see instead?

The system hangs. The SPI data gets corrupted because both SPI buses are active at the same time. Since the SPI accesses aren't atomic, if an interrupt occurs before the SPI data register is read, its possible that the data will be changed after the ISR exits. There is also the issue of the Wiznet chip. If the chip is selected, then it does not properly release MISO which will corrupt any other device on the SPI. If an interrupt occurs while the Wiznet chip is being accessed, and there is an SPI access to a different chip, the access to the other chip will be corrupted because of a data collision on MISO.

What version of the Arduino software are you using? On what operating
system? Which Arduino board are you using?

Arduino IDE version 0021. Windows XP. Custom board.

Please provide any additional information below.

An example of a fix would be:

uint8_t W5100Class::read(uint16_t _addr)
{
// DISABLE INTERRUPTS
cli();

setSS();
SPI.transfer(0x0F);
SPI.transfer(_addr >> 8);
SPI.transfer(_addr & 0xFF);
uint8_t _data = SPI.transfer(0);
resetSS();

// ENABLE INTERRUPTS
sei();

return _data;
}

[matthijskooijman]

I've also ran into this issue, using an Arduino Ethernet combined with the RF22 shield. When an RF interrupt is received (causing some SPI reads and writes) during an Ethernet transfer, my Arduino would lock up.

The solution above would work, but is not perfect: If for some reason interrupts were already disabled, calling the read function would cause them to become enabled, with all the mess associated with that. Instead, it would be better to use the ATOMIC_BLOCK macro from util/atomic.h to save and restore the interrupt state.

I'll prepare a patch in a minute.

[cmaglie]

Fixed with SPI Transactions