We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
This is an MP3 Player application. I have a code of size 116k, which resides in the Program memory (On Chip -SoC with in built 8032 & DSP) upon boot up. This code initially resides in a external Nand Flash memory chip alongwith DSP code as an image file (Size:4mb). Once the system is On, the image file is parsed. I mean 116k of 8032 code is sent to 8032 Program memory and the DSP code to DSP's Program memory. I would like only 32k of 116k code to reside in the Program memory upon boot up. Please kindly suggest a method of doing the same. Can code banking be done ? If so how ?
Code banking is a means of extended the 8051 (or 8032) address space. You need some additional hardware that decodes address lines from a bank select register along with the usual address and control lines to decide where in physical memory the requested address lies. Details depend on your hardware. Typically A0..A14 are taken from the address bus, providing an upper and lower 32KB "bank" of address space. Most often, the lower 32KB (the "common bank") is at a fixed address, while the upper bank is mapped to different locations in physical RAM. When A15 == 1, some external bank select register provides the upper bits of the physical address. Another fairly common scheme is simply to replicate the 64KB address space through the physical RAM, and swap the entire address space at once. This method requires duplicating the common code (especially interrupt handlers) in every 64KB bank. The Keil manuals describe both of these methods, and how to configure the tools to generate code to match. You'll need to customize the L51_BANK.A51 module to match your hardware. From your description, you have some sort of bootstrap code that reads the NAND flash and copies code into various RAMs for execution. Presumably you own the code for that application. If you want it to copy only 32KB of 8032 code, then write the boot code that way. I'm not sure why you wouldn't copy the entire program to RAM. The 8051 core doesn't have any built-in support for caching or paging, so you'll have to do it all in software. If you have a program store RAM less than 116KB (perhaps this is where the 32KB number comes from?), and you are trying to page part of your code in at a time, you'll need to modify the example banking code not only to bank switch, but to wait while the page transfer completes. To be successful, your 8032 code will almost certainly have to be structured in a few highly independent phases or overlays. You probably won't be able to accept the delays involved in copying a 32KB page on every function call. In this case you would need to minimize inter-bank transfer of control.
Just as an aside, 116K is an awful lot of 8032 code! I presume that the DSP is doing all the MP3 hard work, so what does the 8032 do that takes so much code?!
The 8032 acts as an interface between user and the DSP. The s/w is written in the form of event driven co-operative kernel. Hence the code size of 116k
My project aim is to use only 32k of Program memory of 8032 of the present 128k. The 128k Program memory (SRAM) will be replaced by a 32k SRAM after this project is successful. Presently,once the system is On, the 116k of 8032 code resides in the 128k Program memory of 8032 and code banking is done. (For this the L51_BANK.a51 file is used in which ?B_NBANKS is set as 2. So,does this mean that there are two code banks (Bank0 & Bank1)?Also does it include the common code(area)? Also the hardware for code banking exists. I have thought of a method: AFTER THE SYSTEM IS POWERED ON, THE BOOT LOADER WILL INITIALIZE THE PERIPHERALS AND DO PARSING. THE PARSING SHOULD BE SUCH THAT DSP CODE MUST RESIDE IN DSP'S PM , 8032 CODE OF 32K (OUT OF 116K) MUST RESIDE IN THE 128k, 8032'S PROGRAM MEMORY. THE REMAINDER PART OF 8032's 116K CODE WILL RESIDE IN THE NAND FLASH(size:128M x 8) ITSELF after PARSING. Please kindly suggest whether this method will do. or is there any other way out.
Still sounds like an awful lot of code for just a user interface! Does it really need to be that big?! "The s/w is written in the form of event driven co-operative kernel. Hence the code size of 116k" (my emphasis) Maybe I'm just reading too much into your English usage, but the above says that the size of the code is due to writing it as an "event driven co-operative kernel" (whatever that means). Could you not choose a more efficient implementation, and save yourself the grief of code banking?
Could you not choose a more efficient implementation, and save yourself the grief of code banking? naaah, he has not realized The '51 ain't no PC Erik
I thought I'd seen it before: http://www.keil.com/forum/docs/thread7519.asp#msg34757
ah, did not notice the therad was duplicate when posting both places Erik