[参考译文] AM2434：R5F 和 PRU 之间的 DMA

尊敬的 Marshall：

是、 AM243x 有 2 个相同的 PRU ICSSG 切片 (ICSSG0 和 ICSSG1)。  ICSSG0 共享 RAM 存储器 (64KB) 从 0x30010000 开始、您可以从 TRM 中的“PRU_ICSSG 全局存储器映射“部分了解有关不同 PRU 存储器的更多信息。

R5F 可以直接访问 PRU 共享存储器。 您能否尝试从 R5F 直接读取/写入 PRU 共享 RAM、如果您遇到任何问题、敬请告知。

此致、

Nitika.

Nitika,

我同意 R5F 从 PRU 的 RAM 访问存储器时没有问题（0x3001.0000 - Data 64KB RAM2（共享）、TRM 的第 3289 页）、我已经向自己证明了这一点。 问题是让 DMA 从 R5 执行该操作。 具体指 BCDMA。 这里的用例是、我们有一个 PRU 在这里生成和写入数据、但我们需要 R5 来移动此数据、它可以移动、但直接移动时无法跟上 PRU。 因此、我正在进行这项 DMA 基准测试、以展示我们可以使用 DMA 进行哪种性能改进。

起初、我认为我遇到的问题与链接器脚本或数据对齐有关、但深入探究后、我非常确定它与权限有关。 具体而言、DMA（从 R5 触发时）无法访问 PRU 的 RAM。

有任何关于如何解决此问题的想法？

**更多关于我在测试中看到的内容的详细信息**
同样、我将使用 AM2434  UDMA_SW_TRIGGER 示例工程。 我更新了源缓冲区 gUdmaTestSrcBuf、其中使用了指向 PRU 数据 RAM2 (0x3001.0000) 的指针。 在调试模式下、我通过 App_udmaTriggerInit 函数获取第一次调用 UDMA_eventRegister。

retVal = UDMA_eventRegister (drvHandle、gCh0TrEventHandle、&gCh0TrEventPrms)；
DebugP_ASSERT (UDMA_Sok == RetVal)；

它将–1 返回到 RetVal。 深入研究这个兔子洞、我看到这里出现了问题：

APP_udmaTriggerInit -> UDMA_eventRegister -> UDMA_eventConfig（UDMA_event.c 的第 172 行）-> Sciclient_rmIrqSet （UDMA_event.c 的第 1052 行）

尊敬的 Marshall：

感谢您提供的信息。  

我正在将您的问题转发给我们的 DMA 专家、以便他们对此发表更多意见、请留出一些时间回复您。

此致、

Nitika.