Error while trying to place code(CODE SECTION) in L2 in Codec Engine

Please run your application as follows:

# CE_DEBUG=2 ./my_app.x470MV | tee log.txt

Then post your log.txt here.  Under the options menu should be the ability to attach a file.

Brad

Hi Brad,

Thanks for ur reply.

As you suggested , we ran the app with the options u gave  and the log file is attached herewith.

Thanks,

Manoj

Hi Brad,

Can you please tell what could have gone from the log.txt posted in the above reply.

Thanks & Regards,'

Manoj

Can you please post the cfg file from your application too?  There's some kind of memory map inconsistency.  Where are you defining the sections DDR3 and DDR4?

.

Hi,

Here I am attaching a text document which includes the application side .cfg file, server side .tcf and .tci file. I am not able to attach the three attachments differently so i copied all the three into one etxt document.

We have configured our linux memory to 64MB i.e from 0x80000000 to 0x83ffffff and from 0x84000000 the configuration is as shown in .tci fie.

I tried to add some code in application side .cfg file which resulted in the same resuit without any improvement. The options i tried was..

     1) myEngine.armDspLinkConfig.memTable =
                        Engine.getDspMemTableFromServer(
                                                                       "./exe_ser.x64P",
                                                                       "ti.sdo.ce.examples.servers.exe_ser.evm3530" );

    2) config ti.sdo.ce.ipc.IIpc.ArmDspLinkConfig armDspLinkConfig;     // with this i got syntax errors for config

           as spcified in the given path  "/<dvsdk_3_00_00_29 instal DIR>/codec_engine_2_20_01/packages/ti/sdo/ce/ipc/settings.xdc" application is taking the default armdsplinkconfig. That default config what was there was for davinci and compared to our OMAP it is diffferent as it is 128MB.  I tried to change that and failed to do so. Please let me know how to change it  so that it configures for our  codec.

              We are trying to send a code section  to  a particular section  and that section is assigned to IRAM.  In the map file it is showing that  it is in  IRAM but when i run it on board i am getting that error mentioned before.

                                                             #pragma CODE_SECTION(exe_code,"Code_l2")

                                                 and the Code_l2 is assigned to IRAM in link.cmd  as     " code_l2       : > IRAM"

When i use the same code_section for .text it is working fine but i cant put all my .text to IRAM as it is largeer than IRAM size.

When i use the data_section for IRAM it is working fine..

I am not able to find out what the problem  is?    Please help us solve this..

Thanks and Regards,

Manoj 

Hi Brad,

Please let me know if i need to attach the files seperately.

Thanks & Regards,

Manoj

Manoj,

I believe the root cause of your issue is the fact that your DDR3 and DDR4 sections show up with attribute "shared=0" in the log you sent.  That memory map gets created during the createFromServer phase of the build.  I haven't had a chance to verify, but I think that you may be able to fix the issue simply by changing the memory type to "code" instead of "code/data" for those sections.  So make that change in your tcf, rebuild your server, and then rebuild your app.  Note that it must be in exactly that order since the app will do a createFromServer which will look at the server output.

Brad

I just looked at this more closely and I don't think the fix I proposed above is going to work.  When you're building the server you should be getting a big warning message about having unrecognized section names and advising you not to use them.  This problem is why...  It looks like you've created these separate sections just for the sake of having non-cached memory.

First, I recommend you get rid of those additional sections and lump them all together under "DDR2".  That is, make the entire DDR2 section cacheable and apply some user-initiated cache operations to maintain coherence.  It may seem a little scary, but is actually pretty easy (we can help!).  This would be the best way to do it as you will get MUCH better performance.  Operating on uncached external memory will result in horrible performance (several orders of magnitude worse).

Brad

Hi Brad,

I am bit confused with ur explanation.The problem comes when i try to put the code section in IRAM.(internal) .How the attributes of DDR3 and 4 will affect placement of code into IRAM.But of course am able to place data in IRAM.

If you see the tcf file attached , i've declared 64KB of IRAM as Cache and the rest 32 KB as IRAM .I've made sure whatever code (functions) am trying to place in IRAM fits well within 32KB.

As you said ,in the tcf file  there are sections to say code/data for DDR memory but not for IRAM .Is this the issue.

Can you please re look into the log file and confirm if this is the issue.

Thanks for your support.

Regards,

Manoj

Just to add , the reason for making some part of DDR3 as non-cachable was because we are doing DMA on some buffers extensively and if i make those cachable ,then i had to do make sure the cache coherence is taken care off.

What we observed was initiating cache coherence thorugh invalidate and writeback was taking more cycles compared to making them non-cachable.This observation made us to go with non-cachable sections.

This was of course working fine , till the time i put some part of my code to L2 !!!!

The surprsing thing was,this was well tested on CCS on the same EVM and was working fine and consistent for many streams.Only in CE framework it is giving the issue.

Thanks,

Manoj 

Sorry, you're right I misunderstood your question.  Some how I got it in my head that the idea was FIXED when you put the code in L2.  Upon re-reading your initial post I see it's exactly the opposite!

Can you post the output of the linker when this happens?  Are you getting any warnings?

Hi Brad,

I tried the same #pragma CODE_SECTION (setting to IRAM) with video_copy example available in codec engine examples. I got the same results as mentioned with our decoder. Video_copy example works fine without setting the particular function in IRAM memory using #pragma CODE_SECTION.

I made the following changes to the video_copy example ,

1.I defined #pragma CODE_SECTION(VIDDECCOPY_TI_process,"Code_l2") before the VIDDECCOPY_TI_process function definition.
2.I  assigned Code_l2 to IRAM in the link.cmd file in servers ( Code_l2 : > IRAM ). I am attaching the link.cmd file also.
3.I  changed the makefile such that it links the link.cmd while compiling servers. I am attaching a copy of makefile also.

I am able to see the memory allocated for that praticular function in IRAM memory section in the generated map file. While running the code i am getting the following error.

Error: DSP-side memory map does not match configuration.
Compare DSP-side TCF/MAP file with /dsplink/config/all/CFG_<PLATFORM>.c

I am also attaching the log.txt file generated by using CE_DEBUG.
I am using all.tcf and all_evm3530.tci for building the servers. Both .cfg files in application and servers remains the same as in video_copy example.

Can you please have a look at the attached zip file which contains the log,cmd and makefile and comment on what i could have missed out.

Thanks & Regards,

Manoj

Brad,

It is quite obviuos that the default setting for IRAM is data and that is the reason for being not able to place code but data.

But where to change the attributes for IRAM is not clear.

Thanks,

Manoj

Hi Manoj,

Sorry for the slow reply, but I think I've gotten to the bottom of the issue.  This is actually a bug that is present in the version of Codec Engine that you are using.  If you upgrade to CE 2.21 (and dsplink 1.60) the bug is fixed.

Codec Engine 2.21 Release Notes said:

The following defects were resolved:

[snip]

SDOCM00049745 CreateFromServer no longer automatically map internal memory segments

So the issue was when doing createFromServer your internal memory section was being thrown away rather than put into the structure that gets passed to dsplink.  So from the perspective of dsplink that memory range did not exist on the dsp.  That's why it was giving you an error message about the dsp memory map being different than that specified by the arm.  The out file you were loading specified addresses in internal memory that are not part of the memory map data structure on the ARM.

Sorry it took so long to figure out the issue, though I think we've got it now!

Brad