AM5728: DSP space size issue

attach the 2nd file:

Hello Tony,

We will take a look and get back to you soon.

Regards,

Nick

Hello Tony,

Is this the same issue that you are posting about? https://e2e.ti.com/support/processors/f/791/t/855530

If so, the other post mentioned that there was code that worked. Could you post the working project so we could do a diff and see what changed between "working" and "not working"?

I do not see any obvious issues in the memory map, but I also do not have any VPDMA experience. Pulling in additional people to look at your question on this end.

Regards,

Nick

Hello Nick,

I am the customer.

The code that worked, means the memory is set to 7M, not expand to 8M.

After expand to 8M, It goes not work.

Hello Nick,

I've tried some different way to edit the project. There are summary below:

1.Using GRG modified vps lib, or using Ti vps lib, both fail.

2.Using CCS project to compile, or using makefile to compile, both fail.

3.Using XDC tools, IPC, BIOS, compiler from SDK 3_01_00_06, or using newest component, both fail.

so I think the bug is hiding in the DSP source code.

Hello Civet,

We are trying to figure out if this is potentially related to memory mapping, VPDMA, or something else. An exact diff between your files for "memory is set to 7M" and "memory expanded to 8M" would be helpful in narrowing down which people I need to get this in front of.

Regards,

Nick

In addition to Nick's comments,

Is the VPS program based on one of the examples provided in the SDK? If so, please let us know which one - there may be some caching, memory, etc requirement on the VPS side that is no longer being met after expanding the memory region. If the program is based on an example, we can refer to the memory configuration of that example to see what could potentially be missing.

Regards,
Sahin

Hello Civet,

Could you please set a breakpoint inside vpshal_vpdma.c, as shown below, and tell us the value of vpdmaInfo->baseAddr?

{
volatile int foo = 1;
while (foo);
}

After the DSP is booted up and running, you can connect to the core, load symbols, and view the value in the CCS Expressions/Variables window, as described in the article below.

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#attaching-before-the-issue

It would be good to compare the value of baseAddr between the working and non-working case as well. 

Regards,
Sahin

hello Sahin,

GRG vps is modified based on pdk_am57xx_1_0_4.

I will watch the value of vpdmaInfo->baseAddr tomorrow.

Hello Sahin,

I've modified the DSP project, It can do vps job itself, No need the core A15,Ipu etc...

Then I test the 7M memory, there is log below, vps gets image ok:

After expanded to 8M, there is log below, I added a log about vpdmaInfo->baseAddr, the value is 0x4897D000, but still not work:

This test must use GRG base board. Because the image upload depend on the IC ht82v70.

I attached DSP and vps source here, please help me to review it, thanks a lot.

vps.rar1541.Sort2_Project vps trigger.rar

In addition, I've saved the reg values in file.

VPS reg.rar

Sahin Okur,

vpdmaInfo->baseAddr is 0x4897d000, please help this urgent issue asap. thanks!

BR,
Denny

Hello Sahin,

I loged all the global/static parameter address as below, it shows the address are all equal:

even the data of all the parameter are mostly the same:

I have no more idea about this issue now, please help.

Hello Civet,

Thank you for checking these addresses for us. We've been brainstorming with the IPC developer and VPDMA expert, and suspect the DSP is trampling over the IPU memory space. There are a couple of tests we're going to try on our end to narrow down whether it's due to the memory mapping or an instruction in the DSP code potentially trampling over the IPU memory space.

We should hopefully have a response for you tomorrow, but if not, then early next week (due to the US holiday this week). I appreciate your patience. 

Regards,
Sahin 

Hello Sahin,

My last test is just using Dsp program. Ipu1,Ipu2,Pru,host program is not running. So in my opinion, the problem is related with VPS driver and Linux memory distribution.

Hello,

Could you please check your .map file to verify the VPDMA section is placed in an uncached region? It should look similar to below.

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
L2SRAM 00800000 00048000 00000000 00048000 RW X
OCMC_RAM1 40300000 00080000 00003170 0007ce90 RW X
OCMC_RAM2 40400000 00100000 00000000 00100000 RW X
OCMC_RAM3 40500000 00100000 00000000 00100000 RW X
APP_CODE_MEM 80001000 002ff000 000c1480 0023db80 RWIX
APP_CACHED_DATA_MEM 80300000 01400000 00771f4e 00c8e0b2 RWIX
APP_CACHED_DATA_BLK1_ 81700000 0f400000 0f200000 00200000 RWIX
APP_CACHED_DATA_BLK2_ 90b00000 08000000 00000000 08000000 RWIX
APP_UNCACHED_DATA_BLK a0000000 00200000 0001d4c0 001e2b40 RWIX

SEGMENT ALLOCATION MAP

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
40300000 40300000 00002910 00000000 rw-
40300000 40300000 00002910 00000000 rw- BOARD_IO_DELAY_DATA
40302920 40302920 00000860 00000860 r-x
40302920 40302920 00000860 00000860 r-x BOARD_IO_DELAY_CODE
80001000 80001000 000c1280 000c1280 r-x
80001000 80001000 000c1280 000c1280 r-x .text
800c2400 800c2400 00000200 00000200 r-x
800c2400 800c2400 00000200 00000200 r-x .vecs
80300000 80300000 0068c840 00000000 rw-
80300000 80300000 0068c82c 00000000 rw- .far
8098c830 8098c830 00000010 00000000 rw- .fardata.1
8098c840 8098c840 000a066e 000a066e r--
8098c840 8098c840 000a066e 000a066e r-- .const
80a2ceb0 80a2ceb0 0002e4c4 00000000 rw-
80a2ceb0 80a2ceb0 0002e4c4 00000000 rw- .fardata.2
80a5b380 80a5b380 000090b0 00000000 rw-
80a5b380 80a5b380 00005014 00000000 rw- .bss
80a60398 80a60398 00000098 00000000 rw- .neardata
80a60430 80a60430 00004000 00000000 rw- .stack
80a64430 80a64430 00000c48 00000c48 r--
80a64430 80a64430 00000c48 00000c48 r-- .switch
80a65078 80a65078 00000120 00000000 rw-
80a65078 80a65078 00000120 00000000 rw- .cio
80a65198 80a65198 0000cdc8 0000cdc8 r--
80a65198 80a65198 0000cdc8 0000cdc8 r-- .cinit
a0000000 a0000000 0001d4c0 00000000 rw-
a0000000 a0000000 0001d4c0 00000000 rw- .bss:extMemNonCache:vpdma

Hi Sahin,

Due to there some issue for customer's account, I helped to post customer feedback as below:

"

I have placed the vpdma area to uncached region in .cfg file. But I don't know whether it worked.

/* Disable cache for 0xA0000000 through 0x85900000 area */

Cache.setMarMeta(0x9A000000, 0x01000000, 0 );

I attached .map and .cfg file here.

"

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/0334.Desktop.7z

thanks!

BR,
Denny

Hi Denny,

Thanks for the update. The VPDMA region does indeed appear to reside in an uncached region. 

Is this issue reproducible on a TI EVM using the provided project? I was able to build the application but loading via remoteproc is causing the DSP to crash.

Can you please ask the customer to check this for me:

After loading and running the DSP via Linux remoteproc, connect to the device via CCS but do not run any GEL files (the device has already been initialized by Linux at this point so running a GEL file will be destructive). They will need to remove the GEL files from the Advanced tab in the target configuration as shown below.

Once connected to the DSP core, load only symbols, and check ROV for any errors (Tools > ROV Classic > BIOS > Scan for Errors).

Please let me know what they see.

Regards,
Sahin

Another quick test to try is to disable cache for the entire DSP region to rule out any cache coherency issues. 

/* Disable cache for 0x95000000 through 0xA0000000 area */
Cache.setMarMeta(0x95000000, 0x0B000000, 0 );

Regards,
Sahin

Hello Sahin of TI USA, and (CC. Danny of TI China FAE, Aaron of TI China Sales.)

Sorry to jump in. This is PM Ezen Chen. Customer is talking about sending one set final PCBA with JTAG+Debug cable, due to urgent gating on MP process.

Do you thing current AM5718 IDK is enough for you,  we are willing to provide full set PCBA to TI USA to prevent from any side track.

Best Regards,

Ezen Chen.

Hello Sahin,

I think sending a final PCBA to you will speed up to resolve the problem.

I've tested edit .cfg file Cache.setMarMeta(0x95000000, 0x0B000000, 0 );

But it not work. Maybe it's not relative about cache?

When using ROV Scan for Errors, there is screenshot shows below, message:

Caught exception in view init code: Problem fetching remoteSystemInUseJavaException: java.lang.Exception: Target memory read failed at address: 0xbfc00300, length: 256This read is at an INVALID address according to the application's section map. The application is likely either uninitialized or corrupt.