This case is interesting but some of the symptoms are familiar. Since you are getting the right result sometimes (0x4065), my mind is still on the communication signals. In cases like this, here are the weak points we have found in other implementations, which were contributing to poor (or non existent) communication:
- Incorrect coding
- Incorrect sequence
- Timing error violations:
- Signal integrity issues: ringing, noise spikes, etc
- Physical connection issues
Based on the plots you have offered, it looks like the coding and sequence are correct. While we had some questions on the timing early on, these concerns were addressed through the adjustments you made in the CS timing. In the most recent plot, I did notice that the CS line seemed to stay low for the entire capture time on the logic analyzer. Is the logic analyzer keeping the CS low for all sequences or is it raising up to a high level, in between 16-bit communication segments? That type of scenario typically has less noise immunity than raising the CS line in between 16-bit cycles.
Since there is evidence of noise in your plots, that is where I would tend to focus my efforts. You might also want to make sure there are no opportunities for poor physical connections as well. Since you are getting some toggle on the DOUT line, any issue with the physical connectivity would seem to be intermittent (as opposed to obviously broken).