topic Re: no_init in Coldfire CW6.3 LCF linker command file? in Classic/Legacy CodeWarrior

no_init in Coldfire CW6.3 LCF linker command file?

dougpaulsen — Mon, 02 Jun 2014 14:20:08 GMT

It seems like it should be straightforward, but I'm having difficultly understanding how to declare un-initialized RAM in LCF-type linker files.

The use of the NO_INIT keyword in PRM linker files is discussed here and there in the forums and I've used it in other 8-bit CW projects, but my current interest is for Coldfire processors. Under CW 6.3, these deploy a LCF linker command file. I not been able to locate any documentation indicating the NO_INIT (or similar) keyword is valid there.

Obviously, there are a few variables which would be vary helpful to persist over a PIN reset. The CW default is for all un-initialized variables to be cleared to zero, which I understand and appreciate. This is my first Coldfire project, but other experiences with other micro/compiler combinations make declaring un-initialized variables quite easy. One wonders why CW makes it so obtuse in the case of Coldfire processors. Is there perhaps a hardware restraint?

Regardless, I would appreciate any comments/directions on setting up uninitialized segments in LCF files.

Thanks!

Doug

Re: no_init in Coldfire CW6.3 LCF linker command file?

dougpaulsen — Tue, 03 Jun 2014 19:07:51 GMT

Okay!

I managed to piece together a working solution out of a lot of research.

First, I modified the my LCF linker command file as follows:

MEMORY

{

....

NVRAM (RW) : ORIGIN = 0x00800000, LENGTH = 0x00000100

....

}

SECTIONS

{

....

.no_init :

{

*(.no_init)

} > NVRAM

....

}

Then, within my code, I declared my persistent data (in this case, a clock structure) as follows:

#pragma define_section NO_INIT ".no_init" ".no_init"

__declspec(NO_INIT) volatile T_CLK tClk; //uninitialized!

Now, at least in preliminary tests, my clock will survive a PIN reset to keep counting, but of course I'll have to do something specific on any other reset (POR, COP, etc.), but I'm willing to deal with that.

Good luck to all in your non-CW 6.3, non-MCF51 implementations. I've had to experiment with a number of community posts to come up with the above. Some of the offerings seemed to do nothing. Others produced linker error messages I just don't care to deal with. LCF documentation was marginally helpful (I thank whomever I ripped off the above from, wherever you are).