DRA726: MessageQ Error

SDK version ? Have you changed any software ? Please provide patches and/or application code.

Regards

Vineet

Vineet,

My yocto is based on the yocto used in SDK 3.04 but using Poky. I use arago's recipes that I need.

What software are you talking about? It is a custom board, not a TI EVM.

The test program is based on ex02_messageq example with changes to support CMEM. As I explained in my message, it worked but not the first time.

The goal is that once the communication between the core works and I can use CMEM for my circular buffers, to add support for 3 external CAN from Microchip.

The said CAN do not have the main interrupt connected to the DRA726 so I have the choice to either do polling or enable the different interrupt  lines that are connected to the DRA726

Michel Catudal

ACTIA Corp.

Hi Michel,

It is not expected to see this error from MessageQ. Are you still facing this issue?

This error indicates that the MessageQ module is unable to locate a registered transport. Between Linux and BIOS cores TransportRpmsg is supported. The transport for TransportRpmsg is done as part of IpcMgr_ipcStartup, called as a startup function in the ex02_messageq example.

I noticed in the timestamp that the error comes much later after startup, during MessageQ_put. Is some test triggered during this time? Is that the first time MessageQ_put is called? Do you see error with un-modified ex02_messageq, or only with the updated one?

Thanks,

Angela

Angela,

I couldn't use the original one since it conflicts with ipumm with IPU2 and there is no DSP2.

I haven't seen this yet since my last modifications.

I did have a test with something almost like it (with IPU2 and DSP2 removed)

One thing I have noticed is that DSP1 doesn't respond and the code for both DSP1 and IPU1 even when the code of both are almost identical

How do I find out where the problem is for DSP1?

I will get back later on this today or tomorrow and show some log.

I have an emergency right now, kernel support for LCD replacements for our custom boards.

Michel Catudal

ACTIA Corp

Hi Michel,

Thanks for the update.

Yes, please share any logs that you have. The remote core logs as well as the LAD logs and any test app logs will be useful.

As for debugging the DSP1 issue, here is a document that discusses debugging tools and techniques:

Thanks,

Angela

Angela,

Thanks. I plan on moving from user/m4 communication to kernel/m4 communication. Which document would I need to look at for this?

I am writing code for some external CAN from Microchip and would like to have a linux kernel module that would get the information from the Cortex M4

Michel Catudal

ACTIA Corp

Hi Michel,

The method generally recommended for IPC is for User-space to remote core communication via IPC3.x (MessageQ API). For an example of usage in kernel-space, you can check the information here https://processors.wiki.ti.com/index.php/RPMsg_Kernel_Client_Application to see if it helps.

But regarding the original issue, can you please provide summary of what issue you are still facing? And any associated logs? 

Thanks,

Angela