TMS570LC4357: MibSPI and polling

There are currently 2 types of transactions we are implementing and they are the following:

Read transaction where we:

1. Setup the MibSpi device in oneshot mode
2. Enable the transfer group
3. Poll the TGINTFLG register for when the INTFLGRDY[n] bit is set
4. Read out the contents of the RX RAM register
5. Clear the TXINTFLG for the next transaction

Write transaction where we don't care about the SPI response so we:

1. Setup the MibSpi in oneshot mode
2. Enable the transfer group
3. ignore the result.

I have been getting issues where I noticed that I was sometimes returning the previous SPI transaction's result during a read operation and I found out that this was due to the TGINTFLG register doesn't get cleared on the write transactions, so I started clearing it before setting up a read transaction, but sometimes I still get the previous result in a read transaction.

I did some logging of the TGINTFLG register and there were a few surprising findings:

1. reading intvect0 or intvect1 does not clear the TGINTFLG register (offset 0x60, 0x64)
2. intvect0 and 1 are always 0 (maybe because I don't have interrupts enabled?)
3. LGTPEND doesn't show a Tgroup as active before I start the transfer (value is always 0x700)

My question is essentially about polling and the TGINTFLG register.

In order for my code to say that a transfer has finished (I always use the first TG) I have a busy loop that checks the TGINTFLG register

while (currentTime > SPI_TRANSFER_TRANSFER_TIMEOUT_USEC)
{
    if((((spi->hw->TGINTFLG >> 16U)>> auxGroup) & 1U) == 1U)
    {
        break;
    }

    currentTime = HALCpuTickElapsed(startTime, HALCpuTickGet());
    currentTime = HALCpuTickToUsec(currentTime);   
}

But sometimes this exits via the break even though TGINTFLG = 0x0. I added some logging code to save the value of TGINTFLG in a static variable, and when checking with a jtag debugger that static variable is 0x0 so then my SPI RX RAM buffer does not contain 0x8000 as part of the control flags (because it read the RX RAM buffer before the transaction completed)

Any ideas on something that I am missing, or an additional check that I can add to solve this potential issue while polling? (The RTOS we are using has a fairly high overhead for interrupts so we are avoiding them as much as possible)