Can not run MadUtilities Demo ?

Hello again,

I designed a new app(I will call this app as PlatformLed App) and made it run on both cores 0 and 1 in bypass prelink mode. Here is what I've done:

For getting rid of the hyperterminal connection, I designed a PlatformLed application which just blinks a platform LED in a while loop. The blinking LED changes according to the core which the application runs on (If the application runs on core 0, LED 0 blinks; if the same app runs on core 1, LED 1 blinks).

I statically linked PlatformLed app and moved all segments to L2 memory. I copied resulting out file both at app_1 'built' folder and app_2 'built' folder of demo examples. Then in the bypass prelink deployment  file, I located app 1 to core 1, app2 to core 2. Executed build_loader shell file and phyton script in the bypass prelink mode. Burned resulting bin file to NAND.
And my app both worked on core 1  and core 2 after booting from NAND !!
I can see both LEDs are blinking.

Now, I am back in using DDR case in prelinker mode. With my PlatformLed app, I also tried prelinker mode:

1. I rebuiIt PlatformLed with dynamic and relocatable options are on,
2. I added some segment information to the ddr-data partition in the template deployment configuration file, 
3. I executed build_loader shell file and phyton script in prelinker mode
4. I burned resulting bin file to NAND.
5. It didn't worked !!

In fact I didn't understand this virtual address, physical address concept. And there is no information about this issue other than a couple of sentences in MAD guide. I want both applications' code&data reside in DDR Memory. I don't want to use L2 memory.
What  must be the address parameters in this case ?

regards,
Koray.

PS: I attached the deployment template file that I used. Please find it.

{
	"deviceName" : "C6678",
	
	"partitions" : [
		{
			"name"			: "ddr-code",
			"vaddr"			:  "0x9e000000",
			"paddr"			: [ "0x81e000000", "0x81e000000", "0x81e000000", "0x81e000000","0x81e000000", "0x81e000000", "0x81e000000", "0x81e000000" ],
			"size"			: "0x1000000",
			"secNamePat"  	: ["^.text", "const", "switch"],
			"cores"			: [0,1,2,3,4,5,6,7],
			"permissions"	: ["UR", "UX", "SR", "SX"],  
			"cacheEnable"	: true,
			"prefetch"      : true,
			"priority"		: 0,
			"shared"		: true,
			"loadPartition" : true 
		},
		{
			"name"			: "ddr-data",
			"vaddr"			: "0xD0000000",
			"paddr"			: [ "0x800000000", "0x801000000", "0x802000000", "0x803000000", "0x804000000", "0x805000000", "0x806000000", "0x807000000" ],
			"size"			: "0x1000000",
			"secNamePat"  	: ["stack", "^.far$", "args", "neardata", "fardata", "rodata", "platform_lib", "dynamic" ],
			"cores"			: [0,1,2,3,4,5,6,7],
			"permissions"	: ["UR", "UW", "SR", "SW"],
			"cacheEnable"	: true,
			"prefetch"      : true,
			"priority"		: 0,
			"shared"		: false
		}
	],
	
	"applications" : [
		{
			"name"			 : "app1",
			"fileName"       : "..\\mad-loader\\examples\\app_1\\build\\app_1.exe",
			"libPath"        : ".",
			"allowedCores"   : [0,1,2,3,4,5,6,7]
		},
		{
			"name"			 : "app2",
			"fileName"       : "..\\mad-loader\\examples\\app_2\\build\\app_2.exe",
			"libPath"        : ".",
			"allowedCores"   : [0,1,2,3,4,5,6,7]
		}
	],
	
	"appDeployment" : [
		"app1",
		"app2",
		"",
		"",
		"",
		"",
		"",
		""
	]
}

Hi Koray,

Both another member Boll(his thread:http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/194176.aspx) and I encountered the same problem which seems the signature is not properly allocated even I add bss section into secNamePat of ddr-data partitions. According to the --mem_model:data option of compiler, the signature is positioned into bss or far section respectively, so I can't explain why the section is not placed into ddr-data correctly since all these sections are already declared in deployment.json.

Is there any Bug for that?Maybe TI's expert can give us the suggestion.

Allen

BTW, if you try the prelink-bypass mode, the result should be okay. Because in this mode, the address management is handled by your cmd file not the maptools. A common issue you can check is that whether the data or code space is overlapped between multicores. Even the same code is shared by several cores, the cores should have their own copy of data.

Hello Allen,

Thanks for your response.
I am using same deployment file with the one in MADUtilities guide. Just added "platform_lib" and "dynamic" segment to the "ddr-data" partition. Remaining parameters are same which are:

   "name"   : "ddr-code",
   "vaddr"   :  "0x9e000000",
   "paddr"   : [ "0x81e000000", "0x81e000000", "0x81e000000", "0x81e000000","0x81e000000", "0x81e000000", "0x81e000000", "0x81e000000" ],
   "size"   : "0x1000000",
   "secNamePat"   : ["^.text", "const", "switch"],
   "cores"   : [0,1,2,3,4,5,6,7],
   "permissions" : ["UR", "UX", "SR", "SX"], 
   "cacheEnable" : true,
   "prefetch"      : true,
   "priority"  : 0,
   "shared"  : true,
   "loadPartition" : true
  },
  {
   "name"   : "ddr-data",
   "vaddr"   : "0xD0000000",
   "paddr"   : [ "0x800000000", "0x801000000", "0x802000000", "0x803000000", "0x804000000", "0x805000000", "0x806000000", "0x807000000" ],
   "size"   : "0x1000000",
   "secNamePat"   : ["stack", "^.far$", "args", "neardata", "fardata", "rodata", "dynamic", "platform_lib" ],
   "cores"   : [0,1,2,3,4,5,6,7],
   "permissions" : ["UR", "UW", "SR", "SW"],
   "cacheEnable" : true,
   "prefetch"      : true,
   "priority"  : 0,
   "shared"  : false
  },

I assume there is no overlapping in this configuration.

Do you know how are these virtual addresses (0x9E000000 in ddr-code partition and 0xD0000000 in ddr-data partition) calculated?
Also, why are these physical addresses 36-bit(like 0x81e000000) ? Is it just adding an extra '0' bit to the end ? 
And how they are related with virtual addresses ? I searched for some information in other TI documents but couldn't find anything about this issue.

regards,
Koray.

Hi Koray,

First, I mentioned the overlap of memory is dedicated to the prelink-bypass mode which need the static linker to handle the memory allocation. So you could check the cmd file instead of the deployment configuration.

Then as for the virtual and physical address, first you should be clear that C6678 supports 36-bit physical address because there is a XMC module inside the CorePac which is capable of mapping the 32-bit logic address to 36-bit physical address. In most of TI's DSP series before C667x, there is no such feature, so the virtual and physical address is always the same. You can have a look at the CorePac User Guide for more infomation about XMC and the address remapping. And back to the MADUtilities, the relation of vaddr and paddr is also connected with the help of MPAX function of XMC module, it just the MADloader's responsibility to configure the MPAX register to map the vaddr(0x9e000000) to paddr(0x81e000000).

Could you attach your application of LED blinking here for us to have a check? The best is the whole project including source and cmd file.

Allen

Hi Allen,

I read the XMC chapter of Corepac User Guide and now I have a view of Physical&Virtual Address concept. Thanks for the hint again.

About my application, I have to remind again that I have no problem on bypass-prelink mode. It boots from NAND and works on multicores.

I have problems on prelink mode.
I attached my project, please find it. In the zipped folder, you will find my platformLed app, config json files and the resulting ROMFS image that I built by means of phyton tool. I configured deployment file as running the same application on both of the cores: Core 0 and core 1. As you will see in my project, depending on the running core, LED 0 or LED 1 will blink. Hope it helps .

And I have some questions:

1. I see that in the deployment config file, I may use 'text' segment pattern only once. So I understand that , if I want one of my applications code reside in one partition(let say on DDR memory) and other applications code reside on another partition(let say L2 memory); it is not possible . Am I right ?
2. I want to debug the image that maptool created. In the last part of the MAD Utilities User Guide, it describes a way to do this. But what I want more is to debug step by step in the source code of MAL Loader. Is it possible ? If so, how ? I tried to import some MAL Lib source code, but Program Counter(which I set to 0x9E001040 after loading image to 0x9E000000) never hit on the source code I imported.

regards,
Koray

0285.MadUtilitiesPlatformLed.zip

Are there any TI expert that can help me about this issue ?

Regards,
Koray.

Hello Koray,

Sorry for the delay since there was a vacation in the past days.

I have test your project and find some issues. The platform_init function in your application is dedicated to do some initialization and configurations of  modules such as PLL and DDR3. Commonly these operations are already done in GEL process and it's not safe to make these operations within main() function. The risk is that if you already load sections such as .text into DDR3(actually it's the situation of your MAD example, 0x81e000000 is in DDR3 space), and then you run the platform_init() to reconfig the DDR3, this will lead to code corrupt of text section. So just to skip the config of DDR3 and PLL through the statements before platform_init() is called:

 init_flags.ddr = 0;
 init_flags.pll = 0;

Please have a try and let me know if it works.

Allen

Hi Allen,

I tried your suggestion. I rebuilt the project with the modifications of PLL and DDR initialization process. Loaded resulting bin file to NAND. Booted code from NAND. Normally LED 0 and LED 1 should blink; LED 2 and LED 3 should remain switched on. Here is what happens:
LED 0 is blinking.
LED 1 and LED 2 remained switched on. 
LED 3 has switched off and never switched on again.

It seems core 0 is running, but something wrong with core 1.

• About your suggestion, I need to clarify a point: I realized that PLL and DDR initialization has been done in IBL. That's why I shouldn't do any DDR and PLL initialization in platform_init() procedure. Am I right ?
• I want to debug the Mad Loader code, but I can't. Do you have any idea why I can not do it ? (please have a look at my second question in my post before my previous post)

regards,
koray.

Hi Koray,

From your previous posts, I would assume that you have sunccessfully boot the MAD image from the NAND. I would suggest you do the following to debug this problem:

• Try to load your applications on Core 0 & 1 using CCS to see if they are functioning properly?
• If they are, boot the MAD image, and halt DSP core 0 & 1 to check if the PC register has a valid value.  
• If both cores run fine, try to load symbols on core 0 & 1 to check if you can step through the code and find any problem.

As Allen mentioned before, IBL does initialize the PLL and DDR, normally there is no need for the application to re-initalize the PLL and DDR, especially if the application uses DDR as well.

Regards,

Hao.

Hi Hao,

I also tried the project of Koray's, it works well in NO Boot mode if corrected the platform_init() issue. But runs not as expected through the MAD way.

Could you please review and have a try based on Koray's attached source files?

And there is still some pending issues on MAD which is encountered by several members(http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/194176.aspx) about the example mentioned in MAD user guide. Please have a check and confirm whether there is any bug.

Thanks.

Allen

Hi Hao,

About your questions:

• Try to load your applications on Core 0 & 1 using CCS to see if they are functioning properly?
  Yes. When I load my application on both of the cores at debug mode, it runs properly. I can see both LEDs are blinking.
• If they are, boot the MAD image, and halt DSP core 0 & 1 to check if the PC register has a valid value.
  When I halt the cores both have PC register values such as 0x9E011624 and 0x9E011658. It seems they are in the desired range of address space.

• If both cores run fine, try to load symbols on core 0 & 1 to check if you can step through the code and find any problem.
  I loaded the related symbol file (out file of my app that I used in creating MAD image) after I halt the target cores. But CCS can not find the  source code. This situation is valid for both of the cores. What may be the problem that prevents me stepping through the code ?

By the way, I built the image processing demo of MCSDK in prelinker mode, loaded the resulting image to NAND.  And it worked !!
Now, I am trying to make a relation between image processing demo and my application.

Regards,
koray.

Hi Koray,

 The following links explains how to debug MAD loader using CCS: Since the MAD loader itself is not relocated you can use the MAD loader executables "as is" to load the symbol information in CCS.

http://processors.wiki.ti.com/index.php/MAD_Utils_User_Guide#Debugging_application_on_target

For debugging your application after MAD load, you need to pass the relocation information to the debugger (if you used "prelinker mode"). MAP tool generates a CCS GEL file which provides the relocation information of the application to the CCS debug server. This GEL is created in the "./images" directory.

Best regards

Sandeep

@Hao,

I folIowed your suggestion and  wrote seprerate values to the L2 Memories of cores in my application. Built it, loaded it and run it.
And it worked !!
I verified it by connecting to the cores and controlling the values of L2 memories. Thanks for the hint.

But I still want to find out what the problem was in LED case.
It seems there is a problem in platform library about working on multicores. And I want to know the problem, because most of time I am using platform library in my applications. There are some questions in my mind about this issue:

1. When I load my application to different cores using CCS in debug mode, I see that applications run fine. LEDs are blinking concurrently knowing that each of them is controlled by a different core. So this shows that there is no problem at SPI interface between DSP and FPGA. There must be a different problem other than SPI interface I think. Am I right ?
2. Should I have to confirm that all libraries I use are compatible with multicore processing ? For example, I am thinking on using EDMA, PCIe, MathLib, DSPLib. Do you confirm that all these libraries are compatible with multicore processing ?
   Is this multicore compatibility issue covered in userguides  of libraries or peripherals?

@Sandeep,

I followed your instructions but failed on loading symbols file. Here is what I am doing:

1. I power on my EVM at no-boot mode.
2. Open debug view at CCS, and load EVM configuration file which is 'evmc6678l.gel'.
3. I connect to core  0.
4. I load memory with "c6678-le.bin" file which is created by maptool,  starting from memory address 0x9E000000.
5. I set the value of PC of core 0 to 0x9E001040
6. I try to load a symbol file. Either "c6678-le.bin" or 'mad_load_symbols.gel' is not accepted by CCS. I get the same error : "Could not determine target type of file"
7. However, if I continue and run the project, it runs properly. I verify that cores had run by means of reading cores' own memory locations.

As you see, the project runs fine but what I want to do is going step by step inside MAD loader's code. Is it possible ?

regards,
koray.

Koray,

I am glad to see that your first MAD application works!

In platform\evmc6670l\platform_lib\src\evmc66x_spi.c, the API functions do not have semaphore protection when multiple application threads try to access the SPI bus with the same chip select. This will cause problem if two applications are trying to claim the SPI bus with the same chip select at the same time. This limitation also exists in other drivers (UART/I2C/EMIF16, etc.) of the platform lib.

To workaround this problem:

1. User can add a semaphore logic to the application code that any thread should always do an "atomic" transaction of read/write access at any time.

2.User can also use a "master" core to access the peripherals at any time, other cores can use IPC to communicate with the master core if they want to have the access to the peripherals.

I am not familiar with EDMA, PCIe, MathLib, DSPLib, but generally the low level driver does not support multiple cores, user needs to add above-mentioned methods to support multiple cores.

If you use CCS to run your LED application on a group of cores, and remove/reduce the delay in your code, you should be able to re-produce this problem.

Regards,

Hao.

Hi Hao,

Could you have a try on the examples in mad-loader? This is not related to platform_lib, but the signature always show a incorrect address and can't run normally.

Thanks.

Allen

Sandeep,

Do you have any idea what could cause the signature showing a wrong address?

Thanks,

Hao.

It seems like a bug in CCS debug server to me, as I can see the correct address for other variables (counter , terminate, rodata) in the same ELF segment. I will verify with CCS team and let you know.

Regards

Sandeep

Thanks Sandeep.

The situation you met is absolute the same as mine. Wait for your reply.

Hi Allen,

 It has been confirmed as a defect in CCS. Following is the link to IR.

https://cqweb.ext.ti.com/cqweb/main?test=1&command=GenerateMainFrame&service=CQ&schema=SDO-Web&contextid=SDOWP&username=readonly&password=readonly&entityDefName=IncidentReport&entityID=SDSCM00044532

Best Regards

Sandeep

Hi Sandeep,

Thanks for your confirmation and the defect is still in unresolved status. So it seems we can only wait for the next version of MCSDK or CCS to fix it.

Allen

Hi guys, I got some questions about the MAD example.