TMS570LS1224: MibSPI slave starting with delay

First, there is no need to have a different baud rate for master and slave. The clock is provided from the master to the slave and controls the bit rate. i.e., SPICLK of the master should connect to SPICLK of the slave.

Second, can you confirm that the master is transmitting data to the slave and that the slave is receiving it during the time you are not seeing data sent to the master by the slave? i.e., the slave will only transmit data if it is shifting in data from the master.

Hi Chuck,

thank you for the reply.

Yes, the SPICLK of the master is connected to the SPICLK of the slave that is configured as input. I used Halcogen and I configured the baudrate also for the slave.

I see on the oscilloscope data sent from the master to the slave. The master is receiving all 0xFFFF, because the SOMI and the ENA pin are high for the first 350 ms. In the slave I can't receive notification for the transfer group in this time.

It seems that SPI is not configured in this time and I can't understand why.

Thank you

Arianna

Hello Arianna,

Can you measure the time it takes from boot up until you reach the MibSPI initialization code? Is there some other function or initialization at boot time that is blocking execution of the MibSPI initialization in your slave device? In short, what is the slave device doing during the 350ms that it is delayed?

Hi Chuck,

It's the same question I have...

I tried to set a breakpoint at the end of mibspi configuration, and then to start the master software but the result is the same. What I see is that the slave in these 350 ms is in the while, waiting for a mibspi notification..

5756.testHercules.zipI attach my projects.

In the image you can see the measure from oscilloscope:

- signal 1: CLK

- signal 2: SIMO

- signal 3: SOMI

- signal 4: ENA

Thank you for your time Chuck

Regards

Arianna

Hello Arianna,

Thanks for providing the plots. This gives some good pointers on where to look in your code.

First, I see that you are using the nENA feature. It seems that for the entire time that you are waiting, the nENA is high which indicates that the slave is not ready to receive data. This means that it will not be able to receive anything even if the master is sending it. When you initialize the slave, do you put any data into the Tx buffer so that it is ready to transmit something? i.e., since it is a slave, it must have something ready to transmit before it can be ready to receive and assert the nENA pin to indicate to the master that it is ready.

As a side note, it seems that the master is ignoring the nENA signal and is happily transmitting data to the slave regardless of the state of the nENA pin. Have you connected this pin to the master and is the master configured to make use of the nENA pin? My understanding is that both the clock and MOSI line will be held while the nENA pin is de-asserted (high).

Hi Chuck,

the booster pack I am using does not map the nENA pin, so I am using it just for debugging, that is why the master is ignoring it.

This is my slave main code:

int main(void)
{
/* USER CODE BEGIN (3) */
       uint8_t i;

    /* Enable IRQ Interrupt in Cortex R4 CPU */
    _enable_interrupt_();

    mibspiInit();
    muxInit();

    /* Enable TG 0 complete interrupt to INT 0 */
    mibspiEnableGroupNotification(mibspiREG3,0,0);

    /* Fill the transfer Groups */
    mibspiSetData(mibspiREG3,0,TG0_TX_DATA);

    TG0_IS_Complete = 0x55555555;
    /* Enable TG0 to start */
    mibspiTransfer(mibspiREG3,0);

    while(1)
    {

        /* Wait until this flag is set in TG0 ISR */
        while(TG0_IS_Complete != 0xA5A5A5A5);

        mibspiGetData(mibspiREG3,0,TG0_RX_DATA);

        TG0_IS_Complete = 0x55555555;
       
        mibspiTransfer(mibspiREG3,0);

        for (i = 0; i < 16; i++)
        {
            if (TG0_RX_DATA[i] != (TG0_TX_DATA[i] - 1))
                error++;
        }
    }
/* USER CODE END */

    return 0;
}

I am not sure if I have to set the TICKCNT in some way in the slave.

Is it possible that is a debug issue? The JTAG can take some time for some reason? I am debugging the two projects together, using a target configuration with 2 XDS110.

Thank you

Arianna

Hello Arianna,

I don't believe the issue is related to debug mode unless you are breaking before you reach the point where your slave is initialized and there shouldn't be any need to initialize the tick counter since you are not using it to trigger transfers.

How do you power cycle the boards? i.e., how do you assure that the slave is up and waiting for the master and that the master doesn't come up and send before the slave is ready? This could be done with nENA but only if the master uses it too.

For now, I believe the reason the slave is not receiving data and, therefore, no notification is happening is because the nENA pin is held high for this 350ms period. My initial though was you were not loading data into the TxBuff and getting ready to transmit. It would appear that you are doing this with the MibSPITransfer function to start the transfer group sending data but I don't know why nENA would continue to be help high? Can you try disabling nENA (configure as a GPIO) so that it doesn't impede the slave operation?

Hello Arianna,

I am glad you were able to isolate the issue and are now certain you won't have an issue outside of the debug environment. In regard to if the issue is caused by the reset pin, I can't really determine if this is the case or not since I don't have access to your hardware setup. You could certainly monitor nRST on a scope to see if the slave nRST is released at the same delayed time as when the SPI starts to work. Even if you confirm this to be the case, it would then come down to the debugger holding the slave in reset for an extended period which would have to be understood. This information would have to come from the CCS team as I am not an expert on the inner workings of the CCS IDE.