Help me debug: flash programming successful and verified; program does not run

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Being reluctant to add 5 new wires to my PCB for in system programming, I decided to run a bootloader through the alrady established uart connection. Looking through the numerous loaders in the public domain, however, I did not like anyone for some of the reasons:

 

- do not run out of the box for my environment (ubuntu+gcc+atmega8)

- copyleft license

- bloated

 

And since putting up one on my own seems to include just copying avr-libc library examples, I decided to roll my own. Here is the question:

 

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?

 

PS: I read this: https://www.avrfreaks.net/sites/d...

Twice. It helped solve many of my previous problems. And I am violating #9, I know.

This topic has a solution.
Last Edited: Tue. Nov 10, 2015 - 04:39 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two questions come to mind.

 

A) Does the boot loader faithfully copy the entire '.bin' file? Use avrdude to read the boot-loaded application from your avr, and compare what was read with what was written.

 

B) Does the application expect the avr to be in reset condition, when the boot loader has modified some registers? Obviously the USART registers have been 'tampered with' by the boot loader. It is best for a boot loader to restore any registers used to the reset condition. Remember that this includes the stack pointer, status register, control register... If possible, use the Watchdog to force a hardware reset, ensuring that everything is in the pristine reset condition.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey, mikericetga

 

I received the same advice from a friend. The issue is fixed. Here are the details:

 

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

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

Then using dhex 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.