View topic - how to set the functions in sp_driver.S inside boot section?

Search

how to set the functions in sp_driver.S inside boot section?

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

Author

Message

TomQi

Posted: Sep 23, 2011 - 12:33 AM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

Dear all

,
I am currently working on XMEGA32A4 using AVR Studio 4 and WinAVR. I had set .boot_sp section at word address 0x4100 (0x8200)using Project->configuration options->memory settings.
And I used ".section .boot_sp" replace of ".section .text" in sp_driver.S for some functions e.g. SP_ReadByte.
After built, I saw in the .map file:
.boot_sp 0x00008200 0xc
.boot_sp 0x00008200 0xc sp_driver.o
0x00008200 SP_ReadByte

But I could not find SP_ReadByte function in the .lss file.

And I could not find any code in the address starting at 0x8200 in .hex file:
:1080D00080E090E00E9474251CBEE0E0F0E009958D
:0E80E000DF91CF911F910F91FF90EF900895C7
:10840000CF93DF93DC01EC01CB5FDE4F8881AA5F65
:10841000BE4F9C91A650B14020E08F5F8F778917A7

Could you help for this issue?
Thank you in advance.

Regards, Tom

damien_d

Posted: Sep 23, 2011 - 04:25 AM

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia

I simply moved the .text to the boot section. You can see the example code here.

Give this a go and see what happens.

-- Damien

TomQi

Posted: Sep 23, 2011 - 05:25 AM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

damien_d wrote:

I simply moved the .text to the boot section. You can see the example code here.

Give this a go and see what happens.

-- Damien

Thank you Damien,
I would like to show more details to indecate where is my issue:
I had 4 sections need to be at "boot section" and they are showed in .map file as:

.boot_loader 0x00008000 0xee
.boot_loader 0x00008000 0xee bootloader.o
0x00008000 bootloader

.boot_sp 0x00008200 0xc
.boot_sp 0x00008200 0xc sp_driver.o
0x00008200 SP_ReadByte

.boot_uart 0x00008400 0x52
.boot_uart 0x00008400 0x52 usart_driver.o
0x00008400 USART_TXBuffer_PutByte

.boot_i2c 0x00008600 0xa8
.boot_i2c 0x00008600 0xa8 twi_master_driver.o
0x00008600 TWI_Read_Ext_EEPROM
0x0000867c EXTRAM_Read_Byte

However, the .hex file showed:

:105E240008080808080808080808080808080808EE
:10800000EF92FF920F931F93CF93DF938AEB96E249
:108010006DE00E9400428AEB96E26AE00E94004214
:108020008AEB96E262E40E9400428AEB96E26FE4F9
:108030000E9400428AEB96E26FE40E9400428AEBC3
:1080400096E264E50E9400428AEB96E261E20E94B9
:1080500000428AEB96E26DE00E9400428AEB96E2D3
:108060006AE00E94004288E893E10197F1F780E31B
:10807000E82EF12C012D112DC8E8D3E1C801B7017C
:108080000E940041682F8AEB96E20E940042CE01D6
:108090000197F1F70894E11CF11C011D111D80E30B
:1080A000E81688E0F80680E0080780E0180731F756
:1080B00088E893E10197F1F78AEB96E261E40E9488
:1080C00000428AEB96E262E40E94004260E070E8BF
:1080D00080E090E00E9474251CBEE0E0F0E009958D
:0E80E000DF91CF911F910F91FF90EF900895C7
:10840000CF93DF93DC01EC01CB5FDE4F8881AA5F65
:10841000BE4F9C91A650B14020E08F5F8F778917A7
:10842000A1F021E08881FD01E80FF11DED57FF4F1C
:1084300060838F5F8F778883ED91FC9111978381A3
:108440008C7F12969C91892B8383822FDF91CF9111
:0284500008958D
:108600000F93DC0157968C915797882311F080E0E7
:1086100033C081E057968C93579758961C92589781
:10862000660F660F12966C93129714963C931497EC
:1086300013962C93139782E053968C9353975496EA
:108640000C93549755961C92559756961C92569794
:1086500012968C9112978E7FED91FC9111978683E3
:1086600084EC99E00197F1F712968C911297816052
:10867000ED91FC91868381E00F9108950F939C0109
:1086800081E080932C2B84E49AE268E240E001E0F0
:108690000E94004380915B2A8823E1F710922C2BE3
:0886A00080914F2A0F9108950B
:00000001FF

Above .hex means I can see .boot_loader, .boot_uart, and .boot_i2c in the boot section but .boot_sp is not there.

I realized that .boot_sp is in Asembly and others are in C...

In C, e.g. I have #define BOOT_SECTION __attribute((section(".boot_loader")))

and then
void bootloader(void) BOOT_SECTION;

in Asembly , I directly have in sp_driver.S file:
.section .boot_sp
.global SP_ReadByte

SP_ReadByte:
in r19, RAMPZ ; Save RAMPZ.
out RAMPZ, r24 ; Load RAMPZ with the MSB of the address.
movw ZL, r22 ; Move the low bytes to the Z pointer
elpm r24, Z ; Extended load byte from address pointed to by Z.
out RAMPZ, r19 ; Restore RAMPZ register.
ret

Could you please have an advice?

Regards, Tom

clawson

Posted: Sep 23, 2011 - 09:40 AM

Joined: Jul 18, 2005
Posts: 62941
Location: (using avr-gcc in) Finchingfield, Essex, England

Are you writing a bootloader or an app that does SPM?

_________________

TomQi

Posted: Sep 25, 2011 - 03:48 AM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

clawson wrote:

Are you writing a bootloader or an app that does SPM?

At the application, I can receive an "restore default frinmware version" request.
When "restore default frinmware versionon" required from an USART in the application section, I will jump to boot section and rewrite the application section using the code restored in an external EEPROM (via TWI). therefore, I need the sp_driver.S and the TWI_driver.c and USART_driver.c to stay at boot section.
Of course the bootloader is also in the boot section.
Could you have some advices on why the sp_driver.S did not appear at the boot section after the project is built?

TomQi

Posted: Oct 03, 2011 - 12:00 AM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

TomQi wrote:

clawson wrote:

Are you writing a bootloader or an app that does SPM?

In fact, I would like to build the applcation and bootloader together to create a .hex file (it was not successful).
If I built the bootloader with sp_driver.S and TWI_driver.c and USART_driver.c, I had a seperated .hex file for boot section.
Then I had built a seperated applcation .hex file.
When I tried to build the applcation and bootloader together, the sp_driver.S had an issue as above discussion...

clawson

Posted: Oct 03, 2011 - 09:07 AM

Joined: Jul 18, 2005
Posts: 62941
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

When I tried to build the applcation and bootloader together, the sp_driver.S had an issue as above discussion...

Don't build them together.

You build the application, it generates a .hex (let's call it app.hex)
You build the bootloader, it generates a .hex (let's call it boot.hex)
You now join the two .hex files to make an all.hex, you can join them using srec_cat or for a very simple method simply use the DOS command "copy app.hex+boot.hex all.hex" and, having done that open all.hex in a text editor and locate the termination record between the two files and remove it (but leave the one on the last line).
Now program all.hex into the AVR.

_________________

damien_d

Posted: Oct 03, 2011 - 09:21 AM

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia

TomQi wrote:

When I tried to build the applcation and bootloader together, the sp_driver.S had an issue as above discussion...

Whilst I understand that it doesn't quite answer your question about compiling them at once, you're much better off taking Cliff's suggestion to compile separately and combine using srec_cat.

The reason is that the C environment is only setup once. This is a real problem if you bootload a new app that has global variables.

In Version 1.0, imagine you have the following:

Code:

uint8_t old_data = 2;

uint8_t other_data = 6;

Now, assuming you have the reset vector pointing to bootloader space, these global variables will be initialised by code in the bootloader section.

If this gets changed to:

Code:

uint8_t old_data = 2;

uint8_t new_Data = 3;

uint8_t other_data = 6;

And then bootloaded into the AVR, then the order of initialisation gets all messed up and has lots of wrong values all over the place, since the variables will be populated with the old global initialisation.

I got burned by this in a big way when I tried combining the two - it caused a support nightmare (it caused a nasty effect that was only triggered during an unusual condition) and took 3 weeks to find and fix.

So please, take Cliff's advice and build separately unless you *really really really** need to build those routines into your application.

-- Damien

clawson

Posted: Oct 03, 2011 - 09:33 AM

Joined: Jul 18, 2005
Posts: 62941
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

unless you *really really really** need to build those routines into your application.

But in that case share them with a dispatch table in the bootloader.

_________________

TomQi

Posted: Oct 03, 2011 - 10:26 PM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

Thank you.
yes, it is one of the reasons I would like to build them together.
More importantly, if I build them seperatly, there will be some duplicated files in both application section and boot section e.g. I will need a TWI driver in application section and the same driver in boot section.
If we build them together, we can share the TWI driver.

TomQi

Posted: Oct 03, 2011 - 10:28 PM

Joined: Mar 01, 2011
Posts: 6
Location: Auckland

clawson wrote:

Quote:

unless you *really really really** need to build those routines into your application.

But in that case share them with a dispatch table in the bootloader.

Yes, it is a good idea

Jump to:

All times are GMT + 1 Hour

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

AVRFreaks.net

Search