Problem with putting a function in global memory

[skidooman]

Hi there:

Sorry - I already posted a similar message in another section of the forum, but I realized that this is the right forum for this question. If a mod wants to remove my other message, please do.

My environment: XDP512 on simulator, using the banked memory model on CW 4.6.

Basically, I have a function that goes above 12K (code) that I want to put in a global memory allocation in ROM. I used #pragma CODE_SEG __FAR_SEG MY_GLOBAL_SPACE at the beginning of my function (I do not have a header file where these are defined), and at the end of the function I put #pragma CODE_SEG DEFAULT.

Here's an excerpt of my PRM:

      PAGE_FB       = READ_ONLY   0xFB8000 TO 0xFBBFFF; 

      PAGE_FC       = READ_ONLY   0xFC8000 TO 0xFCBFFF;
      PAGE_FD       = READ_ONLY   0xFD8000 TO 0xFDBFFF;

/*    PAGE_FE       = READ_ONLY   0xFE8000 TO 0xFEBFFF; */
/*    PAGE_FF       = READ_ONLY   0xFF8000 TO 0xFFBFFF; intentionally not defined: equivalent to ROM_C000 */

      GLOBAL_ROM    = READ_ONLY   0x7F8000'G TO 0x7FFFFF'G;

If the function is <12K, Code Warrior readily puts this function inside that global space. No problem there.

If the function is >= 12K, then the program compiles and links fine, but when executing, upon loading HIWAVE complains of several faults. Here are some of these faults (most of them repeat):

main 0xFB8000'L T
STARTED
RUNNING
FCS Warning (ID 26): reading from reserved register at pc = 0xfb801e'L. Value: 0x0, Memory Address: 0x5. MEBI module is affected.
...
FCS Warning (ID 13): writing to unimplemented register at pc = 0xfb8022'L. Value: 0x0, Memory Address: 0xB0. IIC module not implemented
FCS Warning (ID 13): writing to unimplemented register at pc = 0xfb8022'L. Value: 0x0, Memory Address: 0xB1. IIC module not implemented
FCS Warning (ID 25): writing to reserved register at pc = 0xfb8022'L. Value: 0x0, Memory Address: 0xDC. SPI module is affected.

...

Etc. And then finally:

No memory at [384'G:1]

The problem is that I am not sure how I end up violating memory in PAGE_FB when I am not trying to access it. It seems my main gets put in there and somehow ends up causing a fault. 

COuld you help me shed some light on what is going on here? Is it possible to have a function that is larger than 12K here?

Best Regards,

Steve

[CompilerGuru]

>  GLOBAL_ROM    = READ_ONLY   0x7F8000'G TO 0x7FFFFF'G;

Don't put code into global areas. It's up to the prm to make sure functions are not allocated across a page boundary and when placing functions into  GLOBAL_ROM this may fail.

I would suggest to only use global ('G) addresses for large data structures and for nothing else.

Daniel

[skidooman]

Hi Daniel:

I see. So, if I have a function that grows above and beyond 16k, it just won't fit, nothing I can doabout it, right?

I tried to put the code in the unbanked ROM, but obviously, it is limited to 16k too...

[CompilerGuru]

The right approach is obviously not to have such huge function-monsters. :smileyhappy:

It is possible to use (part of) the two unpaged areas together with a paged one as single flat area with almost 48k. The truth here is that I never tried such a setup, just given my knowledge of the architecture it should work. No guarantee that there are no special things to handle, and no problems with debugging and other details :smileyhappy:.

Daniel

[skidooman]

Hi Daniel:

Yeah, I know, it would be preferable not to exceed 12k for a single function, but in this case, I do not have much other choice. That decision is not in my hands.

Could you indicate how to use the two unpaged areas together? Since they are not consecutive, how do you make them as one?  And, how would you include one page with it?

I understand this may not work, but I would like to try. It would be a tentative solution.

Thanks!

Steve

[skidooman]

Hi Daniel:

I meant, 16K, of course.

Actually, I keep reading it is possible to store up to 32K. Could that 32K be made so it is the size of one function? 

I would need to put a single function of 20K. Any indication on how to do this would be very appreciated, even if you did not try it. I will try and let you know.

Thanks!

'

Steve

[CompilerGuru · Accepted solution]

Hmm. When looking at the initial topic I'm actually not sure why it failed.

It shows a couple of FCS warnings, are those "normal" or just because of the huge function?

I see there is an"No memory at [384'G:1]" access, what is accessing this?

It apears that this must be some global data pointer access (code does not get fetched via global addresses), do you see why this fails? Why is the code reading from 0x384'g?

I've attached a simplistic test setup which just has a huge 20k function which does one thousand times the same little snippet.

It works for me in the simulator, I don't have HW here right now (or actually I don't have a powersuply for the EP100 here).

I did notice that debuging the 4k outside of the 16 page window does not show the source code. Somehow not so suprising. But the assembly code gets properly executed (in the simulator).

Daniel

[skidooman]

Hi Daniel:

I will try your code from here tomorrow (it seems you are located in Asia-Pacific).

As for your questions:

- The FCS erros only occur whenever the code exceeds 16K

- I tried to see what was trying to access 384`G, and it is I just don`t recognize (.text?).

I also tried your code. I am not on hardware, but on the full chip simulation.

Hiwave still reports that something along these lines:

No memory at [FE8003'L:2]

OObviously, it is right at the biginning of the HUGE_FUNC_SEG

I wonder if the debugger is not at fault here, since obviously it worked for you and you were able to run.

For instance, in the case of lines not showing up, I wonder if Command-> Cache Size has anything to do with it.

 Or if not the debugger, maybe some type of settings that needs to be done within the CW environment to enable that type of capability?

Thanks for the help so far! Sorry it seems to be more complicated that it appeared initially.

Steve

[CompilerGuru]

Silly me.

My sample used to work fine before I tweaked the prm file shortly before zipping it.

Change

      HUGE_FUNC_SEG     = READ_ONLY   0x7F8001'G TO 0x7FFEFF'G;
back to

      HUGE_FUNC_SEG     = READ_ONLY   0x7F8000'G TO 0x7FFEFF'G;

Using 1 exposes a simulator issue, the"No memory at [FE8003'L:2]" message is not correct.

However appart from the message, the simulation outcome is not affected by this bug.

Also note that this issue is not related to the ones you see in your app, it is only happening when there is a undefined byte just before code being executed (0x7F8000'G is the undefined one here).

Did you try it out on HW? Does it fail there too?

I'm not sure why your app is failing for you in the simulator either, can you provide a reproducible app?

Daniel

[skidooman]

Hi there:

Thanks for all the help. I do not have a board with me, but I will test this as soon as I can. Maybe that message will not appear in hardware, who knows!

Then, I will reply to this message and let you know one way or the other.

Best Regards,

Steve

[skidooman]

Hi Guru, Hi Jedi:

I wasn't able to try it on my own, but I asked someone with access to a board to try it, and the code works fine!

Thank you very much for your help, it is appreciated indeed!

Steve

[J2MEJediMaster]

What is the memory model is the compiler is using to generate the code? Is it banked (-Mb), small (-Ms), or large (-Ml)? Look in the HC12 Compiler Settings panel, the Code Generation tab, to find out.

---Tom

[skidooman]

Hi Tom:

I am trying with banked (-Mb).

Thanks!

Steve

[J2MEJediMaster]

Well, now I'm at a loss. I've seen problems similar to this where the wrong memory model was being used, but this doesn't seem to be the case.

---Tom