Address Space overflow

OOps! Made a mistake in addition in my previous post.

987A + 7 = 9881

Sorry.

OOps! Made a mistake in addition in my previous post.

987A + 7 = 9881

Sorry.

Dear All,
If in case you find my observations wrong, or have any other solution, kindly inform me.

Thank you for all the necessary help, guidance and valuable time you provided. Learnt a lot.
Hope the observations and conclusions helps other newbies to solve the problems related to 'Code Banking' and 'Address Space Overflow'.

Regards,
Dhaval Solanki

Glad to see you've got it going.

Regardless of what anyone else might say about banking, I think what Keil did to provide the mechanism is really pretty smart. Certainly for the application I used it on, the results were perfectly acceptable; in terms of development time, reliablility and end product costs. And, after the initial learning curve in getting it going, the fact that we were using banking was virtually forgotten about.

That said, for any new projects, I would recommend you keep an open mind and consider something different.

Dear,
I already highlighted
... Cortex-M3 is used for all the new project development. ... Never the less, I would also, as my personal opinion, always work with latest controllers and technology. .

I am glad that Keil has provided the feature "Optimization: Level 10: Rearrange Code (Linker Optimization) ". I mean they should, to be the best IDE software developers. Respect.

But i still Fail to understand

The starting address of each bank = End address of common bank + 1

This should not happen, ideally.

But i still Fail to understand

The starting address of each bank = End address of common bank + 1

This should not happen, ideally.

On the contrary: that must happen. Your believing otherwise indicates you don't really understand how banking works.

The common bank is called a "common bank" because it contains the material that has to be commonly accessible to code in all banks. The only way that can work is if the entire address range of the common bank is reserved and kept available, regardless which other banks are mapped. In a scheme like SiLabs', with a 32KiB+32KiB hardwired bank mapping, the only way the common bank can become bigger than 32 KiB is if all bytes beyond the 32 KiB boundary are copied to all 3 "upper" banks, so they'll be accessible regardless which of the upper banks is currently active.

I think your real problem was that in your original configuration you placed too much stuff into the common bank yourself, causing this spill-over mechanism to be triggered.

Dear Hans-Bernhard Broeker,
Thank you for clearing the air. But, in my opinion, there should be a document produced by the chip vendor stating this. A newbie may not understand this, the very first time he is using the IC, or may not have a clear picture unless he faces a problem like me.

Dhaval

But, in my opinion, there should be a document produced by the chip vendor stating this.

Though it might be helpful if the chip vendor produced application notes or other documentation relating to such things, I don't think it is really something that they should be expected to do. Which compiler vendors would they document for? Where would they stop?

The Keil documentation relating to banking is reasonably good and:

http://www.keil.com/support/man/docs/bl51/bl51_codebanking.htm

It just requires the reader to have an appreciation of what it is trying to achieve and what is possible.

But, in my opinion, there should be a document produced by the chip vendor stating this.
well, SILabs does

The Keil documentation relating to banking is reasonably good and:
but is somewhat invalid for the SILabs (and other?) chips with "internal banking"

go by the SILabs appnote, it is crystal clear

Erik

go by the SILabs appnote, it is crystal clear

I'll take your word for it :)