| Author |
Message |
|
|
Posted: Mar 20, 2009 - 07:06 AM |
|

Joined: Dec 22, 2008
Posts: 14
|
|
@jl_1978,
I have faced the same problem,"bootloader section overlaps bss". I could use avrxmega5.x linker script to move bootloader and other sections to exact locations I wanted.
Also, I have edited the hex file to remove the metadata.
Is it raw transmission or any protocol like kermit etc employed ( from PC to xmega)? |
|
|
| |
|
|
|
|
|
Posted: Aug 12, 2009 - 08:50 AM |
|

Joined: Mar 09, 2005
Posts: 63
|
|
Hi all.
I could not get the AVR1316 nor the AVR1605 app notes to compile properly for the ATXMEGA128A1 and for the correct bootloader location with AVR Studio 4.16b638. So here is what I did to get them going.
1. Use the file sp_driver.S for the GCC compiler. It was late at night and I made the mistake of trying the sp_driver.S90 file and stupidly tried to hack everything to get it to compile and only when I looked back at the source folder did I see the .S file I needed. By the way the AVR1316 tells you to use the .S file for GCC but it is in the readme.htm notes and not anywhere else. It would have been nice for the AVR1605 to have this note as well, the source for AVR1605 does not even cater for the GCC compiler!
Note: You must copy the sp_driver.S file from the AVR1316 app note source code to be used in the AVR1605 project if GCC is to be used
2. I edited the lines in the source code that needed the FLASH_PAGE_SIZE was set to 512. This was commented out by the author and an error message gets displayed instead. You can just comment out the error message and uncomment the 512 page size. You will pick up this error when compiling, so not to worry if you did not change all occurrences.
3. Create a project with AVR Studio and include all source files in the project.
4. Go to the Project options screen and set the CPU clock and device to 2000000Hz and ATXMega128A1 respectively. Other settings are fine at their default.
5. In the Project options window, click on the Memory settings option and add an entry which is : Memory Type = Flash, Name = .text, Address = 0x10000. This will make sure the code gets compiled and located at the boot sector which is 0x10000. Note this is 0x-ten thousand!
5a. In the Project options window, click on the Memory settings option and add an entry which is : Memory Type = Flash, Name = .BOOT, Address = 0x10800.
6. Flash the resulting Hex file (should be located at 0x10000 onward)
7. Set the fuse of ATXMEGA128A1 for correct booting, i.e. BOOTRST = Boot Loader Reset.
8. Reset the hardware while holding down the Prog pin.
9. Use your favourite serial port terminal prog (Realterm (http://realterm.sourceforge.net) is my favourite) and set the params to 9600bps 8N1, to test. Send a capital "S" (no quotes) and
you should receive a response of "AVRBOOT" from the boot loader code.
The above has been tested using the STK600 with ATXMEGA128A1 and the flash was programmed and read back to make sure the code did reside at location 0x10000 in the boot section.
Note I am still not able to successfully program an ATXMEGA128A1 using the SPM instruction and I think it must be because of the Rev of the chip I have. Hopefully I will have this fixed soon.
Best regards
Priyend
c/o Vardaan Enterprises - Embedded Electronic Engineering - South Africa
http://www.vardaan.com |
Last edited by priyend on Aug 13, 2009 - 09:53 AM; edited 2 times in total
|
| |
|
|
|
|
|
Posted: Aug 12, 2009 - 01:44 PM |
|


Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh
|
|
|
priyend wrote:
Note I am still not able to successfully program an ATXMEGA128A1 using the SPM instruction and I think it must be because of the Rev of the chip I have. Hopefully I will have this fixed soon.
This will tell let you read the XMega Rev:
Code:
/* Change hex8() to match what your hardware needs to display a byte */
#define hex8(x) do{ /* display byte here */ }while(0)
/* Read the part signature and revision: */
hex8( MCU.DEVID0 ); hex8( MCU.DEVID1 ); hex8( MCU.DEVID2 );
hex8( (uint8_t) (MCU.REVID+'A') );
Most things in RevH work, if your Rev is before that,
replace the chip. |
|
|
| |
|
|
|
|
|
Posted: Aug 12, 2009 - 09:34 PM |
|

Joined: Mar 09, 2005
Posts: 63
|
|
Thanks bpaddock. I checked the Rev of my chips and they are all REV H.
Now I am having trouble.
I can easily enter the bootloader app. I can erase my chip in the app area (checked by programming some app using PDI and then issuing the erase command using AVROSP).
I can read back the contents of my device and it is correct. Again tested by preprogramming some known code using PDI and then reading back using AVROSP.
But I cannot program the device at all using AVROSP. I always get and error "Unequal at address 0x0!".
I have checked that the code being flashed using AVROSP works using the PDI method. I have also made sure the Lock bits are set to "Write not allowed" in the boot section (BLBB) to prevent accidental erase of the bootloader itself.
Anyone have ideas why the AVR1605 code will not program an app but PDI does it properly?
Best regards
Priyend |
|
|
| |
|
|
|
|
|
Posted: Aug 13, 2009 - 09:49 AM |
|

Joined: Mar 09, 2005
Posts: 63
|
|
Really weird issue!
I can now program all my ATXMEGA128A1's without any change to my recompiled AVR1605.
I have not changed anything in the code or compiler settings nor the fuse settings. Suddenly it just started working.
I have a feeling my problems have something to do with Micro$oft Window$.
On another note...
There is one change I have added to step 5 above :
Quote:
5. In the Project options window, click on the Memory settings option and add an entry (no quotes) which is : Memory Type = Flash, Name = .text, Address = 0x10000. This will make sure the code gets compiled and located at the boot sector which is 0x10000. Note this is 0x-ten thousand!
One needs to add another section for .BOOT and set it to 0x10800.
This edit has been made and put in as 5a above.
Best regards
Priyend |
|
|
| |
|
|
|
|
|
Posted: Aug 15, 2009 - 04:44 PM |
|

Joined: Mar 09, 2005
Posts: 63
|
|
I have now fixed the "Really weird issue!".
It was a silly mistake I was making.
Each time I flashed the bootloader code, the CPU reset itself and did this in a continuous loop. I then simply pressed the "Enter Bootloader" switch (SW0->PD4) to enter the bootloader which it correctly did so.
I am then able to read, erase chip etc, but not write to flash memory. This is probably because the state of the MCU registers are unknown due to the continuous reset loops. This is BAD!
When I correctly run the sequence to enter the bootloader which is press the "Enter Bootloader" switch (SW0->PD4) and THEN power on. This will set the registers to the power up and wit known default values then all works correctly.
I hope this helps others.
Best regards
Priyend |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 08:41 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
Hi everyone,
I've been trying to make this bootloader work, but for some reasons it doesn't. I'm rather new with the Atmega microcontrollers though.
Here's what I've done so far :
I use the STK600 kit with an XMEGA128A1.
- I conntected PD2 and PD3 to RXD and TXD respectively
- I connected SW0 to PD4 as mentioned in the AVR1605 application note
- I created a project with the configuration suggested by Priyend.
- I set the fuse to BOOTRST = BOot loader reset
- I programmed the .hex file by using the STK600 programmer (embedded in the STK600 board), as I usually do.
The only thing, is that I don't have the JtagIce mk II.
Is there anything that I'm not doing or not doing properly?
Is there any unwritten "gotchas" that I should watch for?
I use sp_driver.S and no sp_driver.S90 since i'm using gcc.
Best regards.
Benjamin |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:07 PM |
|

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia
|
|
|
Survenant wrote:
Hi everyone,
I've been trying to make this bootloader work, but for some reasons it doesn't. I'm rather new with the Atmega microcontrollers though.
Here's what I've done so far :
I use the STK600 kit with an XMEGA128A1.
- I conntected PD2 and PD3 to RXD and TXD respectively
- I connected SW0 to PD4 as mentioned in the AVR1605 application note
- I created a project with the configuration suggested by Priyend.
- I set the fuse to BOOTRST = BOot loader reset
- I programmed the .hex file by using the STK600 programmer (embedded in the STK600 board), as I usually do.
The only thing, is that I don't have the JtagIce mk II.
Is there anything that I'm not doing or not doing properly?
Is there any unwritten "gotchas" that I should watch for?
I use sp_driver.S and no sp_driver.S90 since i'm using gcc.
Best regards.
Benjamin
I'm assuming you've seen this thread: http://www.avrfreaks.net/index.php?name ... mp;t=79592
Can you post what sort of errors or specific problem you're describing?
-- Damien |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:12 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
Yes later on, I saw this thread and I triedthe gcc project.
Even then, I obtained the same results... i.e. nothing.
It's like the board isn't even programmed. I tried modifying the code to toggle a led, but that doesn't work either. Like I said in another thread, when I try to do a readback, the programmer only reads the application section, therefore I have no way of knowing whether or not the bootloader section has been modified.
One thing that I've noticed is that APP1605 uses the JTAG debugger while I'm using the STK600 internal programmer to program the bootloader section of the XMEGA128A1.
That would be strange, but with the debugger I could verify more easily whether the bootloader section has changed or not.
Thanks
Benjamin |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:17 PM |
|

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia
|
|
|
Survenant wrote:
Yes later on, I saw this thread and I triedthe gcc project.
Even then, I obtained the same results... i.e. nothing.
It's like the board isn't even programmed. I tried modifying the code to toggle a led, but that doesn't work either. Like I said in another thread, when I try to do a readback, the programmer only reads the application section, therefore I have no way of knowing whether or not the bootloader section has been modified.
One thing that I've noticed is that APP1605 uses the JTAG debugger while I'm using the STK600 internal programmer to program the bootloader section of the XMEGA128A1.
That would be strange, but with the debugger I could verify more easily whether the bootloader section has changed or not.
Thanks
Benjamin
An idea to test... a normal program can use the bootloader space if there is no bootloader there. Perhaps declare a constant variable at that location in ROM and see if you can access it from a normal program.
-- Damien |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:21 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
That might sound like a stupid question, but how can I specify the address of a variable? I'm using gcc.
Thanks for the idea by the way.
Benjamin |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:32 PM |
|

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia
|
|
|
|
|
|
|
Posted: Oct 20, 2009 - 11:46 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
Follow-up
I downloaded AVR studio 4.17 (I used 4.16) the latest version and now I can read the boot loader section.
It's not working yet, but at least I see that the data was properly written in the bootloader section.
Thanks Damien for your help. |
|
|
| |
|
|
|
|
|
Posted: Oct 20, 2009 - 11:49 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
Follow-up :
My last mistake was not connecting the serial port properly.
It works now, I receive "AVRBOOT" everytime I write "S" in the serial port console.
Basically, the issue was that AVRStudio 4.16 didn't support properly the bootloader section of the XMEGAs when using either AVRISP mkII or STK600.
AVRStudio 4.17 works fine. |
|
|
| |
|
|
|
|
|
Posted: Oct 21, 2009 - 04:05 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
I've got another question.
I'm able to program a custom bootloader program.
Basically this bootloader flashes a led until the user presses SW0 on the STK600.
When SW0 is pressed, the program will go to 0x00000
Code:
void (*funcptr)( void ) = 0x0000;
while (1) {
if( !(PORTD.IN & _BV(4)) ) {
funcptr();
}
cnt++;
if (cnt == 0) {
light_led(7);
}
else if (cnt == 32768) {
shut_led(7);
}
}
When I press SW0 I see that the led stops flashing, however the "regular" application doesn't start, because after I remove my finger from SW0 I return in the bootloader.
I programmed the bootloader with AVRISP mkII.
Afterwards, I opened another project, I erased the application section and I programmed the application without erasing the flash (because I only deleted the application section before).
The fuse is set to bootloader reset, not application reset.
Do you guys have any ideas? Is there something I'm not doing right?
Best regards
Benjamin |
|
|
| |
|
|
|
|
|
Posted: Oct 21, 2009 - 04:18 PM |
|

Joined: Oct 05, 2009
Posts: 42
Location: Quebec, Quebec
|
|
I'm sorry for bothering, looks like I did a newbie mistake. I forgot 3 lines of code before calling funcptr();
Now it works.
Code:
while (1) {
if( !(PORTD.IN & _BV(4)) ) {
SP_WaitForSPM();
SP_LockSPM();
EIND = 0x00;
funcptr();
}
cnt++;
if (cnt == 0) {
light_led(7);
}
else if (cnt == 32768) {
shut_led(7);
}
}
|
|
|
| |
|
|
|
|
|
Posted: Jun 30, 2010 - 05:54 PM |
|

Joined: Jun 23, 2010
Posts: 15
|
|
I am having a problem with jumping back to 0x00000.
I am running a boot loader that reads in a hex file and programs application space in FLASH. I have checked to ensure that my FLASH is consistent with what I programmed it with. After I have written everything to FLASH I execute
Code:
asm("jmp 0"::);
When I single step through with the disassembler I see that it goes back to address 0x00000, but it doesn't start the program in application space.
What am I missing? |
|
|
| |
|
|
|
|
|
Posted: Jul 01, 2010 - 11:13 AM |
|


Joined: Jul 18, 2005
Posts: 62246
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
but it doesn't start the program in application space
But surely location 0x0000 holds an (R)JMP that crosses the vector table and enters the C pre-amble of the app code. Are you saying that the debugger is not showing an (R)JMP opcode at 0x0000? If so it sounds like the bootloader failed to program the app space (at 0x0000 at least) or you have forgotten to re-enable the RWW section. |
_________________
|
| |
|
|
|
|
|
Posted: Jul 01, 2010 - 02:33 PM |
|

Joined: Jun 23, 2010
Posts: 15
|
|
|
clawson wrote:
But surely location 0x0000 holds an (R)JMP that crosses the vector table and enters the C pre-amble of the app code. Are you saying that the debugger is not showing an (R)JMP opcode at 0x0000? If so it sounds like the bootloader failed to program the app space (at 0x0000 at least) or you have forgotten to re-enable the RWW section.
The debugger goes to address 0x0000, at that address I see the vector table and does the C pre-amble app code. The jmp command is there at 0x0000.
Code:
SP_WaitForSPM();
SP_LockSPM();
EIND = 0;
asm("jmp 0"::);
That is the code I am using to jump back to 0x0000.
When I used the Watchdog Timer, it executed the program that I loaded in the application space. So does that mean that I missed a step when I attempt to do a straight jmp command? |
|
|
| |
|
|
|
|
|
Posted: Jul 01, 2010 - 02:52 PM |
|


Joined: Jul 18, 2005
Posts: 62246
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
The jmp command is there at 0x0000
So what's the problem. You said:
Quote:
I see that it goes back to address 0x00000, but it doesn't start the program
If it gets to 0x0000 and there's a JMP there then how could it possibly fail to execute it? Are you saying that if you single step the JMP it doesn't then jump over the vector table to the start of the C pre-amble. That surely could only occur if the JMP was actually a "JMP 0x0000" so just keeps jumping back to itself? So what is the offset of the JMP shown in the disassembler? |
_________________
|
| |
|
|
|
|
|