[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[avr-chat] issues with custom bootloader and ATMega32
From: |
Alexander Krause |
Subject: |
[avr-chat] issues with custom bootloader and ATMega32 |
Date: |
Tue, 29 Oct 2013 13:46:13 +0100 |
Hi all,
I started to write a bootloader for RS485/ModBus and am stuck for quite
a while now.
In general I've three issues.
First of all, it seems like my IRQ's are not working when I put the code
into the boot section.
I've choosen 2048 bytes bootsize, which will start at byte address
0x3800 equals word address 0x1C00 .
Fuses are:
MCU_LFUSE=0xBE
MCU_HFUSE=0xD0
My program starts like this:
int __attribute__((noreturn)) main(void) {
MCUCR = (1 << IVCE);
MCUCR = (1 << IVSEL);
...
So that should work, but It doesn't :-(
Well, since I've to shorten my code as far as possible I simply decided
to use polling instead of IRQs (saves me the cli, sbi and some other
things ~100bytes less code).
This raises the question if I can short the bootloaders interrupt table
somehow? At the moment it looks like this:
1c00: 4f c0 rjmp .+158 ; 0x1ca0 <__ctors_end>
1c02: 00 00 nop
1c04: 5d c0 rjmp .+186 ; 0x1cc0
<__bad_interrupt>
1c06: 00 00 nop
1c08: 5b c0 rjmp .+182 ; 0x1cc0
<__bad_interrupt>
1c0a: 00 00 nop
1c0c: 59 c0 rjmp .+178 ; 0x1cc0
<__bad_interrupt>
1c0e: 00 00 nop
1c10: 57 c0 rjmp .+174 ; 0x1cc0
<__bad_interrupt>
1c12: 00 00 nop
1c14: 55 c0 rjmp .+170 ; 0x1cc0
<__bad_interrupt>
1c16: 00 00 nop
1c18: 53 c0 rjmp .+166 ; 0x1cc0
<__bad_interrupt>
1c1a: 00 00 nop
1c1c: 51 c0 rjmp .+162 ; 0x1cc0
<__bad_interrupt>
1c1e: 00 00 nop
1c20: 4f c0 rjmp .+158 ; 0x1cc0
<__bad_interrupt>
1c22: 00 00 nop
1c24: 4d c0 rjmp .+154 ; 0x1cc0
<__bad_interrupt>
1c26: 00 00 nop
1c28: 4b c0 rjmp .+150 ; 0x1cc0
<__bad_interrupt>
1c2a: 00 00 nop
1c2c: 49 c0 rjmp .+146 ; 0x1cc0
<__bad_interrupt>
1c2e: 00 00 nop
1c30: 47 c0 rjmp .+142 ; 0x1cc0
<__bad_interrupt>
1c32: 00 00 nop
1c34: 45 c0 rjmp .+138 ; 0x1cc0
<__bad_interrupt>
1c36: 00 00 nop
1c38: 43 c0 rjmp .+134 ; 0x1cc0
<__bad_interrupt>
1c3a: 00 00 nop
1c3c: 41 c0 rjmp .+130 ; 0x1cc0
<__bad_interrupt>
1c3e: 00 00 nop
1c40: 3f c0 rjmp .+126 ; 0x1cc0
<__bad_interrupt>
1c42: 00 00 nop
1c44: 3d c0 rjmp .+122 ; 0x1cc0
<__bad_interrupt>
1c46: 00 00 nop
1c48: 3b c0 rjmp .+118 ; 0x1cc0
<__bad_interrupt>
1c4a: 00 00 nop
1c4c: 39 c0 rjmp .+114 ; 0x1cc0
<__bad_interrupt>
1c4e: 00 00 nop
1c50: 37 c0 rjmp .+110 ; 0x1cc0
<__bad_interrupt>
Can't I simply tell GCC to not use/generate such a table since there'll
be no IRQ anyway.
The last and biggest issue is that I'm not able to write via the SPM
features.
I tried this with a minimalistic piece of code:
void spm_write_page(uint32_t page) {
uint8_t i;
eeprom_busy_wait();
boot_page_erase(page);
boot_spm_busy_wait(); // Wait until the memory is erased.
for (i=0; i<SPM_PAGESIZE; i+=2) {
boot_page_fill(page + i, i);
}
boot_page_write(page); // Store buffer in flash page.
boot_spm_busy_wait(); // Wait until the memory is written.
// Reenable RWW-section again. We need this if we want to jump back
// to the application after bootloading.
boot_rww_enable();
}
int __attribute__((noreturn)) main(void) {
spm_write_page(1);
while(1);
}
However, when I dump my Flash there is no valid data in the first page:
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0001c00 c04f 0000 c05d 0000 c05b 0000 c059 0000
0001c10 c057 0000 c055 0000 c053 0000 c051 0000
0001c20 c04f 0000 c04d 0000 c04b 0000 c049 0000
0001c30 c047 0000 c045 0000 c043 0000 c041 0000
0001c40 c03f 0000 c03d 0000 c03b 0000 c039 0000
Thanks a lot for reading. I'd be very grateful for any help.
Regards,
Alex