[SOLVED] CCS places string handler outside of #ORG range

[bkamen]

So I've been playing with the CCS bootloader and I noticed that the printf handler in the bootloader code is being placed OUTSIDE the range the bootloader is supposed to live in.

If I define the application to take up all the space that isn't bootloader space, I get a compiler error that says there's no space available (when there is). If I back off the application zone definition, those items are inserted right after the "end" of application space and the compile succeeds.

It's obvious what it is as the "CALL PSTRINGC_115200_31764_31765" points to:

[FvM]

Because there may be various misunderstandings about the exact way, you are defining the said code locations, I would prefer to see an example, and also know about the compiler type and version.

[bkamen]

[bkamen]

Nevermind... I talked with Mark and it's just a matter of the #ORG placement.

In front of the #USE RS232, it does what I'd expect, BEHIND the #USE RS232 it was doing what I didn't expect.

Some of the pre-processor commands are really kinda location specific when it comes to some other pre-processor commands.

-Ben

EDIT: As it turns out though, strings (like printf("HELLO!\r\n"); ) are actually reserved in space OUTSIDE a controlling #ORG for a given function. I'm still looking into this with CCS.

So in the bootloader where I have #ORG 0x100 (where 0x100, 0x7FF) is the previously defined range, inside a function a PRINTF() and it's constant string can be found OUTSIDE 0x100-0x7FF someplace. Ouch.)

UPDATE: Ok, so where I was going wrong was the use of default with #ORG. I was following the CCS example which had a final #ORG default at the end of the bootloader.c followed by a #int_global.

I thought the #int_global needed the #org for whatever reason. But being the last #org WITH a DEFAULT seen by the compiler, it told the compiler that anyplace outside my bootloader region was ok to place constants and code which was undesired.

So I removed the #org, #int_global still went to 0x0008/18 and other stuff of concern got properly stuffed into the loader defined segment as desired.

Cheers -- Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D