AM62A7: IPC Notifiy Init

Sopheap Key

Part Number: AM62A7

Tool/software:

Hello TI Dev,

I’m currently developing a project on the AM62A SK board using the remoteproc and IPC (SDK V10.00.xx.xx). I’ve successfully imported and built the example project from the SDK, where the DSP core writes a value to MSRAM, and the Linux side reads this value after boot via /dev/mem. Most of the time, this works as expected.

However, I’m encountering an issue:

• After booting Linux, the DSP core is in the “running” state

• But there is a time when I try to read the MSRAM address from Linux, the value is all zeros (0x0) instead of the expected value set by the DSP.

• This happens randomly every 20–30 reboots (roughly 1–2 occurrences), while the rest of the time, everything works fine.

• Upon debugging, I noticed that the issue seems to occur during or before the IpcNotify_init() call on the DSP side.

• Then, I tried to write a value to MSRAM before the IpcNotify_init() and the value that are written to MSRAM after IpcNotify_init are 0.

My Questions:

Is there any known issue in SDK 10.00.xx.xx regarding IPC Notify initialization race conditions or shared memory sync problems with MSRAM?.

Regards,

Key

2 months ago

0 Nick Saulnier 2 months ago

TI__Guru** 101700 points

Hello Key,

Just to check, what is the address of the MSRAM that you are using?

Regards,

Nick

0 Sopheap Key 2 months ago in reply to Nick Saulnier

Prodigy 210 points

Hello Nick,

MSRAM address I am using is 0x43C40000.

I have spent some times to look into IpcNotify Init function. Inside IpcNotify Init, there is HwiP_construct function that causes an issue. I have attached the capture from IpcNotify init function below.

Regards,

Key

0 Sopheap Key 2 months ago in reply to Sopheap Key

Prodigy 210 points

Hello Nick,

Could you please provide any update regarding this issue?

Regards,
Key

0 Nick Saulnier 2 months ago in reply to Sopheap Key

TI__Guru** 101700 points

Hello Sopheap,

There are a lot of different memories called "SRAM" in this device

At this point, I am not sure what the 64kB of memory at 0x43c4_0000 is intended for (e.g., if another part of the processor might be modifying data in this memory region). We are still looking into this question.

But the general-purpose on-chip SRAM (OC_SRAM) is located at 0x7000_0000. There is a bug in the current AM62Ax TRM where it is not listed in the memory map, but it will be added in the next TRM version coming out sometime in the coming month.

You can refer to the AM62Ax Multicore academy for more details about SRAM allocation:
https://dev.ti.com/tirex/explore/node?node=A__AYrsKbr1tG2YndAqFy7LLg__AM62A-ACADEMY__WeZ9SsL__LATEST

Note that in that page, the 512kB MSRAM region that I mention is the MCU domain MSRAM, not the OC_SRAM at 0x7000_0000. I'll add a note to clarify that in a future Academy release.

Next steps - I would try the 0x7000_0000 region

We are still looking into the 0x43c4_0000 region. It may take a few more business days - feel free to ping the thread if we do not have another response for you by the middle of next week. If you want to make progress before we respond, you could test the region at 0x7000_0000 to see if it works for you.

Regards,

Nick

0 Sopheap Key 2 months ago in reply to Nick Saulnier

Prodigy 210 points

Hello Nick,

As you mentioned regarding the OC_SRAM region which is located at 0x7000_0000, I see 2 physical address of MSRAM_64KB listed in reference manual as shown below. Currently, I am using 0x43c4_0000 to write data on DSP and read data on Linux side. As I try to read the value at both address (0x43c4_0000 and 0x7000_0000), it returns the exact same value when ipc works and both returns 0 when ipc is stucked or hang inside ipcnotify init right before HwiP_construct.

Are there any differences between these 2 address region?

Regards,
Key

0 Nick Saulnier 2 months ago in reply to Sopheap Key

TI__Guru** 101700 points

Hello Key,

0x43c4_0000 and 0x7000_0000 point to the same OC_SRAM region

It looks like we both decided to run the same tests today. Yes, I can confirm that both of these addresses are pointing to the same memory region. So one of them is the "real" address, and the other one is an "alias". It does not matter which address you use, accesses should be the same from either address.

root@am62axx-evm:/opt/edgeai-gst-apps# devmem2 0x70000100
/dev/mem opened.
Memory mapped at address 0xffffad2e5000.
Read at address  0x70000100 (0xffffad2e5100): 0x00000000
root@am62axx-evm:/opt/edgeai-gst-apps# devmem2 0x43c40100
/dev/mem opened.
Memory mapped at address 0xffffae97a000.
Read at address  0x43C40100 (0xffffae97a100): 0x00000000
root@am62axx-evm:/opt/edgeai-gst-apps# devmem2 0x43c40100 w 0xFACEBEEF
/dev/mem opened.
Memory mapped at address 0xffff9d051000.
Read at address  0x43C40100 (0xffff9d051100): 0x00000000
Write at address 0x43C40100 (0xffff9d051100): 0xFACEBEEF, readback 0xFACEBEEF
root@am62axx-evm:/opt/edgeai-gst-apps# devmem2 0x43c40100
/dev/mem opened.
Memory mapped at address 0xffff8fbc2000.
Read at address  0x43C40100 (0xffff8fbc2100): 0xFACEBEEF
root@am62axx-evm:/opt/edgeai-gst-apps# devmem2 0x70000100
/dev/mem opened.
Memory mapped at address 0xffffbabcc000.
Read at address  0x70000100 (0xffffbabcc100): 0xFACEBEEF

Avoid memory allocation conflicts

This is probably not the issue you are running into, but if you do not properly allocate memory regions, different software can write to the same memory regions, leading to data corruption. AM64x users are more likely to run into this with OC_SRAM, since the SRAM is used by PRU Ethernet.

On AM62Ax, it does not look like any Linux drivers or applications are grabbing OC_SRAM by default. You can see it getting defined, but not actually used:

/arch/arm64/boot/dts/ti$ grep -r --include=k3-am62a* oc_sram
k3-am62a-main.dtsi:     oc_sram: sram@70000000 {
k3-am62a-main.dtsi:             sram = <&oc_sram>;

in k3-am62a-main.dtsi:
&cbass_main {
        oc_sram: sram@70000000 {
                compatible = "mmio-sram";
                reg = <0x00 0x70000000 0x00 0x10000>;
                #address-cells = <1>;
                #size-cells = <1>;
                ranges = <0x0 0x00 0x70000000 0x10000>;
        };

Passing your thread back to another team member

I am passing your thread back to a team member for the next debug steps.

Regards,

Nick

Processors

Processors forum

AM62A7: IPC Notifiy Init