V6.2 ColdFireV1 JM32 SP, build 080723
V6.2 HCS08 JS16 SP, build 080625
V6.2.1 Compiler Patch, build 8205
I don't think this matters, but in case it does, the IDE version is 5.9.0 Build 2830.
Background with a couple of the questions:
We are using a DEMOJM board to evaluate the MCF51JM for a customer's application that will use USB OTG.
I have built and modified some of the USB-LITE Stack applications from CMX. First, without any modifications, the compiler/linker issued the following warning:
All segments to userram have to begin at address aligned to 512
Please add ".=ALIGN(512);" before every "} >> userram"
After some digging, I found that CMX added a section/area (__BDT_BASE, __BDT_END) to userram in the .lcf file and they put ". = ALIGN(512);" before __BDT_BASE.
First question is why does adding the ALIGN(512) cause the linker to issue that warning?
NOTE: I am not questioning why the ALIGN is necessary.
I looked at the map file and __BDT_BASE is aligned on a 512 byte boundary, and everything else is aligned as it should be on 4 byte boundaries.
Being that I am a bit obsessive compulsive when it comes to compiler warnings, I removed the ALIGN(512) and replaced it with this:
__bdt_padding = (512 - (. & 511)) & 511;
. = . + __bdt_padding;
__BDT_BASE = .;
which worked to quiet the warning and __BDT_BASE is located in the exact same location as with the ALIGN(512) command.
Is there a way to do the ALIGN(512) with the ALIGN() function without having the linker issue a warning?
Would adding the suggested ALIGN command before each '} >> userram' create more dead areas in memory? (Yes, I could test this, but it just does not look like the right solution, and I suspect it will create unnecessary dead areas in memory.)
Can I write macros or functions in the LCF so that I can make a MYALIGN() function or macro?
After that I made some modifications to one of the applications by adding functionality that reads from an off the shelf USB based GPS and then does some calculations using the lat and long - mainly using the haversine formula, but other calculations as well. Long story longer, I ran into some problems that turned out to be a stack overrun, so back to the .lcf file. I increased ___stack_size, and that fixed that problem.
So the next question, is there any reason that I cannot set ___SP_INIT equal to ___RAM_ADDRESS + ___RAM_SIZE and set ___SP_END to what ever is next to the last - be it the heap (not used and of size 0) or BDT?
What I typically do is near the end of a project is measure the actual stack usage, pad that number so there is enough room for all ISRs, and then add some canary values that become part of the system watch dog. But during the main part of development I don't see why all of the unused RAM cannot be put to use for the stack.
And finally, while I was searching for answers to the above questions, I saw some posts that mentioned that some lcf commands are different if you are building within the IDE vs from a command line / make. I did not make note of that post, and it was for a non CF V1 part, but I would like to know if such things apply to the V1 parts. If the project goes forward, we will be building from a makefile and not the IDE.