• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2999 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.

remoteproc2: mbox_send_message failed: -105

Fesseha Mamo
Prodigy 70 points

Hello,

I am using the Beaglebone Black (BBB) to develop a kind of Sniffer from an RS485 bus.

Exactly speaking, I'm trying to use the PRU UART along with a TI RS485 TRX module. In doing so I'm redirecting all data from the PRU UART to the ARM Linux on BBB. I encountered a problem in doing so. After receiving few (~26bytes) data I get the error shown below:

omap-mailbox 480c8000.mailbox: Try increasing MBOX_TX_QUEUE_LEN

remoteproc2: mbox_send_message failed: -105

If this solution works out I'm expecting lots of data from the RS485 bus. Therefore, I need a way to make data continuously flow from the PRU UART to the ARM Linux. It just needs to be a forward and forget system - no storing required. What could be the problem and how do I solve it?


Thanks

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the PRU experts to look at this.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 70 points

    Hello,

    I assume that this message is generated by the pru_rpoc HOST interface. I assume, again, that this happens because the last "kick" from the HOST to the PRU is not sent successfully. After mailbox  queue gets full, i.e. MBOX_TX_QUEUE_LEN = 20, this error message that I reported on the initial question happens.

    So now my question is what is the use of Step 9 in this procedure - http://processors.wiki.ti.com/index.php/PRU-ICSS_Remoteproc_and_RPMsg#PRU_to_ARM ???

    ...
    Step 9: Kick the host Vring by writing its index (0) into a message in Mailbox 2

    Because even though I'm getting this error message the HOST is still able to receive what is being transmitted from the PRU UART side. Look below

    Any suggestions?

    Thanks

  • 0 in reply to Fesseha Mamo
    TI__Genius 10440 points

    The kick from Step 9 in the procedure is a method that the ARM core uses to notify the remote processor (the PRU in our case) that an available buffer has been added back to the vring. This notification can be used by the PRU to confirm that the ARM side has received a message, that a new buffer is available for sending more messages, or it can be ignored.

    Since we are using mailboxes as our kick method in this release, if we completely ignore these messages the mailbox will fill up and we will get console output (exactly like you are seeing). You'll see that in the Echo_Interrupt examples (provided in the pru-software-support-package v4.0.2) that the mailbox is checked in a while loop and if the message contained a kick notifying the PRU of a new available buffer (step 9) that no action is taken. However, the act of reading the message from the mailbox stops the console logs that you are seeing.

    The simplest solution to your issue would be to remove the 'if (msgs_received)' and 'virtqueue_kick(vrp->rvq);' lines from the 'rpmsg_recv_done' function in the 'drivers/rpmsg/virtio_rpmsg_bus.c' file in your kernel source. Then rebuild the module and replace the one on your board with the newly built one.

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 70 points
    Thanks Jason.
    I would also like to know how it is possible to read the notification from the mailbox to free up the queue and silence the error message. Is there any API to do that from the PRU side?
  • 0 in reply to Fesseha Mamo
    TI__Genius 10440 points

    Check out the code in the while(1) loop of this echo example: https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/v4.0.2/examples/am335x/PRU_RPMsg_Echo_Interrupt0/main.c

    The comments should explain most of what's going on but lines 112 and 114 are the ones to focus on. Line 112 performs a while loop until all messages currently in the mailbox are cleared. Line 114 is a check to see which vring has been kicked. In the example, the code only cares about messages arriving from the ARM core on vring 1 (hence the == 1 in the code). Any message arriving in the mailbox with a value of 0 will be read, but no action will be taken on it.

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 70 points
    The example works fine because it's always doing to and fro. It always gets triggered from the ARM side. Where as, I only send from the PRU side and all I want to do is - when the interrupt is triggered on the PRU side to clear this notification of the ARM step 9 kick and continue transmitting.
  • 0 in reply to Fesseha Mamo
    TI__Genius 10440 points

    I understand that.

    Your example will still get triggered by the ARM side because you are receiving the buffer consumed kicks from the ARM. You need to read the messages from the mailbox (int msg = CT_MBX.MESSAGE[MB_FROM_ARM_HOST], like line 114 in the example I showed) or else the mailbox will continue to fill and you'll continue to get the console output.

    You have a few options:

    1. my first suggestion was to stop the ARM core from kicking you after consuming a buffer by commenting those lines out of the kernel source and rebuilding
    2. you can use the code from line 106-114 of the example I linked in order to only clear the mailbox if an interrupt was received
      1. you do not need to check for any equality in line 114, you just need to read the message from the mailbox in order to clear it
    3. you can just use lines 112-114 to poll on the mailbox and clear it when a message arrives
      1. you do not need to check for any equality in line 114, you just need to read the message from the mailbox in order to clear it

    If you select option 2 or 3, the clearing of the mailbox can be something that you do only after you send a message: get serial data to send to arm -> send serial data to the ARM with rpmsg -> poll the mailbox until the completion kick arrives. OR you can have the clearing of the mailbox be something that is done constantly as a sort of 'idle function' between receiving serial data.

    Jason Reeder

  • 0 in reply to Jason Reeder
    Prodigy 70 points
    Thank you Jason.
    This (int msg = CT_MBX.MESSAGE[MB_FROM_ARM_HOST) worked for me. It was not working for me before since I always had this [while(CT_MBX.MSGSTATUS_bit[MB_FROM_ARM_HOST].NBOFMSG > 0)] statment before the clearing of the mailbox and it was never entering the while loop if it is not receiving a message from the ARM.
    Thanks again!