I am trying to put together a simple bootloader in the high end of the flash of an atmega8. The loader communicates with minicom via the XMODEM protocol, checks for errors, writes the corresponding flash pages and verifies them. All this is tested and working.
What is not working is executing the application after it has been flashed. I have 4 test cases.
If the input file is 1kB of 0x00 or 0x01 bytes, after cold reboot, program execution seems to start at the bootloader, although the BOOTSEL bit is set to start at flash address 0x0000 and the loader is at 0x1800.
If the input file is a binary file of an actual program, the chip hangs and no communication is possible. I have tried with a very simple and a quite complex applications, and the result is the same.
avr-gcc app.c -o app.out
avr-objcopy -j .text -j .data -O binary app.out app.bin # doesn't work
avr-objcopy -j .text -j .data -O ihex app.out app.hex # works via an isp
While both programs have been verified to work by uploading the
.hex file via an in system programmer, uploading the
.bin biles resuts in the explained hanging.
For example, here are the first several bytes of the very simple application:
00000000 12 c0 24 c0 23 c0 22 c0 21 c0 20 c0 1f c0 1e c0 |..$.#.".!. .....|
This is big-endian, being converted to small-endian by the bootloader. The opticode of an RJMP is
1100 kkkk kkkk kkkk where
k is an up to 2kB offset. Thus
12 c0 becomes
c0 12, which becomes
1100 0000 0001 0010. So the vector table is there.
What could be wrong? I am out of ideas. And my only debugging aids are
printf() over uart and blinking a led - no JTAG available. Where shall I investigate for the solution?