CALL to location FFFF

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

Hi,
Just checked the forum & didn't see anything related to this. Sometimes, the AVR Studio + GCC combo just refuses to be debugged. Or it jumps to a bizarre location and tries to debug stdint.h !!!

(1) some calls just end up pointing to FFFF: for example:

---- W:\M400\5xx\506\test_dsd_src\main.c ----------------------------------------------------------
187:        LedsInit();                 // Setup LED IO pins
+0000043F:   940EFFFF    CALL    0x0000FFFF       Call subroutine

While it should be:

---- W:\M400\5xx\506\test_dsd_src\main.c ----------------------------------------------------------
187:        LedsInit();                 // Setup LED IO pins
+0000043F:   940E1636    CALL    0x00001636       Call subroutine

I don't know if these are two separate bugs or symptoms of the same problem.

Sometimes I can get it working by setting all RAM to 0x00 (by loading a zerod-out hex file.) (why would this work?)

Sometimes I can get it sane again by exiting AVR Studio, rebuilding & powering the JTAGICEmkII & target.

Regards,
Alf Lacis
http://au.geocities.com/lacis_alfredo

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

That looks a lot like a program that has been compiled but hasn't been linked (and it's the linker fixes up the external call references)

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

(Not) sorry, but that's not an answer... what can I *do*, right now, to make this work?

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

What do you mean that's not an answer. Compiled code needs to be linked to resolve the addresses. What file are you looking at when you see this "problem"?

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

lacis_alfredo wrote:
(Not) sorry, but that's not an answer... what can I *do*, right now, to make this work?
You can make sure your whole project builds AND is loaded before starting up the debugger.

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

lacis_alfredo wrote:
(Not) sorry, but that's not an answer... what can I *do*, right now, to make this work?

Stamp your feet even HARDER and toss ALL the toys out of the pram perhaps? I always find it helps. :lol:

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

Hi, clawson,
Thanks for the sanity check. My apologies, just goes to show, don't post after a night out... "Don't drink and drivel." [groans]

Back to the topic: yes, WYSIWYG: the code fragments from the original post were from an AVR Studio debug session, showing 'View | Disassembler'. It's not me opening a list file or anything like that #.

So what you can see is what I saw.

1. Please, are A.S. trying to debug stdint.h and A.S. not starting a debugged application properly symptoms of the same bug? For an example, see: http://au.geocities.com/lacis_alfredo/pix/avr_bug_3.PNG

2. Why does A.S. start debugging properly after I clear RAM?

3. Is there something else I can do so these problems don't occur?

4. in the assembler start-up code, why not just erase the whole of RAM (perhaps except for the DATA section), instead of just the BSS area (apart from a few extra microseconds required to start up)?

Has anyone done 4?

Humbly,
Alf
(#) For my bona fides, see http://au.geocities.com/lacis_alfredo/resumes

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

1) that's extremely curious, as you probably know the yellow arrow should only ever position on a line that has generated code - clearly there are no such lines in stdint.h - when you are in that situation just select "disassembler" on the "view" menu and find out that it thinks is "underneath" the C code. But this looks like some kind of fault in the symbolic info that's been built into the .elf file.

Also forget the JTAGICEmkII for the time being and load and debug the same file using the simulator and see if that differs

2) clear RAM how?

4) you are forgetting about .noinit I think! But you can, of course, put your own routine into .init3 to clear the whole of RAM before the .data/.bss code gets a look in if you want. Make sure it uses just register (and not stack frame or .data/.bss) variables. You will therefore need to make sure some type of optimisation is turned on.