Is there a way to make the bootloader code occupy a specific section in program memory?
I noticed that some of the code is written in the top section of memory but the other part is written starting at section $11000. In my case it conflicts with my application code. So how do I force the bootloader code to occupy program memory starting from $00000 to $10000? I am assuming it can be done by changing some settings under Mplab XC8 compiler.
PIC: PIC18F87J11
Compiler: MPLAB XC8
Update:
Found the fix
Project properties > XC8 global options category > Memory Model > ROM ranges
ROM RANGE: 0-10000
Update:
I am seeing another issue though.
So I set the ROM range from $00000-$10000, but that's not enough space for the bootloader code even though it should. However when I look at the program memory under MPLAB XC8 after building the project, I noticed that there are some addressees left empty.
How do I force those addressees to be used? If those sections were used then the specified ROM size from 0-10000 should be enough for my bootloader code.
For example those addresses are used (data written there)
00000-0925C
But then these address are not used, just left blank
0925E- 0F77A (huge section, what a waste)
Then these addresses are used
0F77C-0FFFE
But then my program gets cut off at $10000 even though there seems to be more code to be written to memory.
So
How do I force those unused addressee to be used? Its just a huge waste of memory to skip them and I don't understand why they are empty. I can not give the Bootloader anymore ROM space, the rest must be given to the Application Code.
I hope everything is clear, thanks!
To place the bootloader in the specified memory, you should:
1) In the code - create the section.
int __section("_bootloader") helper(int mode) {
/* ... */
//bootloader functions here
}
2) In the options of linker - add options to place the section to the specified memory.
-L-A_BLOADER=00h-ffffh
-L-p_bootloader=_BLOADER
To see the exect functions placed in the memory range 0F77C-0FFFE, you may see the *.map file (if it is generated).
Related
I'm a newly graduated electronics engineer and one of my first tasks in my new job is to import a code to Mbed compiler.
I'm trying to run the Mbed Blinky example on my custom hardware with LPC1769 chip. I've exported the Blinky app to GNU Eclipse from the Online MBED compiler and imported it to the IDE.
The Mbed blinky code runs fine when I set the appropriate led pin(changing LED1 in the PinNames.h from 1.10 to 2.13 for my hardware) and flash it directly. So MBed and my custom HW isn't problematic. However, my firm has a custom bootloader and it's required to use it with any application. The custom bootloader requires that I start the program beginning from 0x4000.
For this my firm was previously adding this line to their code, flashing the bootloader and uploading the IDE's output .bin file to the board with a custom FW loading program.
SCB->VTOR = (0x4000) & 0x1FFFFF80;
When I try to follow the same steps, compiler builds without any complaints, but I see no blinks when I upload the program to my bootloader.
I'm suspecting I have to make some changes to the built-in CMSIS library, and/or the startup_LPC17XX.o and system_LPC17xx.o files come with the MBED export, but I'm confused. Any help would be much appreciated.
Also, I'm using the automatically built make file, in case there's any wonders.
Most importantly, you need to adjust the code location in the linker script, for example:
MEMORY {
FLASH : ORIGIN = 0x4000, LENGTH = 0x7C000
}
Check the startup code and linker script for any further absolute addresses in flash memory.
Adjusting the VTOR is required for interrupts, if the bootloader doesn't already do that. The & operation looks weird; it should be sufficient to simply write 0x4000, or, even better, something like:
SCB->VTOR = (uint32_t) &_IsrVector;
Assuming you have defined _IsrVector in your linker script or startup code to refer to the very first byte in the vector table, i.e. the definition of the initial stack pointer. This way you don't have to adjust the code if the memory layout is changed in the linker script, and you avoid magic numbers.
Ok, I have read several discussions regarding the differences between JIT and non-JIT enabled interpreters, and why JIT usually boosts performance.
However, my question is:
Ultimately, doesn't a non-JIT enabled interpreter have to turn bytecode (line by line) into machine/native code to be executed, just like a JIT compiler will do? I've seen posts and textbooks that say it does, and posts that say it does not. The latter argument is that the interpreter/JVM executes this bytecode directly with no interaction with machine/native code.
If non-JIT interpreters do turn each line into machine code, it seems that the primary benefits of JIT are...
The intelligence of caching either all (normal JIT) or frequently encountered (hotspot/adaptive optimization) parts of the bytecode so that the machine code compilation step is not needed every time.
Any optimization JIT compilers can perform in translating bytecode into machine code.
Is that accurate? There seems to be little difference (other than possible optimization, or JITting blocks vs line by line maybe) between the translation of bytecode to machine code via non-JIT and JIT enabled interpreters.
Thanks in advance.
A non-JIT interpreter doesn't convert bytecode to machine code. You can imagine the workings of a non-JIT bytecode interpreter something like this (I'll use a Java-like pseudocode):
int[] bytecodes = { ... };
int ip = 0; // instruction pointer
while(true) {
int code = bytecodes[ip];
switch(code) {
case 0;
// do something
ip += 1; break;
case 1:
// do something else
ip += 1; break;
// and so on...
}
}
So for every bytecode executed, the interpreter has to retrieve the code, switch on its value to decide what to do, and increment its "instruction pointer" before going to the next iteration.
With a JIT, all that overhead would be reduced to nothing. It would just take the contents of the appropriate switch branches (the parts that say "// do something"), string them together in memory, and execute a jump to the beginning of the first one. No software "instruction pointer" would be required -- only the CPU's hardware instruction pointer. No retrieving of bytecodes from memory and switching on their values either.
Writing a virtual machine is not difficult (if it doesn't have to be extremely high performance), and can be an interesting exercise. I did one once for an embedded project where the program code had to be very compact.
Decades ago, there seemed to be a widespread belief that compilers would turn an entire program into machine code, while interpreters would translate a statement into machine code, execute it, discard it, translate the next one, etc. That notion was 99% incorrect, but there were two a tiny kernels of truth to it. On some microprocessors, some instructions required the use of addresses that were specified in code. For example, on the 8080, there was an instruction to read or write a specified I/O address 0x00-0xFF, but there was no instruction to read-or write an I/O address specified in a register. It was common for language interpreters, if user code did something like "out 123,45", to store into three bytes of memory the instructions "out 7Bh/ret", load the accumulator with 2Dh, and make a call to the first of those instructions. In that situation, the interpreter would indeed be producing a machine code instruction to execute the interpreted instruction. Such code generation, however, was mostly limited to things like IN and OUT instructions.
Many common Microsoft BASIC interpreters for the 6502 (and perhaps the 8080 as well) made somewhat more extensive use of code stored in RAM, but the code that was stored in RAM not not significantly depend upon the program that was executing; the majority of the RAM routine would not change during program execution, but the address of the next instruction was kept in-line as part of the routine allowing the use of an absolute-mode "LDA" instruction, which saved at least one cycle off every byte fetch.
Is there a utility that will show me a program's current memory contents? Like a hex dump of the entire memory being used by the program? Thanks.
My utility, Bit Slicer, which runs on 10.6 or later can do this for regular applications.
1) Run the program and select a target process.
2) Go to Tools -> Dump All Memory... This will save all the current readable memory in a directory with a bunch of files each indicating a particular memory region and a file that merges everything as well. These files can then be viewed with a hex editor.
3) There's also the real-time memory viewer in the Memory menu for looking at a particular spot.
Dmalloc - Debug Malloc Library
This program came with OS 10.6 but it seems to have disappeared with OS 10.7 (which has many, many, many ... programming complications). Excluding 10.7 regrets, Dmalloc is wonderful way to examine every memory allocation.
Ah ha...
Mac OS 10.7 provides Menu-Product-Profile. I have not investigated fully used it, however, I recognize the Dmalloc icon within it.
Would it be possible to take the source code from a SNES emulator (or any other game system emulator for that matter) and a game ROM for the system, and somehow create a single self-contained executable that lets you play that particular ROM without needing either the individual rom or the emulator itself to play? Would it be difficult, assuming you've already got the rom and the emulator source code to work with?
It shouldn't be too difficult if you have the emulator source code. You can use a method that is often used to store images in c source files.
Basically, what you need to do is create a char * variable in a header file, and store the contents of the rom file in that variable. You may want to write a script to automate this for you.
Then, you will need to alter the source code so that instead of reading the rom in from a file, it uses the in memory version of the rom, stored in your variable and included from your header file.
It may require a little bit of work if you need to emulate file pointers and such, or you may be lucky and find that the rom loading function just loads the whole file in at once. In this case it would probably be as simple as replacing the file load function with a function to return your pointer.
However, be careful for licensing issues. If the emulator is licensed under the GPL, you may not be legally allowed to store a proprietary file in the executable, so it would be worth checking that, especially before you release / distribute it (if you plan to do so).
Yes, more than possible, been done many times. Google: static binary translation. Graham Toal has a good howto paper on the subject, should show up early in the hits. There may be some code out there I may have left some code out there.
Completely removing the rom may be a bit more work than you think, but not using an emulator, definitely possible. Actually, both requirements are possible and you may be surprised how many of the handheld console games or set top box games are translated and not emulated. Esp platforms like those from Nintendo where there isnt enough processing power to emulate in real time.
You need a good emulator as a reference and/or write your own emulator as a reference. Then you need to write a disassembler, then you have that disassembler generate C code (please dont try to translate directly to another target, I made that mistake once, C is portable and the compilers will take care of a lot of dead code elimination for you). So an instruction of a make believe instruction set might be:
add r0,r0,#2
And that may translate into:
//add r0,r0,#2
r0=r0+2;
do_zflag(r0);
do_nflag(r0);
It looks like the SNES is related to the 6502 which is what Asteroids used, which is the translation I have been working on off and on for a while now as a hobby. The emulator you are using is probably written and tuned for runtime performance and may be difficult at best to use as a reference and to check in lock step with the translated code. The 6502 is nice because compared to say the z80 there really are not that many instructions. As with any variable word length instruction set the disassembler is your first big hurdle. Do not think linearly, think execution order, think like an emulator, you cannot linearly translate instructions from zero to N or N down to zero. You have to follow all the possible execution paths, marking bytes in the rom as being the first byte of an instruction, and not the first byte of an instruction. Some bytes you can decode as data and if you choose mark those, otherwise assume all other bytes are data or fill. Figuring out what to do with this data to get rid of the rom is the problem with getting rid of the rom. Some code addresses data directly others use register indirect meaning at translation time you have no idea where that data is or how much of it there is. Once you have marked all the starting bytes for instructions then it is a trivial task to walk the rom from zero to N disassembling and or translating.
Good luck, enjoy, it is well worth the experience.
when i was trying to build my project in MPLAB,i got this Build error message..
Clean: Deleting intermediary and output files.
Clean: Deleted file "M:\12 CCP PWM\12 CCP PWM.o".
Clean: Done.
Executing: "C:\MCC18\bin\mcc18.exe" -p=18F46K20 "12 CCP PWM.c" -fo="12 CCP PWM.o" -Ou- -Ot- -Ob- -Op- -Or- -Od- -Opa-
MPLAB C18 v3.20 (feature limited)
Copyright 1999-2005 Microchip Technology Inc.
This version of MPLAB C18 does not support the extended mode
and will not perform all optimizations. To purchase a full
copy of MPLAB C18, please contact your local distributor or
visit buy.microchip.com.
Executing: "C:\MCC18\bin\mplink.exe" /l"C:\MCC18\lib" "C:\MCC18\lkr\18f46k20i.lkr" "12 CCP PWM.o" /u_CRUNTIME /o"12 CCP PWM.cof" /M"12 CCP PWM.map" /W
MPLINK 4.20, Linker
Copyright (c) 2008 Microchip Technology Inc.
Error - could not find definition of symbol 'main' in file 'C:\MCC18\lib/c018i.o'.
Errors : 1
Link step failed.
----------------------------------------------------------------------
Release build of project `M:\12 CCP PWM\12 CCP PWM.mcp' failed.
Thu Apr 16 14:34:41 2009
----------------------------------------------------------------------
BUILD FAILED
I have checked that the path to the linker library was correct.I suspect it has something to do with my source code...Any helps are very much appreciated.
Here is my source code.. http://cl1p.net/mplabc18
The compiler may be looking for a different definition of main. I have seen this in some PIC code:
// Main application entry point.
#ifdef __C30__
int main(void)
#else
void main(void)
#endif
{ ... }
It is a good idea to add the specific linker file to your project. If you are using MPLAB, under the workspace, right click on linker files and add the linker file from mcc16\lkr folder for the specific processor.
Clean and Re-compile the solution
The only thing that stood out to me in your source file is this part of the ISR declaration:
#pragma code InterruptVectorLow = 0x18
The user guide of the compiler you're using states this should be:
#pragma code low_vector=0x18
Since this declaration is just before your main function it might be giving you trouble.
Edit:
None of the presented solutions seem to work so I have just copy-pasted your code into a new MPLAB project, set up for the PIC18F46K20 device. It compiles just fine with the MCC18 compiler. The only thing that's missing from the project is the "12 CCP PWM.h" header file (which I do not have). So either there's something wrong with your header file, there's something wrong with your project setup, or the fact that I'm using MCC18 3.30 instead of 3.20 is the problem.
code compiles fine for me (C18 3.30 full)
i've had MPLAB flake out a bit on me especially on large source trees, many times a reboot has solved it, absolutely no idea why, tried everything else and it was the only way to get mplab to reset.
Personally I would not strain the corners of the implementation by having source file names with several spaces in, particularly with an embedded toolchain!
But it seems like they're making a reasonable effort to add all the double-quotes, so maybe that's not a real problem.
Do you actually have a 'main' function in your code, and if so, exactly how is it defined?
I use a third-party compiler, so I can't offer any specific experience on that. But one thing I may suspect is that something in the code is causing the compilation to stop partway through. This can be an unterminated comment, or a function with a closing brace missing. Consider especially the #included files, because you can't see the effects in your editor when you look at the main file, and particularly check any #includes that you have written yourself. And at the top of the list is, "what did you change last"?
What I do at this point is make a branch copy, and start mercilessly hacking out huge blocks of code, just to see when the error goes away. Divide and conquer. Of course, this can be time consuming, so I'd probably ask on StackOverflow, first :)
It's been a while, but I saw that you used a pragma to define the location of the interrupt handler before you created the function, might you need to do the same thing with main()?
It might be handled in the .h file - I'm not sure. I only ever used ASM on the PICs and I explicitly handled everything (ie, at 0x000 jump to main; at the interrupt vector address jump to this memory address; at main address do these things, etc). 'main' for me was defined to be an available address in the code section (which I see you've done, started the code section then defined main) but I believe I had to explicitly define that 'main' was to start at a memory address in the code section. Again, it was ASM, but I wouldn't doubt that you need to do something similar - a pragma to define main as main.
If c018i.o contains the reset vector, and it refers to the function main by name, then the issue could be that main needs a prototype - even in the same file as the function itself, so the linker can pick this up and put main in its list of functions.
So, try inserting:
void main (void);
immediately above the main function.