[avr-gcc-list] memory layout for bootloader
Hi, i'd like to write a bootloader for an ATMega128 and some questions came up, it would be great if you could give me some hints. In avr-libc-usermanual-1.2.3 there is an example in the FAQ how to put a function into a certain section and how to put that section to a certain address. In that example the section .bootloader is used. I just made a small example and found in the map-/listing-file that a function marked with that attribute is put at that fixed address, but there are lots of other functions that are of course then not at that fixed address. To place a bootloader at a fixed address, isn't the preferred way to put section .text to a fixed address? Or are there some disadvantages in this way? I'm confused about the addresses. The ATMega has 128 kB of flash. It has a 16 bit PC. In the data sheet i read that the flash is organised in 64kB X 16 bits. When i set (BOOTSZ1:BOOTSZ0) to (0:0), do i set the the address of the bootloader to 0xF000 or 0x1e000? In the data sheet 0xF000 is used, in the avr-libc-usermanual 0x1E000 is used in the example. I guess i use 0x1E000, as 0xF000 seems to be based on 16 bits per address, is that correct? In the data sheet it is also mentioned that the assembler commands are either 2 or 4 bytes. What about the ATMega256, can the upper 128 kB only be used for data and not for an executable program? I assume that the ATMega128 can execute program in all its 128kB, is that correct? Can i really DISABLE SPI programming by fuse bit SPIEN? So if i set this one to 1 i have to program the chip in parallel mode again to enable it? This is not possible in an easy way on my board, this is a really dangerous thing, or do i misinterpret the data sheet? Best regards, Torsten. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memory layout for bootloader
Torsten Mohr wrote: Hi, i'd like to write a bootloader for an ATMega128 and some questions came up, it would be great if you could give me some hints. In avr-libc-usermanual-1.2.3 there is an example in the FAQ how to put a function into a certain section and how to put that section to a certain address. In that example the section .bootloader is used. I just made a small example and found in the map-/listing-file that a function marked with that attribute is put at that fixed address, but there are lots of other functions that are of course then not at that fixed address. To place a bootloader at a fixed address, isn't the preferred way to put section .text to a fixed address? Or are there some disadvantages in this way? No preference, just different designs. One way is to build an application with an integrated bootloader; that's what the example is hinting at. Some people, the bootloader *is* the application and they do move the .text section, and also move the interrupt vectors to the bootloader area. I'm confused about the addresses. Yes, they are confusing. The addresses in the datasheet are *word* addresses, so take that and multiply by two to get the *byte* addresses. Byte addresses are what is used throughout the entire GNU toolchain. I wish Atmel would change their datasheets, or at least put in a note to reflect this. In the data sheet it is also mentioned that the assembler commands are either 2 or 4 bytes. What about the ATMega256, can the upper 128 kB only be used for data and not for an executable program? Somehow I doubt it. I would think that you should be able to use all of it for code. Because this device is so new, the best thing to do would be to check the datasheet or ask Atmel directly about this. I assume that the ATMega128 can execute program in all its 128kB, is that correct? Yes, that is correct. Can i really DISABLE SPI programming by fuse bit SPIEN? Sorry, I don't know about this one. HTH Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memory layout for bootloader
Hello, if you want to place other functions in the bootloader memory add the attribute to these functions as well. Ideally one must set the address of .text to boot address, as bootloader is a completely independent program. I tested by putting the .text in the bootloader section and it worked fine. Or are there some disadvantages in this way? I found one disadvantage or rather I am looking for a solution. If one creates a complete program including the main function and put .text in the bootloader memory, the startup code, the interrupt vector table and ofcourse the cleanup code are also added to the binary/hex image. If one is not using any interrupts in the bootloader, why waste this memory? similarly why occupy some more memory for cleanup as this may never be used? I found this to be a disadvantage. How does one avoid putting interrupt table and cleanup code in the bootloader section? (this is what I am looking for) I guess i use 0x1E000, as 0xF000 seems to be based on 16 bits per address, is that correct? The data sheets talk about word address so you need to get the byte address by shifting the bootloader address , mentioned in the docs, left by 1 I assume that the ATMega128 can execute program in all its 128kB, is that correct? Yes. Can i really DISABLE SPI programming by fuse bit SPIEN? Never tired this. Regards Nayani P __ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] memory layout for bootloader
Torsten Mohr [EMAIL PROTECTED] wrote: Can i really DISABLE SPI programming by fuse bit SPIEN? You can. But read the text carefully: you cannot do that while using ISP programming. ;-) So it's not a shoot-into-your-foot (SIYF) fuse. The only real SIYF fuse they ever invented is the reset disable fuse on the ATmega8. There are semi-SIYF fuses when you select a clock option that will result in the device no longer being clocked, but you can usually always resurrect them by supplying an external clock. Some people who don't even own a simple pulse generator occasionally even program a second AVR for that purpose, and use that one's clock output as clock supply for the device to resurrect. ;-) On the debugWire-capable devices, the DWEN fuse is most likely also a semi-SIYF fuse: debugWire uses a kind of 1-wire protocol across the /RESET-pin, so this pin no longer works as a normal reset. The only way back then is to use a JTAG ICE mkII, and talk debugWire across it in order to turn it off again. Hmm, perhaps we could persuade Atmel to at least publish a bit sequence you need on dW that will resurrect an indadvertently programmed DWEN fuse without a JTAG ICE... -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
