[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: bootloader / flash coding / avr

From: Reza Naima
Subject: [avr-gcc-list] Re: bootloader / flash coding / avr
Date: Thu, 22 May 2003 14:27:27 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

1. I would seriously consider NOT licensing it under GPL unless you have to. 
The BSD license is
less restrictive, and that way other people can use it freely in commercial 
products without
having to give away other parts of their code.

Sounds good to me.

2. All the functions that are called in your bootloader() need to have 
after their prototypes. This means you need to write prototypes for TxChar, 
RxChar, flushUSB.
Also, any variables that are needed for the bootloader, also need to placed 
BOOTLOADER_SECTION, such as usb_boot_dev. Everything in the bootloader must be 
and put into the "bootloader memory" (NRWW); you shouldn't make any calls that 
reference the RWW
memory that you're trying to modify. Sorry that this really isn't documented 
anywhere yet.

I considered this. The functions were originally declared 'static inline', but to be on the safe side, I also tried making them macros or coping the code directly into the bootloader function. With regards to the variable declaged global (usb_boot_dev), it's a pointer to the externally mapped memory, which is how I talk to the USB device. Someone else posted about making this an 'auto' variable -- I'm not sure what that entails exactly. I'm wondering if this is the problem I'm having.. Any thoughts?

3. sbi will be deprecated soon. Use direct access instead: MCUCR |= SRE; As 
long as you have
optimization turned on, GCC will generate the correct instructions.

Good to know, thnx. I was reading somwhere that bitwise operations seen to be cast, or else the compiler casts themt to 16 bit values. Would it be true with the above? Should I do MCUCR |= (unsigned char) SRE; instead, or does it not apply here?

4. boot_mem_read() will not be a part of the final bootloader support API. 
There is a new
pgmspace.h API in the avr-libc CVS that provides better read functionality. 
Replace it with

I noticed pgm_read_byte in your demo code. It took me a bit to realize it's in CVS now. I'll wait till the code gets pushed out to an rpm, then I'll change.

5. Try testing just writing to the flash first, without doing the 
communications, using some
test data and getting just that part working. Then adding the comms stuff. I 
have gotten a
bootloader working at 0x1E000 with a mega128.

Well, I thought doing the communication would be easier. I'm still wondering about the stack. If that function lives in 0x1E000 only, then on a reset, the stack/etc.. are not initialized. Will the function still work? Also, why does it fail to work when I just relocate the function to, say, 0x500 (when called as a function)? One last question, A friend suggested using the NORETURN attribute to optimze the code (so it will not save the registers from the calling function), yet it didn't do anything. Does the back-end of gcc ignore this?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]