2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ If you have no live debugging capability, maybe you could try a simulator? \$\endgroup\$ – pjc50 Nov 3 '15 at 10:13
  • \$\begingroup\$ Does the bootloader expect the .bin or .hex format? I've no AVR experience but Freescale/Motorola bootloaders usually expect .s19 format which is human-readable ASCII with addresses and checksums rather than the raw binary data. Also check you're not trying to over-write the bootloader boot-block when writing the new code. This is possible if the bootloader either has no checking/protection, or the uploaded data tells it to write at the initial address. \$\endgroup\$ – John U Nov 3 '15 at 10:26
  • \$\begingroup\$ ...alternatively, can you buy a dev-board with debugging capability that has the same or very similar chip on it that would get you over this problem? \$\endgroup\$ – John U Nov 3 '15 at 10:27
  • \$\begingroup\$ @JohnU, the bootloader just takes bytes from the uart and writes them to flash. So it is expecting most definitely a binary, but possibly not the binary I am giving to it (btw ihex is also a human-readable ascii). I am checking for boot sector overrun. Concerning your second comment, this is a vary small project, but a sophisticated development board seems to be the last resort. \$\endgroup\$ – Vorac Nov 3 '15 at 13:07
  • 1
    \$\begingroup\$ Hmm. Add a "monitor" feature to your bootloader so it can dump the entire contents of the flash after writing, so you can check it? \$\endgroup\$ – pjc50 Nov 3 '15 at 13:31
1
\$\begingroup\$

In such low debug resource environment, every tool must be utilized. In my case, this was the in circuit programmer. I used it to download images of the flash.

 sudo avrdude -p atmega8 -c usbasp -U flash:r:file_name:r

Then using dhex any byte value differences became evident, leading to the conclusion that the flash programming fucntions from avr-libc expect unsigned chars and I am using signed chars.

Yey, my very first bootloader works.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.