SC16IS741A not accepting MOSI data from host

[greg1]

We have a product design that utilizes the SC16IS741A chip to convert UART data to SPI (the product is a LTE cellular modem, cellular module is UART, hosts are SPI).  We have solid performance when the SPI Master is a Broadcom CPU (aka Raspberry PI or DragonBoard 410C) where we have done the majority of our driver development.  But recently when performing a regression test and using a SAMD21G18A (SAMD21G Arduinos) as the SPI Master we have seen the behavior on the SC16IS741A go from intermittent to hard-failure. 

The symptoms are no MISO response to register reads, we are assuming this is likely caused by MOSI data (in this one case is a read command of either the scratchpad or line-control registers), is somehow not clocked in to the SC16IS741A.  If the read command is not clocked in, clearly the SC16IS741A would not be set to respond on MISO with the register data.

We have checked (and compared to the working Raspberry PI) scope waveforms for

• Signal level differences (both working and failing are at 3.3v high), they are similar with a clean LOW signal
• Noise (there is actually more ringing on the rising edge of the working signal), both are well shaped digital squared edge signals (I can post scope output tomorrow if requested).
• Timing (the working waveform is at the SC16IS741A 4 MHz datasheet maximum).  The failing SAMD tests are at clock rates of 150 KHz to 4 MHz.
• Both automatic decode on a Rigor scope and manual visual decoding of the SPI MOSI\CLK waves display a clean representation of the MOSI data out to the SC16IS741A.
• One observed pattern on the Rasp-PI (Windows 10 IoT Core)... the SPI library returns MOSI to a LOW state between transfer actions.  We have duplicated this "unusual" MOSI behavior on the SAMD only via bit-banging SPI since the SAMD SERCOM facility performs all of the bit timings and port I/Os in SPI.
• Verified that MISO definitely goes from High-Z output to logic HIGH, when CS is brought active LOW.  So it would seem that our host output drive signals are compatible. 
• We have attempted slowing things down, adding delays, and switching to SW SPI to gain bit level control over SPI signals.

Test Pattern

Write Scratchpad register (data 0x55 or 0xAA)

Read Scratchpad register

Alternate Test

Read LCR register following SC16IS741A reset (should return 0x1D)

So we have tried everything we can think of over the last several days and are posting here thinking someone has crossed this issue before.  If anyone has a known solution, an idea, or simply a crazy hunch... please post and let me hear your thoughts.

Thank you in advance for your time and assistance,

Greg 

[greg1]

This has been solved!  In the handoff of the test script code a key element was accidentally omitted; the test script was not deasserting the CS (chip\slave select) line between write and read actions.  When the CS deassert between the two sequential SPI transactions was replaced, the SC16IS741A worked as expected.