Debugging Bootloader Code on Atmega328P with AS 6.1 and Dragon

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

Trying again (fourth time) to start discussion.  If this works, I'll reply to post the real content.

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

I have a custom bootloader for an Atmega328p  that I want to debug with the Dragon tool in AS 6.1.

 

I have these linker flags:

 

-Wl,--section-start=.text=0x3800

The 2048_3800 fuse is set and the BOOTRST fuse is set.

 

Both compiler and assembler have default debug data.

 

The .text section starts at 0x3800 according to the loadmap file(attached as AES.txt) and the address of main looks reasonable (0x00003dbe   )

 

 

But, when I click

 

   Debug->Start Debugging and Break

 

I can see the status message indicating the boot code is loaded over debugWire, but the first line of main is never reached.  If I do

 

Debug->Break All

 

and bring up assembly view, I see code running in low memory:

 

00000283  SBIS 0x09,2		Skip if bit in I/O register set 
00000284  RJMP PC+0x0003		Relative jump 
00000285  SBIC 0x09,3		Skip if bit in I/O register cleared 
00000286  RJMP PC-0x0003		Relative jump 

 

It's like the bootloader code was loaded at 0x0 (or at least control was transferred to low memory)  instead of the 0x3800, despite the linker settings and what's reported in the loadmap file.

 

I feel like I'm missing some simple configuration option. Can anyone help?

 

... I tried using 

--section-start=.boot=0x3800

instead of .text.

 

Now the code seems to run to the first line of main.  Seems to step ok for a while, but then goes "in the weeds".  And, now the load map makes it look like the code is at 0x0 instead of the 0x3800 I saw when the .text=3800 flag was used.

 

 

 

Really need help!

 

Dave Thomas

 

Attachment(s): 

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

For the BOOTRST Fuse “1” means unprogrammed while “0” means programmed.

 

So, does a checked box adjacent to BootRst under Tools-->Device Programming->Fuses indicate "1" or "programmed"?

 

 

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

In Atmel Studio a check means "programmed".

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Thanks, that's what I was assuming.

 

Is there a way to debug (in asm) from the reset vector?  Right now, a breakpoint set in the first line of main  is never seems to be reached.   

 

Also, I can't figure out how to set a breakpoint in code that doesn't have C source code associated with it.

 

Dave Thomas

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

Figured out how to set a breakpoint--just typed an addressed in the assembly window that came up when I did "break all".

 

Set a break at 0x3800--sure enough, that breakpoint is hit after reset, but the assembly view shows nothing but NOPs:

 

00003800  NOP         Undefined 
00003801  NOP         Undefined 
00003802  NOP         Undefined 
00003803  NOP         Undefined 
00003804  NOP         Undefined 
00003805  NOP         Undefined 
00003806  NOP         Undefined 
00003807  NOP         Undefined 

 

However, the memory view of flash shows what looks like code (at least not all the same op code like NOP), maybe a jump table:

 

 

prog 0x37F8  ff ff ff ff ff ff ff ff 0c 94 49 1c  ÿÿÿÿÿÿÿÿ.”I.

prog 0x3804  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3810  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x381C  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3828  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3834  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3840  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x384C  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3858  0c 94 5c 1c 0c 94 5c 1c 0c 94 5c 1c  .”\..”\..”\.
prog 0x3864  0c 94 5c 1c 8f ef 98 e0 9e bf 8d bf  .”\..ï˜àž¿.¿

 

So AS 6.1 seems to be interpreting flash memory differently  in assembly versus Memory views. 

 

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

Figured it out--the entire table 27-13 in the Atmega spec is in words, not bytes including the section start addressess.

 

So, instead of --section-start=.text=0x3800 I needed --section-start=.text=0x7000

 

I saw previous posts about the byte/word confusion and should have noticed from the 0x3fff in the tables for a 32K part meant they were word, not byte addresses.

 

Darn, so much time wasted on a stupid thing.

 

Dave Thomas