Urgent need for help. Non volatile MC13213 application parameters.

[Jonte]

Hi,

I'm developing an SMAC application for the MC13213 device. I would need to store some parameters (approx 10-16 bytes) to non volatile flash memory. This must be done from the application code itself (on a daily basis at maximum).

I have seen suggestions for how to achieve this in a Freescale forum thread. See S08_Flash_A2.zip attached to a post in the forum thread for the suggested solution.
https://community.freescale.com/message/68186#68186

However I don't know what changes must be done to my PRM file.

I have attached the PRM file of my project. I would be most grateful if I could assistance with the appropriate changes of my PRM file.


Best Regards,

Johan Hammar

[bigmac]

Hello Johan,

You initially had some problems with overlapping or segments with incorrect range.  These needed to be first corrected, before making the changes required to place the RAM based code.  These corrections are shown in red, within the following PRM.  I have also re-sequenced some ot the lines for clarity, but should not affect PRM operation.

/* Linker parameter file for the GB60 */NAMESENDSECTIONS /* all RAM/ROM areas of the device are listed. Used in PLACEMENT below. */  Z_RAM        = READ_WRITE 0x0080 TO 0x00FF;   RAM          = READ_WRITE 0x0100 TO 0x0B7F; //0x107F;  Adjust to allow for SSTACK  SSTACK       = READ_WRITE 0x0B80 TO 0x107F; // Explicit stack section now defined.  ROM2         = READ_ONLY  0x1080 TO 0x13EF; //0x17FF;  Previous overlap with NVRAM  FLASH_TO_RAM = READ_ONLY  0x13F0 TO 0x13FF RELOCATE TO 0x0B80; // RAM based code.  NVRAM        = NO_INIT    0x1400 TO 0x17FF; //0x1800; /* 802.15.4 MAC NVRAM AREA */  ROM          = READ_ONLY  0x182C TO 0xFAFF; //0xFEFF;  Previous overlap with vector areaENDPLACEMENT /* all predefined and user segments are placed into the SECTIONS defined above. */  _DATA_ZEROPAGE, MY_ZEROPAGE   INTO Z_RAM;  DEFAULT_RAM                   INTO RAM;  DEFAULT_ROM                   INTO ROM/*, ROM2*/;   /* in case you want to use ROM2 here as well, add option -OnB=b to the compiler. */  DOT4MAC_NVRAM                 INTO NVRAM;  FLASH_ROUTINE                 INTO FLASH_TO_RAM; ENDSTACKTOP 0x107F//STACKSIZE 0x500          VECTOR 0 _Startup /* reset vector: default entry point for a C/C++ application. */

The additional and modified items, for flash programming purposes, are shown in blue.  The intent is to place the code that is eventually relocated RAM (bottom of stack position) at the FLASH_TO_RAM location.  A stack segment SSEG is also explicitly defined so that the bottom of stack position is known.  Consequently, STACKTOP (rather than STACKSIZE) has been defined.  The size of the stack should remain at 0x500 bytes.

When modifying a PRM, make sure that the various sections that are defined do not overlap each other.

Regards,

Mac

[Jonte]

Hi Mac,

Thank you for your promt reply.

Unfortunately I get the following Linker error when attempting to build my codewarrior project using the corrected PRM file that you provided:

Error: L1004: ';' expected

Linker.prm line 11

Linker Error: Link failed

(This is the line defining the FLASH_TO_RAM section).

Any idea?

Best Regards,

Johan

[CrasyCat]

Hello

Apparently you are looking for a way to run portion of your application from the stack.

If this is what you intend to do, refer to attached Technical note.

You cannot use RELOCATE?TO in that particular case.

CrasyCat

[bigmac]

Hello,

The method of flash programming that the OP refers is not of the "do_on_stack" variety, which I think TN235 refers.

The method being attempted actually uses a 16 byte block of code that needs to be relocated to a fixed position in RAM, and executed.  It so happens that the RAM position being attempted is the very bottom of the stack segment, where it will least likely be disturbed by normal stack operations, in the short term at least.  However, any other suitable block of RAM could have been used.

I am not sure of the reason for the L1004 error - it seems to be indicating a missing semi-colon - but this method of relocation has previously been successfully used.

Regards,

Mac

[CompilerGuru]

There is a little typo in the prm on line 11. The line contains the two words RELOCATE TO, but actually the linker expects  RELOCATE_TO, a single keyword with an underscore.

Daniel