RM48L950: Forcing SPI shift registers to default state,

Hi Paddu,

Yes, clearing SPIEN will reset the TX and RX shift registers, SPIDATx registers, SPIFLG register and the SPIBUF register. What do you see when "it is not working"?

Regards,
Sunil

Hi Sunil,

Thank you so much for the information.

I am sorry for the incomplete information.
After detailed debug, we found that shift registers are cleared if SPIEN bit is cleared.
But, in our case the MibSPI buffer RAM pointer deviates....is there any way to clear buffer pointer?
Both Send/Receive buffer data are deviated or misaligned compared to the data sent from SPI master.

I will send the detailed scope shot later, meanwhile could you please
let me know if there is any way to clear MibSPI buffer RAM pointer.

Best Regards
paddu

Hi Sunil,

I am sorry for the late reply.

Actually, we are not able to solve this issue yet.
We cannot reset MibSPI module because SPI pins are also used as I/O
and the reset will affect other features, so the only way is to reset the RAM pointer.

Below are the details of the Loop operation from Master and RM48xx-slave,
there seems to be a slight improvement after MSPIENA reset, but still, the data from RM48xx is misaligned.

Normal operation:
SPI master Tx:        0x02, 0x01, 0x04, 0x03,0x06,0x05,0x08
RM48xx Slave Tx:   0x02, 0x01, 0x04, 0x03,0x06,0x05,0x08

After noise in the clock signal:
SPI master Tx:        0x02, 0x01, 0x04, 0x03,0x06,0x05,0x08
RM48xx Slave Tx:   0x08, 0x04, 0x10, 0x0C,0x18,0x14,0x20

Modifications as per your suggestion:

After SPIEN reset:
SPI master Tx:        0x02, 0x01, 0x04, 0x03,0x06,0x05,0x08
RM48xx Slave Tx:   0x00, 0x00, 0x06, 0x05,0x08,0x07,0x02

After MSPIENA reset:
SPI master Tx:        0x02, 0x01, 0x04, 0x03,0x06,0x05,0x08
RM48xx Slave Tx:   0x04, 0x03, 0x06, 0x05,0x08,0x07,0x02

Please let me know if there is any way to reset the RAM pointer.

Best Regards
paddu

Hi Paddu,

Each time you reset the MibSPI module or even the multi-buffered mode, the module performs an auto-initialization of the RAM. The application must wait for this initialization to complete before proceeding to configure the TX buffers. Does your application account for that?

Regards,
Sunil

Hi Sunil,

Thank you for the quick info.
I am sorry for the delay.

Yes, there is sufficient wait time provided for the auto-initialization.
We are using the code generated from the Halcogen as shown below,
but we think this Halcogen code may not be sufficient in this case.

Data Receive function:

uint32 mibspiGetData(mibspiBASE_t *mibspi, uint32 group, uint16 * data)
{
/* USER CODE BEGIN (8) */
/* USER CODE END */

    mibspiRAM_t *ram    = (mibspi == mibspiREG1)  mibspiRAM1 : ((mibspi == mibspiREG3)  mibspiRAM3 : mibspiRAM5);
    uint32 start  = (mibspi->TGCTRL[group] >> 8U) & 0xFFU;
    uint32 end    = (group == 7U)  (((mibspi->LTGPEND & 0x00007F00U) >> 8U) + 1U) : ((mibspi->TGCTRL[group+1U] >> 8U) & 0xFFU);
    uint16 mibspiFlags  = 0U;
uint32 ret;
    if (end == 0U) {end = 128U;}

    while (start < end)
    {
        mibspiFlags  |= ram->rx[start].flags;
        /*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are only allowed in this driver" */
        *data = ram->rx[start].data;
        /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
        data++;
        start++;
    }

ret = ((uint32)mibspiFlags >> 8U) & 0x5FU;
/* USER CODE BEGIN (9) */
/* USER CODE END */

    return ret;
}

Are there any other settings related to MibSPI RAM other than clearing the registers? 

As per the halcogen code it seems the buffer used is in between the start of a TGxCTRL group
to the start of the next group, in this kind of code, if the communication stops in between,
the pointer would become uncertain and this could lead to misalignment in the buffer data.

Can we instead set only the value of PSTARTx of TGxCTRL for the only Group0  inside mibspiInit()
to avoid this issue?

Best Regards
paddu

Hi Sunil,

I am sorry to bother you,
Please let me know if there is any suggestion on the last reply.

Hi Paddu,

Sorry for the delay in the response. In multi-buffered slave mode operation, there is only one transfer group, and that is transfer group 0. This TG0 is triggered by the SPInCS pin. The group's PSTART gets copied to PCURRENT each time the TG0 is triggered (nCS gets asserted by the master), or the end of the TG0 is reached during a transfer, or if a trigger event (nCS being asserted) occurs while (Pointer Reset Mode) PRST = 1.

For your case of disturbance on the clock line, you can try setting PRST=1 in the TG0CTRL register. Although this is not recommended for use in slave mode, it may result in the behavior you desire. For this to work correctly, the master must deassert and then assert the chip select to the slave.

Regards,
Sunil

Hi Sunil,

Thank you for the suggestion,
and I am sorry for the delay in feedback.

We tried with the setting PRST=1 in the TG0CTRL register, but unfortunately we couldn't solve the issue,
actually this application doesn't use chip select(nCS) pin (Chip Select Hold is enabled).
So "PRST=1" may not work properly if we do't use chip select?
And just in case could you please confirm there is no other ways to reset the buffer pointer.

Best Regards
paddu