machine/spi_sdcard.cpp: fix write data leaking into cmd buffer

[holub]

somehow related to MT08855 - but it's unclear how "wrong" spi commands can kill entire emu memory.

[cuavas]

This really looks like a “fix the symptom rather than the cause” change. Is the software using CMD16 to set a block size that’s too large for your fixed-size buffer m_data? Is something corrupting m_write_ptr?

Have you tried logging m_write_ptr after each state change to ensure it isn’t getting corrupted?

[holub]

This really looks like a “fix the symptom rather than the cause” change. Is the software using CMD16 to set a block size that’s too large for your fixed-size buffer m_data? Is something corrupting m_write_ptr?

Have you tried logging m_write_ptr after each state change to ensure it isn’t getting corrupted?

The problem is different here: software writes right amount of data and this data is stored. But because this data is simultaneously written to cmd buffer, the tail of data is treated as a command and processed during the next cycle.

[holub]

I insist that's the actual fix.
Similar to the situation we do clean_cmd after each command to clean m_cmd buffer we need to do it here. The only difference is that command happens before we start receiving the m_data. As a result after data is received m_cmd is polluted with the tail of data received and this is treated as a next command which shouldn't be a case.

... I had also tried to assert writes beyond m_data and never catched such

[pmackinlay]

Surely the real hardware knows when it's expecting data (rather than commands), and shouldn't be adding data into the command buffer in the first place? Can you make the command buffer byte latching conditional on the state to avoid having to "clean" it in either case?

[holub]

I did minimal refactoring which can be considered as a better fix