Coprocessor management troubleshooting grid

Revision as of 15:18, 13 September 2019 by Registered User

Some typical issues related to the management of a coprocessor are listed below. Solutions or debugging methods are proposed for these issues.

If your issue is not listed, try looking at in the articles in the Coprocessor management Linux, Coprocessor management STM32Cube or troubleshooting grids categories.

1. Coprocessor firmware loading and control[edit source]

Symptom Resolution
 cat  /sys/kernel/debug/remoteproc/remoteproc0/trace0
No such file or directory

The trace is available only if declared in the coprocessor firmware resource table. Another root cause is that the ".resource_table" section is not defined in the elf file. to check

  readelf -S <elf file>

2. Inter processor communication[edit source]

Symptom Resolution

Deadlock in OpenAMP during IP communication withe the main processor.

rpmsg_virtio_rx_callback and rpmsg_virtio_send_offchannel_raw (rpmsg_virtio.c) are using the lock in rpmsg_device struct when they access to the index of the virtio queue index. Theses functions have to not be used in interrupt context, to avoid a double mutex lock between the normal and interrupt contexts.

Linux kernel trace:

stm32-ipcc 4c001000.mailbox: Try increasing MBOX_TX_QUEUE_LEN

This message occurs when the Linux generates an overflow on the IPCC mailbox, which is used to inform the co-processor that a new RPMsg is available. This should not affect the transfer as RPMsg are not discarded but should be interpreted as the coprocessor reachs its capacity to treat the received messages in time.

Linux kernel trace:

timeout waiting for a tx buffer

This message means that there is no more TX buffer available to transmit a message to the remote processor.

  • If no message has been treated by the coprocessor, check that the IPCC interrupt occurs on coprocessor (refer to IPCC_internal_peripheral for detail on the peripheral).
  • If some messages have already been treated by the coprocessor, this probably means that the coprocessor firmware is busy, freeze, or crashed.

Linux kernel trace:

No memory for tty_prepare_flip_string

This message means that there is no more space in the TTY temporary buffer on reception. The root cause is probably that the Linux application does not read the tty device in time to treat the incoming TTY stream.

Linux kernel trace:

remoteproc remoteproc0: stm32_rproc_kick: failed (<mbx>, <error value>)

An error occurs when the rproc driver tries to kick the coprocessor via the IPCC mailbox. The root cause can be:

  • The IPCC mailbox driver is not activated in the kernel configuration ( use make menuconfig command to edit the configuration)
  • The "mboxes" and/or "mbox-names" are not correctly defined in the Linux Kernel device tree( refer to stm32_rproc Device_tree_configuration for exemple)