TDA4VE-Q1: Greely_Smart TDA4 SCI Issue

Part Number: TDA4VE-Q1

Tool/software:

Hello TI experts,

We meet some issue happed when The A72 core booting time,when we remove some logs in bootApp which intigrated in autosar OS.The A72 core runs with issues when request the SCI resources ,and we debug the A72 core deeply and we found that 

the A72 core was stucked in here 

Value J7Mailbox_MessagesAvailable(
        J7MailboxDev * Dev,
        Value Channel)
{
    Assert(Dev != NULL);
    Assert(Channel < Dev->ValidQueues);
    
    volatile uint32_t * Status =
        (void *)(Dev->StatusKernAddr + Channel * MBOX_RGN_SIZE);
    
    
    console_printf("J7Mailbox_MessagesAvailable Channel %d address %x status %x *status %x\r\n",Channel,Dev->StatusKernAddr,Status,*Status);

    return ExtractField(*Status, MBOX_DBG_STS_MSG_CNT);
}

after we add some logs(as the logs shows) in the function we found that the reson why a72 core stuck here is that when the sci request was send to R5,

after the R5 reply the request the A72 core will read the 3240b000 which is a PROXY_0_STATUS Register I think,

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000000

J7Mailbox_MessagesAvailable Channel 11 address 32400000 status 3240b000 *status 40000001

to get the cur_cnt value to know that if the R5 have successfully replay the message.

but when the issue time the value of this reg is always 0x40000000.

We want to know where the R5 write the reg and why it can not be changes when R5 replay to A72 core.