topic Re: Application note on memory usage in DSC in Digital Signal Controllers

Application note on memory usage in DSC

ankur_kala — Thu, 20 Feb 2014 12:21:36 GMT

Is there any application note or a white paper as to how memory segmentation works in case of DSCs. One of our customers is facing lot of issues of runtime constants updation or wrong updation of variables in memory.

Re: Application note on memory usage in DSC

Ben — Thu, 20 Feb 2014 14:46:58 GMT

Hi Ankur, I did not see any document specific for using the memory, but tell the customer to make sure that if he used the PE for initialization, there is routine which copy constants to RAM while initialization and working from RAM. It works good, do not modify it.

Also, I recommend to use CW 10.5 with the service pack. I faced problem with constants in memory too wile working with old versions. (with 568257)

Re: Application note on memory usage in DSC

sutter_zhou — Fri, 28 Feb 2014 05:48:34 GMT

Hi Ankur. You can refer to AN4329, which shows how to relocate code and data using the codewarrior LCF (linker command file) for CodeFire. Even though this document aims to CodeFire, it also applies to DSC.

Re: Application note on memory usage in DSC

Ben — Fri, 28 Feb 2014 10:04:28 GMT

Xuwei, this AN helped me to locate a memory segments in external memory.

For the internal memory - the PE made a good work for me so far.

The problem with changing the LCF file, as that every time you run the PE, you'll have to re-edit this file again.

If you have a tip for this case, please advise

Re: Application note on memory usage in DSC

ankur_kala — Mon, 03 Mar 2014 06:47:15 GMT

Hi, thanks for your replies. However, for DSCs the cmd file reads like this:

#### RAM - 4KB

.p_flash_ROM_data (RX) : ORIGIN = 0x000400, LENGTH = 0x000400 # internal xRAM data mirror

## Data Memory space

.x_internal_RAM_data (RW) : ORIGIN = 0x000000, LENGTH = 0x000800 # alias of 1000 for program space

How exactly does RAM mirroring work for ROM data section. All const data is placed in the ROM segment. Do I need to copy this data distinctly into RAM at runtime or do I need to keep a RAM segment isolated for the constants.

the customer at his end is trying to simulate a sine wave and has a const array defined for 512 bytes. He also has certain other arrays defined as const. he is using optimization level 2 for confining code in the given flash size.

johnlwinters

Re: Application note on memory usage in DSC

johnlwinters — Mon, 03 Mar 2014 16:49:21 GMT

The project stationery contains routines that prepare the environment for the C language.

This involves setting up the stack, trimming the frequency and perhaps other aspects of the hardware, clearing portions of RAM that have no initial value, and copying portions of RAM that DO have initial values from the ROM image of these varialbes.

The detailed mechanism is contained in the linker command file, and the startup code. The startup code is not located in the same folder as the user code; it is also not located with the generated code. The generated code does contain a program with a name such as CPU.c which will go to the startup code.

The startup code calls the main program after the system is all set up.

You can modify the debugger properties (debug configuration) so that it breaks at the very first instruction executed if you wish to trace this through.

Re: Application note on memory usage in DSC

Ben — Wed, 05 Mar 2014 00:17:16 GMT

Ankur, I think that both me and John focused technical explanation, however, I read again your question, and I think that it is similar to a problem I had in a project with DSC chip.

I assume that you are using CW 10.5, if it is possible, I advise your customer to start a new project and to define again all the chip components, then to add his code.

It worked for me, the 10.5 PE re-build the project and it started to work good. I don't understand what caused it.

It took me a full working day to re-build it, but it was after 2 months of digging the code to repair the problem, without any success from the support team (and I can't blame them, it is not an easy problem to solve in remote mode).

Re: Application note on memory usage in DSC

johnlwinters — Wed, 05 Mar 2014 01:19:09 GMT

All,

Yes, always start with a clean working project and add your code, testing at every step.

I've learned to mostly discard projects that do not work, unless I am converging two sets of projects, working and non-working to the minimum difference.

By creating a new project and adding the components, you are assured of a clean start.

Another trick that sometimes works is to delete the generated code directory, then regenerate the code.

This cleans up and Processor Expert code that may not be consistent with the version of CW you are using.

Re: Application note on memory usage in DSC

ankur_kala — Thu, 06 Mar 2014 05:20:17 GMT

Hi johnlwinters and Ben,

The customer in this case is not using PE to generate the peripheral initialization routines.

Re: Application note on memory usage in DSC

johnlwinters — Thu, 06 Mar 2014 14:43:44 GMT

Hi,

In any case, he is probably relying on the initialization code generated by the stationery even in the case where PEx is not even chosen.

These routines, which work in conjunction with the linker command files, do not normally come to the attention of the programmer, since the stationery is configured to break at main, after the execution of these routines.

Re: Application note on memory usage in DSC

johnlwinters — Thu, 06 Mar 2014 14:44:56 GMT

Hi,

In any case, he is probably relying on the initialization code generated by the stationery even in the case where PEx is not even chosen.

Re: Application note on memory usage in DSC

ankur_kala — Fri, 25 Jul 2014 04:34:56 GMT

Just to close this thread, the issue was finally found in the linker file generated by the tool. The constant section mapped in the RAM from the Flash was defined halfway from the RAM which rather must have pointed to the start of RAM. As a result on runtime, after mapping the constants on the RAM, the runtime variables were overwriting this section (since the section was shared for both). The issue was resolved by mapping the section to the start of the RAM.

Re: Application note on memory usage in DSC

johnlwinters — Fri, 25 Jul 2014 22:24:03 GMT

Hi Ankur,

Thanks for the update; the tool in this case is the CodeWarrior stationery, or the PEx stationery? Have you reported this issue into the appropriate ticket/tracking system, such as CQ or other newer system?

Re: Application note on memory usage in DSC

ankur_kala — Thu, 31 Jul 2014 10:19:50 GMT

Hi John,

Yes the issue was seen in CW, with PE correct linker files were getting generated. This has already been logged with the CW team. Kamil has already raised the ticket.

Re: Application note on memory usage in DSC

sumanbhandari — Fri, 28 Aug 2015 07:38:47 GMT

Hi All,

I am experiencing similar errors on run-time. I am not using PE.

Can anyone share the correct linker file for RAM mapping in MC56F84763??

Attached is the linker file I m currently using.

Re: Application note on memory usage in DSC

sutter_zhou — Mon, 31 Aug 2015 04:26:01 GMT

Hi Suman,

You used CodeWarrior to generate a stationery for 56F84763 but without PE, right? Generally speaking, there'd be no problems using this stationery to develop your project. But based on my experiences, the stationery without PE seems to be not updated everytime CW is updated, but the stationery with PE is updated properly.

So I recommand you to update your CW environment first (Help -> Check for updates), this update is crucial because some bugs are fixed in the start up file. Then you can generate a project with PE, extract the linker file, 56F83x_init.asm and vectors.c to your own project without PE to replace the corresponding files. Of course there're some necessary modifications in vectors.c.

Re: Application note on memory usage in DSC

ankur_kala — Mon, 14 Sep 2015 09:31:35 GMT

Hi Suman,

Is your problem fixed.

Regards,

Ankur

Re: Application note on memory usage in DSC

sumanbhandari — Tue, 22 Sep 2015 13:24:17 GMT

Hi Ankur,

Thanks for your reply.

I did an update of CodeWarrior and noticed that the linker file changed from the previous version.

The main difference I noticed is as follows:

Old version linker file :

.p_flash_ROM_data (RX) : ORIGIN = 0x001800, LENGTH = 0x001800 # internal xRAM data mirror

# for pROM-to-xRAM copy

## Data Memory space

.x_internal_RAM_code (RW) : ORIGIN = 0x000000, LENGTH = 0x001800 # alias of 60000 for program space

.x_internal_RAM_data (RW) : ORIGIN = 0x001800, LENGTH = 0x001800 # alias of 60000 for program space

New version linker file:

.p_flash_ROM_data (RX) : ORIGIN = 0x000000, LENGTH = 0x003000 # internal xRAM data mirror

# for pROM-to-xRAM copy

## Data Memory space

#.x_internal_RAM_code (RW) : ORIGIN = 0x000000, LENGTH = 0x001800 # alias of 60000 for program space

.x_internal_RAM_data (RW) : ORIGIN = 0x000000, LENGTH = 0x003000 # alias of 60000 for program space

After this change we did see some improvements. But the data corruption still occurs intermittently and is difficult to catch and debug.

We are currently using 100Mhz clock, could reducing the clock frequency help?

Thanks

Suman

Re: Application note on memory usage in DSC

ankur_kala — Wed, 23 Sep 2015 04:33:49 GMT

Hello Suman,

So the latest update is the right approach to go. what kind of data corruption are you seeing now. can you attach the linker file and if possible the map file generated from your project.

Regards,

Ankur

Re: Application note on memory usage in DSC

sumanbhandari — Wed, 23 Sep 2015 11:01:36 GMT

Thanks for the reply.

Yes the update helped a little.

We use a global structure array in our code and intermittently when the global structure members are accessed or passed as a parameters the values get corrupted.

Attached is the linker file.

As suggested earlier this linker file is generated by updated PE and used in static our project without PE

Regards,

Suman