External PIN remaining high

Hello,

I'm working on a project that uses the RA6M5 MCU. The FSP version is 3.5.0.

The MCU behaves as a host that commuicates with a 3rd party chip over SPI. There is an external PIN which is used by the 3rd party chip as a notification mechanism. When there is some data for the host, the 3rd party chip will turn this external PIN high. When it's high, the host should read the data. The host can only send the data when it's low.

We found a problem about this external PIN. At some point during the communication between the host MCU and the 3rd party chip, this external PIN is turned to high and remaining high for long time such as 500ms. Based on the protocol, there is data for the host when this external PIN is high. However, the PIN is suddenly turned to low when the host tries to read the data - the reading packet wasn't even fully sent over the SPI. As we know, this PIN isn't controlled by the host. Instead, it's controlled by the 3rd party chip. I'm wondering if it's possible that there is something wrong in the host MCU side so that the external PIN is turned to high and remaining high by the host MCU. Another possibility is, is it possible that the PIN can't be turned to low by the 3rd party chip because the host MCU is too busy? I supposed "turned the PIN low" shouldn't need a lot of system resources because it happens in the hardware layer, is that right?

Here is the configuration of the external PIN:

const external_irq_cfg_t g_external_irq14_cfg =
{
  .channel       = 14,
  .trigger       = EXTERNAL_IRQ_TRIG_RISING,
  .filter_enable = true,
  .pclk_div      = EXTERNAL_IRQ_PCLK_DIV_BY_64,
  .p_callback    = gpio_IRQ14_host_wakeup_isr,
  .p_context     = NULL,
  .p_extend      = NULL,
  .ipl           = (10),
  .irq           = VECTOR_NUMBER_ICU_IRQ14,
};

void gpio_IRQ14_host_wakeup_isr(external_irq_callback_args_t *p_args)
{
  // Call the ISR function
  ... 
}

The 3rd party chip company said they couldn't reproduce the case. Meaning, they didn't turn it to high when there is no data for the host. I'm trying to figure out if this problem is caused on the host MCU side. One thing that 3rd party company mentioned is that the SPI clock "seems not sync with the MOSI" which could cause the external PIN isn't turned to low because the SPI communication is messed up. Here is a screen shot of the SPI capture. It looks like the MOSI is not sync with the clock. I believe the clock is provided by the Renesas SPI driver. My question is, is this clock/MOSI sync a problem? If it's a problem, is there a way for us to fix it?

Here is the SPI driver configuration:

const spi_extended_cfg_t g_spi1_extend =
{
    .spi_clksyn   = SPI_SSL_MODE_SPI,
    .spi_comm     = SPI_COMMUNICATION_FULL_DUPLEX,
    .ssl_polarity = SPI_SSLP_LOW,                 
    .ssl_select   = SPI_SSL_SELECT_SSL0,          
    .mosi_idle    = SPI_MOSI_IDLE_VALUE_FIXING_DISABLE,
    .parity       = SPI_PARITY_MODE_DISABLE,        
    .byte_swap    = SPI_BYTE_SWAP_DISABLE,          
    .spck_div     = {
        /* Actual calculated bitrate: 50000000. */
        .spbr = 0,
        .brdv = 0
    },
    .spck_delay         = SPI_DELAY_COUNT_1,        
    .ssl_negation_delay = SPI_DELAY_COUNT_1,        
    .next_access_delay  = SPI_DELAY_COUNT_1         
 };

const spi_cfg_t g_spi1_cfg =
{
    .channel = 1,                         
    .rxi_irq = VECTOR_NUMBER_SPI1_RXI,    
    .txi_irq = VECTOR_NUMBER_SPI1_TXI,    
    .tei_irq = VECTOR_NUMBER_SPI1_TEI,    
    .eri_irq = VECTOR_NUMBER_SPI1_ERI,    
    .rxi_ipl = (10), 
    .txi_ipl = (10),
    .tei_ipl = (10),
    .eri_ipl = (10),
    .operating_mode = SPI_MODE_MASTER,        
    .clk_phase    = SPI_CLK_PHASE_EDGE_ODD,   
    .clk_polarity = SPI_CLK_POLARITY_HIGH,    
    .mode_fault   = SPI_MODE_FAULT_ERROR_DISABLE,
    .bit_order    = SPI_BIT_ORDER_MSB_FIRST,   
    .p_transfer_tx = NULL,                     
    .p_transfer_rx = NULL,                     
    .p_callback    = r_spi1_callback,          
    .p_context     = NULL,                     
    .p_extend      = (void *)&g_spi1_extend,   
};

Thanks!

Parents
  • Hello pilot,

    Thanks for posting your question online.

    The external pin state cannot be handled from the host mcu, especially when you have configure the pin as external interrupt pin.

    About SPI configuration problem, you probably refer to this behavior below:

    Please try to change MOSI Idle state from MOSI IDLE Value Fixing Disable to MOSI Idle Value Fixing Low and check again your system's behavior.

    Regards,

    AL_Renesas

  • Hi AL,

    Thank you so much! I changed the mosi_idle to SPI_MOSI_IDLE_VALUE_FIXING_LOW. Here is a screen shot of the capture after the changing:

    It looks like it's similar to the SPI_MOSI_IDLE_VALUE_FIXING_DISABLE. I'm using the open source software PulseView. Probably that's the reason the MOSI isn't sync with the clock?

    Are there other problems of the SPI configuration? 

    If the external PIN can't be turned to low by the host MCU. Can we firmly say that issue is caused by the 3rd party chip? Of course, I'm trying fix any SPI issue which is potentially making the 3rd party chip unhappy. Other than the SPI issue, are there any other potential issues that I should look into our MCU?

    Thanks.

Reply
  • Hi AL,

    Thank you so much! I changed the mosi_idle to SPI_MOSI_IDLE_VALUE_FIXING_LOW. Here is a screen shot of the capture after the changing:

    It looks like it's similar to the SPI_MOSI_IDLE_VALUE_FIXING_DISABLE. I'm using the open source software PulseView. Probably that's the reason the MOSI isn't sync with the clock?

    Are there other problems of the SPI configuration? 

    If the external PIN can't be turned to low by the host MCU. Can we firmly say that issue is caused by the 3rd party chip? Of course, I'm trying fix any SPI issue which is potentially making the 3rd party chip unhappy. Other than the SPI issue, are there any other potential issues that I should look into our MCU?

    Thanks.

Children