Unable to transfer data correctly through RSPI using RZ/A2M configured as slave.

Hi, im using RZ A2M processor and trying to send data through RSPI configured as slave. The hardware manual says that the data can be sent at 4.125 Mhz speed. but at 1 Mhz speed itself when i try to send data, in between instead of correct value, zero has been sent in the MISO line. For example, when i try to send 3 bytes of data, the third byte is sent as zero. I have attached the code and screenshot of probed data with this. 

Code :

st_rspi_data_t reg;
int_t error;
uint8_t buf_size[3] = "Bag";
reg.p_send_data = (void *)buf_size;
reg.p_recv_data = NULL;
reg.send_size = 3;
reg.recv_size = 0;


error = control(handle, CTL_RSPI_TRANSFER, &reg);
if(error<0){
printf("Error");
return -1;
}


Probed data:

The yellow line is the clock generated by master at 1 mhz speed.
The blue line is the MISO pin output.

As you can see, the first value is "B" ( 42 hex code) is correctly send. the second value is "a" (61 hex code) is correctly send. But the third byte is sent as 0, but the correct value "g" should have been sent.

for higher frequencies, this invalid data can be seen more frequently, for example, if i try to send 20 bytes of data, there are 2 to 3 invalid data being send. 

Can anyone explain why this is happening? and how to solve this issue?

  • SSL is in active low condition. 

  • So I need additional information to determine if this is a hardware or software issue. 

    Can you confirm the SSL is active low for all bytes?

    If you increase the number of bytes size will the code work? 

    What are the settings for the for the SPI on the channel you are using?

  • Can you confirm the SSL is active low for all bytes?

    yes, the SSL is active low for all the bytes. i have checked it.

    If you increase the number of bytes size will the code work? 

    Yes the code will work. But again the third byte will be zero. And one more thing to mention is that, if i read one more byte after the first 3 bytes read, im able to get the third byte correctly. 

    To summarize, if i send three bytes (['B','a','g']) from slave (renesas) to master. if i read 4 bytes in the master side. That looks like this - > ['B','a','\0','g']. This is for 1 mhz frequency. 

    for higher frequencies, this invalid data can be seen more frequently, for example, if i try to send 20 bytes of data, there are 2 to 3 invalid data being send. 

    If the frequency increases, the number of bytes invalid (zero) also increases, which i have mentioned above. 

    What are the settings for the for the SPI on the channel you are using?

    the following is the configuration im using for spi.

    * @section R_RSPI_SC_TABLE Smart Configurator settings table.
    */
    static const st_r_drv_rspi_sc_config_t RSPI_SC_TABLE[] =
    {
    /* This code is auto-generated. Do not edit manually */
    { 2,
    {
    RSPI_MODE_SLAVE,
    RSPI_BITRATE_4_125MBPS,
    RSPI_CLOCK_PHASE_SAMPLING_EVEN,
    RSPI_CLOCK_POLARITY_1,
    RSPI_DATA_ENDIAN_MSB,
    RSPI_DATA_LEN_8BIT,
    RSPI_MOSI_LEVEL_0,
    RSPI_SSL_POLARITY_0,
    RSPI_SSL_DELAY_RSPCK_1,
    RSPI_SSL_DELAY_NEGATE_1,
    RSPI_SSL_DELAY_NEXT_1,
    false,
    0x11111111,
    5000,
    28,
    28,
    },
    {
    &GPIO_SC_TABLE_rspi2[0],
    sizeof(GPIO_SC_TABLE_rspi2)/sizeof(st_r_drv_gpio_sc_config_t),
    }
    },
    /* End of modification */
    };

  • Can you confirm the SSL is active low for all bytes?

    yes, the SSL is active low for all the bytes. i have checked it.

    If you increase the number of bytes size will the code work? 


    Yes the code will work. But again the third byte will be zero. And one more thing to mention is that, if i read one more byte after the first 3 bytes read, im able to get the third byte correctly. 

    To summarize, if i send three bytes (['B','a','g']) from slave (renesas) to master. if i read 4 bytes in the master side. That looks like this - > ['B','a','\0','g']. This is for 1 mhz frequency. If the frequency increases, the number of bytes invalid (zero) also increases, which i have mentioned above.

    What are the settings for the for the SPI on the channel you are using?

    the following is the configuration im using for spi.

    * @section R_RSPI_SC_TABLE Smart Configurator settings table.
    */
    static const st_r_drv_rspi_sc_config_t RSPI_SC_TABLE[] =
    {
    /* This code is auto-generated. Do not edit manually */
    { 2,
    {
    RSPI_MODE_SLAVE,
    RSPI_BITRATE_4_125MBPS,
    RSPI_CLOCK_PHASE_SAMPLING_EVEN,
    RSPI_CLOCK_POLARITY_1,
    RSPI_DATA_ENDIAN_MSB,
    RSPI_DATA_LEN_8BIT,
    RSPI_MOSI_LEVEL_0,
    RSPI_SSL_POLARITY_0,
    RSPI_SSL_DELAY_RSPCK_1,
    RSPI_SSL_DELAY_NEGATE_1,
    RSPI_SSL_DELAY_NEXT_1,
    false,
    0x11111111,
    5000,
    28,
    28,
    },
    {
    &GPIO_SC_TABLE_rspi2[0],
    sizeof(GPIO_SC_TABLE_rspi2)/sizeof(st_r_drv_gpio_sc_config_t),
    }
    },
    /* End of modification */
    };

  • Hi Ramon,

    Thank you for your response. I have reviewed the settings. They seem to be correct. We are currently looking at the SPI driver. The driver references the transmit and receive data buffer from the application layer any changes to the buffers during transfer is reflected in the output of the SPI. This could happen it the application buffer is defined in the stack then there is a RTOS context switch. 

  • Hi michael,

    Thanks for your reply. I understand that there needs to be changes made in driver side. So can i expect a updated SPI driver? If so can you please let me know when it will be available? 

    Meanwhile, is there anything else we can do from our end in the application layer to avoid this issue? 

  • Could you check that your buffer is declared as a global variable and try testing. 

  • We do not see an issue with the SPI interface. Please follow the suggestions above. If you continue to have this problem please create at support ticket.

  • Hi michael, i tried keeping the buffer as a global variable. But the issue is still the same as i described before. 

  • For us to examine the issue further we will need you to open a support ticket. 

  • sure michael, thanks for your support. i will open a support ticket