• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 532 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.

PROCESSOR-SDK-AM57X: MessageQ between HLOS threads

Chris Pendleton
Intellectual 410 points
Part Number: PROCESSOR-SDK-AM57X

Hello. I am seeing errors when trying to send TI-IPC MessageQ messages between threads on QNX 7.0. The error shown on the console is: "transportPut: write failed: 9, Bad file descriptor". The same code works fine when exchanging messages with DSP1.

My test setup:

Board: AM572X-EVM / BeagleBoard X-15
Cortex-A15s/HLOS: QNX 7.0, using the TI-RTOS/IPC (Processor SDK v04.02) libraries (processors.wiki.ti.com/.../IPC_Install_Guide_QNX)
DSP1: TI-RTOS/IPC (Processor SDK v04.02)

The IPC Users Guide (processors.wiki.ti.com/.../IPC_Users_Guide) claims:

"IPC can be used to communicate with the following:

Other threads on the same processor
Threads on other processors running SYS/BIOS
Threads on other processors running an HLOS (e.g., Linux, QNX, Android)"

This statement makes me think that a named MessageQ should be accessible from any thread running on any these OSes on any processor on the chip. Again, I am able to send from a QNX thread to a DSP1 MessageQ without problems. This is basically the stock IPC/ex02_messageq example, and it works very well. Could this be specific to the TI's QNX IPC implementation? Am I misunderstanding something?

Thanks,
Chris

  • 0
    TI__Expert 3640 points
    Hi Chris,

    Unfortunately, the IPC3.x implementation for QNX does not currently have MessageQ_put support for local delivery on QNX. I will update the wiki to indicate this.

    Thanks,
    Angela
  • 0 in reply to Angela Stegmaier
    Intellectual 410 points
    Thanks for the reply Angela. There are plenty of potential workarounds, just wanted to make sure I wasn't missing anything. IPC on QNX is a great software package.

    Another quick question since I have have your attention...

    We have been using the shmemallocator resource manager to manage the DDR reserved carveout. There is not much documentation on this API, but I tried to map a different memory (OCM SRAM) to the code by modifying ...

    ipc_3_47_00_00/qnx/src/ipc3x_dev/sharedmemallocator/resmgr/SharedMemoryAllocator.c:

    #define SH_MEM_BLOCK1_START 0xBA300000
    #define SH_MEM_BLOCK1_SIZE 0x5A00000

    #define SH_MEM_BLOCK2_START 0x9DB00000
    #define SH_MEM_BLOCK2_SIZE 0x1000000

    If I change the address start and size for either block and rebuild IPC, everything appears to work as I expect. I was just wondering whether you know of any reason why I should not do this?

    Regards,
    Chris
  • 0 in reply to Chris Pendleton
    TI__Expert 3640 points
    Hi Chris,

    That is the correct way to configure a different memory region for shmemallocator. Sounds like you are already doing what is mentioned here:

    processors.wiki.ti.com/.../IPC_3.x_FAQ

    IPC3.x itself doesn't use shmemallocator for any IPC communication, so changing this address doesn't affect IPC. Also make sure that no other software in your system is using shmemallocator and expecting the memory to be in that area (for example shmemallocator is used by libdce).

    Thanks,
    Angela
  • 0 in reply to Angela Stegmaier
    Intellectual 410 points

    Thanks again Angela. I am not sure that I have read that FAQ, but I am happy that it suggests doing what I did.

    Regards,

    Chris