Timing delay is random for SPI write - read command
The assumption is that an application which access the SPI port is running on a Linux operating system.  Linux is a real time operating system.  As such, it is not reasonable to expect the application to run uninterrupted.  At any given moment there are likely dozens of applications running on a Linux operating system.  The operating system is using a time slicing technique to allow each application a small amount of processor time.  

The application code, in order to read the data dependably, should wait the minimum delay for the data to become valid.  In this way, if the linux operating system did not preempt the application, the delay should be sufficient.

The author has (later) indicated the use of a 6804 multiple cell pack management chip.  This is a complex, self timed, dual ADC with 6:1 multiplexed inputs capable of monitoring up to 12 batteries.  By no means is this a simple ADC chip.

It is unlikely the SPI interface is to blame for data loss.  Rather, as the 6804 is a complex chip, it is likely this is a 6804 management problem.  Either research the 6804 control registers or control of external 6804 pins.

Since there are many register setting and pins to research it would be impossible to suggest a specific solution.  Rather, here are two idea from reading the 6804 specifications:


Does the 6804 go to sleep? What did you set t-IDLE to?



  The serial ports (SPI or isoSPI) will enter the low power IDLE state
  if there is no activity on Port A for a time of t-IDLE. The WAKEUP
  circuit monitors activity on pins 41 and 42.



Is the software timer being managed properly?



  If software timer activates in the middle of RDCFG command, the
  configuration register group resets as per Table 14. As a result, the
  read back data from bytes CRFG4 and CRFG5 could be corrupted.