CCSTUDIO: DSP L1D RAM is change by "Load Program"

Tashiro-San,

CCS would not touch the L1D RAM area. Is customer configuring this area as Cache Or leaving it to power on default? The default is this would be configured as Cache. I am wondering if he is seeing any cached values. 

Can you please provide steps customer is providing and possibly get some screen shots from customer 

Hi Aravind,

Thanks for your quick reply. Please see below feedback from customer.

Aravind Batni said:

Is customer configuring this area as Cache Or leaving it to power on default?

The area is not configured as Cache. The address is 0x00F0C000. Customer thinks this area cannot be configured as Cache.

Aravind Batni said:

Can you please provide steps customer is providing and possibly get some screen shots from customer

Here are steps customer did:
1) Launch CCS v9.3
2) Power-on the board. Code runs from NOR flash here. In this program, L1D RAM is shared between ARM9 and C64x+.
3) In "Target Configuration" Window, perform "Launch Selected Configuration".
4) In "Debug" view, select "C64XP_0" then "Connect Target".
At that time, L1D RAM contents are below:

5) In "Debug" view, select "ARM9_0" then "Connect Target".
When ARM9 is connected, GEL file OnTargetConnect() clears 0x11f0c000 to 0x11f0c003 and 0x11f0c020 to 0x11f0c023.
At that time, L1D RAM contents are below:

6) Select "C64XP_0" then "Load Program".
After program is loaded, L1D RAM contents are below:


Customer did the same steps again, then got below snapshots step#4, #5 and #6.
At step#4 (same as previous snapshot):

At step#5 (same as previous snapshot):


At step#6 (L1D RAM contents are different):


Thanks and regards,
Koichiro Tashiro

Koichiro Tashiro said:

In this program, L1D RAM is shared between ARM9 and C64x+

Interesting! Can customer share the memory map file and details on how are they sharing the memory between ARM9 and C64x+? Is it possible to not allocate any L1D RAM for ARM for this experiment and repeat this steps? Just to make sure none of the ARM9 is not influencing those memory areas.

Also, you can configure the entire L1D area (48KB + 32KB) to be RAM instead of 32KB cache in the above experiment?

Also, it would be a good data point to not do step (5) In "Debug" view, select "ARM9_0" then "Connect Target". and load the DSP executable to see unexpected values show up in L1D RAM area.

Sorry! I don't have a setup to tryout the GEL files.

Thanks

Hi Tashiro-San,

Any inputs/updates on this? Just following up. I will sample the thread after few days and close it, if there are no further activity assuming that this is no longer an issue and resolution has been identified.

Thanks

Hi Aravind,

Sorry for the delay. I am asking customer to check what you mentioned.
Please wait for a while.

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-San,

Sure.. I will wait for your inputs.

Thanks

Hi Aravind,

Please find below feedback from customer.

L1D RAM configuration is like this:
0x00f04000 to 0x00f07fff : C64x+ Data
0x00f08000 to 0x00f0bfff : C64x+ stack
0x00f0c000 to 0x00f0ffff : Shared between ARM and C64x+
0x00f10000 to 0x00f17fff : Cache

Customer tried below three additional tests.
a) ARM does not access to L1D RAM at all.
b) In addition to a), step(5) is not performed in the test sequence.
c) In addition to b), all L1D RAM areas are configured as RAM.

Here are screen shots:
At step(4) with a)


At step(5) with a)


At step(6) with a): L1D RAM contents are changed.


At step(4) with b)


At step(6) with b): L1D RAM contents are changed


At step(4) with c)


At step(6) with c): L1D RAM contents are not changed.


So a) and b) showed the same results (L1D RAM is updated).
Only c) showed L1D RAM contents are not updated.


Thanks and regards,
Koichiro Tashiro

Hi Tashiro-San,

By the way, is customer just loading the program or is the program loaded is being run to main()? 

If the program is being run to main(), it seems like some stack values are getting written back to the memory and I see customer has below configuration.

0x00f08000 to 0x00f0bfff : C64x+ stack

0x00f0c000 to 0x00f0ffff : Shared between ARM and C64x+

To prove out this is the root cause of the issue, can customer try out a memory hole in between stack and the shared memory between ARM and DSP?

Like can they have below memory map and test for (b) cases?

0x00f08000 to 0x00f0bfbf : C64x+ stack 

0x00f0bfc0 to 0x00f0bfff: Memory hole 

0x00f0c000 to 0x00f0ffff : Shared between ARM and C64x+

Please let me know details for above.

Thanks

Hi Aravind,

Aravind Batni said:

By the way, is customer just loading the program or is the program loaded is being run to main()?

At customer side, the code automatically runs to main(). He tried to disable auto run feature, but it did not work.
Here are what he tried.
1) Open C64x+ project properties window.
2) Select "Debug" => "Auto Run and Launch Options".
3) Uncheck "On a program load or restart" checkbox.

Anything he should check to disable auto run feature?

Aravind Batni said:

To prove out this is the root cause of the issue, can customer try out a memory hole in between stack and the shared memory between ARM and DSP?

I will let you know the results as soon as I get it from customer.

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-San,

It is strange that customer is seeing the code running to main() after disabling the option? Are you sure that the option is really unchecked? I may need to loop in CCS team experts, if that is the case.

I have tested that feature locally and I am not able to see this issue.

Please let me know.

I will wait for other results from you.

Thanks

Hi Aravind,

Aravind Batni said:

Are you sure that the option is really unchecked? I may need to loop in CCS team experts, if that is the case.

Please see below screen shop. The option is unchecked.

And customer tested below configuration as well.
0x00f08000 to 0x00f0bfbf : C64x+ stack 
But results are the same.
After target C64x target connect:

After load program:

Thanks and regards,
Koichiro Tashiro

Hi Tashiro-San,

Yes, that is the correct location under CCS to disable the program to run to main. 

The reason, I wanted to stop the program running to main is to update the L1D configuration to all RAM configuration before running anything in the code. 

Since customer is facing the issue to stop the program run to main() after the load, you can suggest below updates.

1. have a custom entry function - say customStartup, which is written in assembly, which simply updates the L1D configuration to all RAM

2. after #1, the customStartup would call  the _c_int00 function 

3. During the linking customer would need to add additional link option to have the custom entry for the program like (--entry customStartup)

4. Load this updated code and see if there is a influence on L1D area -- If there is nothing placed there and when it is configured as all RAM, no change should be seen. 

Please note that, customer can do this check by load and run of the DSP code, without any ARM code to make sure DSP is not altering anything in the memory.

Thanks

Tashiro-san,

Koichiro Tashiro said:

Please see below screen shop. The option is unchecked.

Yes it appears you are correctly disabling auto-run to main. I have not heard of any issue where disabling it has no effect. To be safe, can you clear out the 'main' label?