Memory Management - Code And Large Flash Objects

[Fred]

I haven't put a lot of thought into this just yet. I was hoping that some of you guys could help me out with ideas and suggestions in this regard. Probably as I type this post I'll realise a few things anyway.

There are two chunks of flash permanently visible to the CPU with efficient instruction calls. They are 14 and 16 K and total 30k of space. There is a 16k window through which we can view ONE other block of flash at a time.

Because we are being a bit greedy we need to use the paged space to hold various things that aren't constantly needed.

The state of the play is that you can put either functions or data structures in the paged space. Previously I had everything in linear space and there were no issues, however now the situation exists where the code and data MUST be accessible at the same time. What this means is that either they must be on the same page, ie, code in the same 16k block as data it is working with. Or, the code can be in the paged block, and the data in permanent space. Or the data in paged space and the code in permanent space.

Right now its all a non issue, however that is going to change.

Basically we need to segregate the code and data in such a way that each can always see the other. For the main tables, paging them is natural as only a small part of init.c and commsCore.c need to see them at the same time and those can be put in the perm area without issue. For fixed config though, many many parts of the code will need to see them and thus it would be best if the fixed conf was permanent and the many many were paged.

It looks like I have answered my own question to some extent, but if Jean and others with a few ideas and some experience in this want to comment, I'd be glad to hear it :-)

Fred.

[jbelanger]

One thing that can help is that for a lot of tables, you'll want to access them through an interpolation function. This function can be put in the same memory block as the tables. Then you call this function from any place in memory and the result is returned on the stack and you don't have to worry about where the calling code is with respect to the data. This method may be applicable in other situations if needed.

Jean

[Fred]

That is a good point that I hadn't thought of, however all of the live tunable ones are in ram and paged there so that won't help because they aren't a problem anyway. As far as I can tell it's fine to hide the IAT etc tables in paged flash and it's fine to hide all the ram buffered stuff in paged flash, which only leaves the fixed configs really (which are tiny right now and probably won't grow that much).

Perhaps I need a better understanding of how the calls are made etc. I'll look into making sure I understand that fully before we go too much further.

I also have a huge number of these :

Code: Select all

init.c:(.text.initPagedRam+0xd69e): warning: reference to a banked address [fe:9000] in the normal address space at d69e

I guess I'd like to cut back on them, or figure out some way of cutting them out of the build output.

Cheers for the input :-)

Fred.

[Fred]

Jean, although your example wasn't applicable, the general idea was/is :-)

I went click tonight and realised how I could do it.

I'm now using 3 pages of flash each with 8 1k tables and a function that does two things at the same time, inits some pointer vars pointing to the tables and copies the flash up to ram. You don't get a warning for functions called from paged space, only data, so its quieter now. Tomorrow I'll try to make it silent :-)

One strange thing though...

I have garbage collection on, and it is collecting the .tramp region :-/ I have no idea why, and the firmware runs fine, but I don't like the look of it there in the build output.

Code: Select all

/usr/lib/gcc-lib/m68hc11/3.3.6-m68hc1x-20060122/../../../../m68hc11/bin/ld: Removing unused section '.tramp' in file '/usr/lib/gcc-lib/m68hc11/3.3.6-m68hc1x-20060122/m68hc12/mshort/libgcc.a(_far_tramp.o)'

Buggered if I know really. Perhaps its some legacy thing from hc11 ? Maybe I should read the gcc code and find out myself.

Next thread!

Fred.

[Fred]

No linker warnings at all now :-)

I had a small bug in one function referring to flash stuff when it should have been referring to ram, but solved that this morning.

I've added dual linking to the make file temporarily too. it first does GC then does it without. I feel safer this way but i'd like to figure out the .tramp thing!

Thanks Jean! I'll have to put in an honourary mention somewhere as I've done for a few others.

Fred.

[jbelanger]

I'm glad I could help even if it was in very indirect way.

Jean

[MotoFab]

That is a good point that I hadn't thought of, however all of the live tunable ones are in ram and paged there so that won't help because they aren't a problem anyway. As far as I can tell it's fine to hide the IAT etc tables in paged flash and it's fine to hide all the ram buffered stuff in paged flash, which only leaves the fixed configs really (which are tiny right now and probably won't grow that much).

Perhaps I need a better understanding of how the calls are made etc. I'll look into making sure I understand that fully before we go too much further.

Hi Fred. If I'm understanding the question correctly, maybe this will be of some use. I took a look at the processor datasheet and from what I understand the program can get to any ram page using global instructions and the GPAGE register. That seems to fit with what you're saying so I hope I'm on the right track.

But to get to a particular 16k flash program memory page, the page bits must be preset in the PPAGE register. I think one way to do that is, when you're calling a program memory location or function, is to place the page setting instructions into the call, as a preface I mean.

Sometimes the page setting instructions will be redundant because the program is already on that page.

Something I haven't read about yet is whether the program can get back to the original page that the call was issued from, does the return address include enough bits to do that I mean.

Maybe this will show that I need a better understanding too, heh heh.

- Jim

p.s.: This project is steadily moving along. Good on ya. I am glad to see it.

[MotoFab]

Or, maybe place a duplicate set of 'calls to calls' say on the top of each of the 16k windows. What I mean by 'calls to calls' is, create a preliminary call for each actual call that first sets the 16k flash page bits, then calls the call. Placing a duplicate set of these on the top of each 16k window allows any call to be made from any page.

- Jim

[Fred]

What I was on about was the linker warnings. There was no actual problem as such. I've got it 100% under control now.

Unfortunately the compiler doesn't support the GPAGE stuff or DIRECT stuff. There are a number of addressing modes, but only the two original S12 modes are available to us. This is fine however as we need no features of the other systems anyway.

Fortunately the compiler takes care of both moving to the page IF required and moving back to the caller page afterwards IF required. No work to do for me except in terms of burning it where we will do exactly what you suggest with a push pop arrangement :-)

Thanks for the encouragement!

Fred.

[MotoFab]

Fortunately the compiler takes care of both moving to the page IF required and moving back to the caller page afterwards IF required.

That's handy. Well, carry on then