• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 291 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM263P4-Q1: Regarding lack of space in the notification queue for RPMessage_send()

Imaoka Daisaku
Intellectual 430 points

Part Number: AM263P4-Q1
Other Parts Discussed in Thread: SYSCONFIG

When RPMessage_send() is called five times in a row with a timeout of 0 ms, the following warning is output and SystemP_TIMEOUT is returned.
"RPMessage_send:288: [IPC RPMSG] Message send to remote core 3 @ 2 end point failed due to lack of space in Notify Queue!!!"
Please tell me the cause and solution.

Even when called 16 times in a row, this warning is output only the fifth time, and not from the sixth time onwards.
The "RP Message Number of Buffers" setting in sysconfig is 16.

Also, the warning is not output when the timeout is set to 1 ms.
There is sufficient vring, and the following warning is output when the vring queue overflows, so I believe this is a different cause.
"[IPC RPMSG] Message send to remote core %d @ %d end point failed due to lack of space in vring!!!"

  • 0
    TI__Mastermind 26802 points

    Hi,

    Based on the SDK driver, the vring buffer is a shared memory circular buffer, set to a max size of 32 in Software. The max messages that the driver allows to store in the SW FIFO is 4

    When you remove the timeout, the SW does not have enough time to run the ISR and drain the FIFO. When you have a timeout set, there is enough time for software to drain the FIFO and have space to store new messages.

    May i know why the timeout is being set to 0ms?

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 430 points

    Hi Shaunak,

    Assuming that the application will never call `RPMessage_send()` more times than the number of VRING buffers at any given time, we want to minimize the delay caused by `RPMessage_send()`.
    How long, at worst, would it take for space to become available in the SW FIFO so that SystemP_TIMEOUT is not returned and sufficient time is secured to store a new message?

    Regards,

    Imaoka

  • 0 in reply to Imaoka Daisaku
    TI__Mastermind 26802 points

    Hi Imaoka,

    This will need some experimentation, we do not have numbers readily available for this. Let me run some experiments and get back early next week.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    TI__Mastermind 26802 points

    Hi Imaoka-san,

    I did some internal testing with the IPC APIs. Key Findings:

    1. SW FIFO Drain Time: 8-9 μs (measured from first 3 successful iterations)
    - This is the time for IPC Notify ISR to drain one message from the 4-deep SW FIFO
    2. Root Cause of Your Issue:
    - SW FIFO has only 4 message slots (MAILBOX_MAX_MSGS_IN_SW_FIFO)
    - When calling RPMessage_send() 5+ times with timeout=0, the 5th call fails because SW FIFO is full and there's no time for ISR to drain it
    - With timeout=1ms, ISR has time to process messages

    Recommendation:
    Use minimum 20 μs timeout (with some safety margin included) and test.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Intellectual 430 points

    Hi Shaunak,

    This issue has been resolved. Thank you very much for your assistance.
    Regards, Imaoka