Re: [AVaRICE-user] Avarice and Self-programming

[Theodore A. R. <tr...@op...>]

On Fri, 27 Aug 2004, Roy Shea wrote:

> > Do you get the same results when you try debugging a "regular" program?
>
> The JTAG works fine with regular programs.  Only when I work on programs
> placed in the BLS is this a problem.  On a side note, without the JTAG
> I can run programs from the BLS without problems.

I assume that you have all the lock bit cleared from your previously
supplied output. The data sheet says that on-chip debugging is disabled
if any lock bit is set.

Next test: write a regular program with a special function that is
located in the BLS. See if you can debug and step into that function.

>
> > > Enabling on-chip debugging:
> > > jtagRead
> > > command[R, 1]: 52 B2 02 00 00 00 20 20
> > > response: FF 18 FE 00 41
> > >   Extended Fuse byte -> 0xfe
> > >       High Fuse byte -> 0x18
> > >        Low Fuse byte -> 0xff
> >
> > It appears that you have the device fused into mega103 compatability
> > mode. You should set the extended byte to 0xff if you don't what comp
> > mode on.
>
> Hmm...  Are you sure on this?  I thought mega103 compatibility mode is
> controlled with bit 1 (not bit zero) with a value of zero being programmed.
> Enabled values would thus be 0xfd or 0xfc.  I am pretty sure that the zero
> bit enables a watchdog timer, which I want turned on.

You are right. I am just too used to seeing 0xff there since I never use
the watchdog timer and have seen many people that didn't realize that
Atmel ships these parts with the M103 bit set. Brain fart on my part.
Sorry.

>
> > Since you appear to have changed the fuses, are you sure that you have
> > the correct clock source?
>
> Yeah, these also seem correct.  7.37 MHz crystal and going with a slow
> rising power.  But it is always good to double check!
>
> So I am still stumbling.  Perhaps my placement of sections in memory does
> not work with avarice?  Here are the final steps of my build:
>
> --------- building app -----------
> avr-gcc blank.o a.o b.o c.o b.o -mmcu=atmega128 -Wl,-Map=blank.map,--cref
> -Wl,--section-start=.text=0x1e000 -Wl,--section-start=.xos_dev=0x19000 -o
> blank.elf
>
> avr-size -A blank.elf
> blank.elf  :
> section     size      addr
> .data        104   8388864
> .text       6396    122880
> .xos_dev   14922    102400
> .bss        2812   8388968
> .noinit        0   8391780
> .eeprom        0   8454144
> .stab        996         0
> .stabstr     142         0
> Total      25372
> ----------------------------------

When I was writing my bootloader a few months back, I vaguely remember
being able to debug it with avarice/jtagice. It's been so long though,
that I'm not actually convinced that I really did though. ;-)

Instead of putting all of the .text section into the bootloader, I put
all of the bootloader code into a .bootloader section and then forced
that to flash address 0x1e000. That way, all of my app stays in .text
(including the interrupt vector table) and I have the app jump to the
first address of the bootloader on demand.

By putting all of .text at 0x1e000, you've moved all the intr vectors
and unless you set the BOOTRST flag, the device will power up to addr
0x0. You'll also get weird results if you are using interrupts in your
bootloader. I didn't use interrupts in my bootloader.

Hmmm, that 104 byte of .data worries me. If you are using the avr-libc
crt file, it can not handle copying the .data into sram from the upper
64K of flash. In my bootloader, I took great pains to make sure that I
used 0 bytes of initialized data.

Ok, I don't see how any of this could stop the jtagice from working
unless you are writing/reading some IO register that you shouldn't be
and that is locking up the chip somehow.

One other thing that comes to mind though... does on-chip debug play
well with the SPM instruction? That may be a gray area, but it looks to
me that your debug session with avarice never even gets that far.

---
Ted Roth
PGP Key ID: 0x18F846E9
Jabber ID: tr...@ja...