Application note on memory usage in DSC

[ankur_kala]

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.

[sumanbhandari]

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.

[ankur_kala]

Hi Suman,

Is your problem fixed.

Regards,

Ankur

[sumanbhandari]

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

[ankur_kala]

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

[sumanbhandari]

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

[ankur_kala]

Hello Suman,

You can crosscheck the map file also to see if the data segment is long enough for the amount of data. From the linker file, the segmentation seems good now.

Regards,

Ankur

[sumanbhandari]

Dear Ankur,

Thanks for the reply.

I checked the MAP file the segments seems proper. Attached is the same.

Regards,

Suman

[ankur_kala]

Hello Suman,

In this case the segments look good. I guess the structure array in discussion is 'FVarDataStructure1'. In this case it looks to be an issue of application handling the parameters. From the system side, linker file and map file are OK. Ensure that you are working with optimizations turned OFF to start with. You can always go back to optimization later.

Regards,

Ankur

[sumanbhandari]

Dear Ankur,

Thanks for the reply.

Yes the data structure 'FVarDataStructure1' gives issues apart from other local variables.

We are not using any optimization currently.Attached is the screenshot.

Regards,

Suman

[ankur_kala]

Hello Suman,

In this case you will need to forward your software along with instructions to reproduce the issue.

regards,

Ankur

[sutter_zhou]

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.

[ankur_kala · Accepted solution]

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.

[johnlwinters]

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?

[ankur_kala]

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.

[ankur_kala]

Hi johnlwinters and Ben,

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

[johnlwinters]

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.

[johnlwinters]

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.

[ankur_kala]

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

[Ben]

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).

[johnlwinters]

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.