avrdude dump only ff ?

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

Hi,

I have had som issues with writing/reading to EEPROM, there was some linkage issue when having the

code in a separate compiled unit. However I think I have now solved that, it seems to work since

the values I store, can be retrieved after a re-start,  using the macros for read from eeprom.

 

Only that; when I use avrdude (in terminal mode)

 

dump eeprom 0 12;

 

where I would expect the variable to be placed

there is only ff returned.

 

I have some dejavu about this, that I have been unable to see data even though it there.

 

thanks if anyone could have a tip what im missing

/g

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

Why don't you dump the entire EEPROM and see if and where your data shows up.

 

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

Are you also programming the chip? If so do you know the significance of EESAVE?

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

actually, no; dont have notion of EESAVE (will check), but Im not re-downloading  between write and read, only turning off power, fully.

and I do get the read give same value as the write before turn off.

 

as usual I have in the other location when communicating, than where I have my setup, so cant make tests just now, but I will try

make a read direct on commandline, i.e not in terminal mode. 

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

Bootloader or ISP?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Aug 7, 2019 - 01:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

Bootloader or ISP;  bit shorthand, do you refer to how I connect to M8 for Avrdude com; well that is actually a impayimpa of own make with RS232

(avrdude -c dapa ....) (has been working well for like 5yrs now, except some solering giving up now and then)

 

your "experience .." notion, evidently discards me as experienced :)  I have a strong feel that I have encountered this before (a while since i dumped eeprom)

 

 

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

What happens if you ask it to dump the WHOLE of the EEPROM? If that shows 0xFF for the entire space and yet your code results show data is being stored then it's your programming system that is FUBAR.

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

gechxx wrote:
bit shorthand
The question was, are you connecting to your target with an ISP programmer, or are you doing so via a bootloader?  The reason for asking is that not all bootloaders handle EEPROM.

 

gechxx wrote:
dapa
I have my answer then.

 

gechxx wrote:
your "experience .." notion, evidently discards me as experienced :)
If you say so.

 

Good luck with your project.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Hi all
Did the what should have been fone earlier
Dumped all eeprom and see a bit into mem the dwords appeared. Thanks for all help, sorry for getting stuck on such trivial.
/g

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

But how come the linker didn't position it at 0? Had you done something to override that?

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

No actually not. And as suspicion gives I have now run into further problem.
When including exact code from testrigg into mainbody, the ee-storing fails again. Seems a linkage issue. Guess I will have to take to 'halving method' removing functionblock by block till it goes away...

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

Actually, storing worked once when whole code was in mainfile. Troube started whe I lifyed it to a separatly compiled file and .o file
(Coming to think of it)

Last Edited: Thu. Aug 8, 2019 - 08:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again
Highly annoying outcome;

Added some exta printout and increased a buffersize for a temporary used buffer
And alll seemed to work well also in the all assembled module program, but no !
Now a totally unrelated package ( for providing clock/date, a DS1203) long time working stable, suddenly presents 0.

Only thing close to a clue what i can see is that according to map printout, the time var is at top of common while one of variables of ee problem follows in common
. clearly annoying since this is last step of integration of this version of the program....

Last Edited: Sun. Aug 11, 2019 - 08:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again.
I actually start thinking it could be a stack collission issue. avr-size givesme 517bytes in SRAM. Is there any way to check calling depth / stack alloc (think not checked, my code is some 10 at max)
as freeware (guess iccavr does the trick
.)

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

You mention avr-size (part of the avr-gcc toolchain) and iccavr (which could be Imagecraft or IAR) so which compiler are you talking about? 

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

Well im using gnu

However I found an entry in a thread on the issue (of stack depth) from 09 where somone was encouraged to use (seemingly IAR) iccavr for checking (and yes I did realise it was a full sdk, didnt get it was iar though) anyways someone may have made afreeware hack ?, no.
Well I guess pen and paper to follow callchains isnt impossible..

Last Edited: Sun. Aug 18, 2019 - 06:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another thought, though far fetched, im doing a dword read /write in the code when included induces stange things, could it possibly be that the avr macro for this is upsetting the stack? ( with the assumption dword is not so freq use towards ee.)

(Some error modes i see looks like over writes of .data 0000 and sometimes the second word !)

Last Edited: Sun. Aug 18, 2019 - 07:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:
(seemingly IAR)
IAR EWAVR has stack analysis.

gechxx wrote:
Well I guess pen and paper to follow callchains isnt impossible..
Indeed possible though tedious.

Dynamic analysis :

  • data breakpoint range that's the stack guard region
  • unified memory AVR can transmit the value of the CPU's stack pointer via UPDI

 


User Guides: IAR Embedded Workbench for AVR

...

...

Atmel Studio 7 - Stack Overflow Detection Using Data Breakpoint

 

"Dare to be naïve." - Buckminster Fuller

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

Thanks !
Have been using studio only a little. Will check. Is breakpoints supported running on target? (or emulation)

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

Yes, breakpoints are fine in the Studio debugger. Have had "lots of them" in a single run.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

https://github.com/ezharkov/ezstack
You can also use SRAM painting and examine via debugger.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Mon. Aug 19, 2019 - 12:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok thanks
Though have still not understood if studio can debug when running on target ( how is communication done in that case)
Also it looks like its no good trying to use studio offline ?

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

gechxx wrote:
Though have still not understood if studio can debug when running on target ( how is communication done in that case)
Which AVr are you talking about. Many have some form of On Chip Debugging unit (debugwire, JAT, PDI, UPDI, etc). To connect to Studio you then need an interface that can support the same protocol that the chip uses. debugWire/JTAG are still possibly the most widely used. Devices like Atmel-ICE, Dragon, Power Debugger, Snap, PICKIT4 should be able to handle most of these protocols.

 

By "studio offline" I presume you mean the "simulator". For a p[ure memory leak it should work, but if the running of the design is dependent on external stimuli then simulation may not be possible as the AS7 simulator is not very good at supporting the simulation of external events (for that you need something like Proteus).

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

Thanks ok
Its an atmega8 im working on.
Have no notion of deb support for this.
Guess ill have to make dummy rutines for my drivers and use simulator (/emulator)
Since they are at the end of call chain stack depth should be same

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

gechxx wrote:
Its an atmega8 im working on.
Yup, you picked the wrong chip. This is why people using the pin compatible mega88 rather than the mega 8 because one of the ways it is better is that it has debugWire.

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

Ahh see ! I actually have 88s in store, bought as extras if mem would be too tight.
Looks I should mount a board with one.
How is deb accessed, hopefully uart or isp pins...

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

gechxx wrote:
How is deb accessed, hopefully uart or isp pins...
Neither. For a mega88 (and 168, 328) the debug interface is called "debugWire" and it only uses one pin - the _Reset pin. However to switch in and out of debugWire mode the DWEN fuse has to change and for that to happen all 6 ISP pins (including _Reset) have to be connected to the programmer/debugger interface you use. At the present time Atmle-ICE is probably still the best debugger to use - it costs $100. For something cheaper there is the Microchip Snap that only costs $15 (actually a recent discount had it at half that) but there's still some question as to the best IDE to use to work with it (and in turn that may have implications for the C compiler used).

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

clawson wrote:
For something cheaper ...
another that's less expensive

debugWIRE via USB UART | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

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

Great thanks all. Will try.

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

Hi again, havnt gotten to debug yet.

 

meanwhile Im digging into asm somewhat;

 

I have some things I dont really understand:

    25a:	08 d9       	rcall	.-3568   	; 0xfffff46c <__eeprom_end+0xff7ef464>

     4ea:	df 93       	push	r29
     4ec:	cf 93       	push	r28
     4ee:	00 d0       	rcall	.+0      	; 0x4f0 <logg_rec_get+0x24>
     4f0:	00 d0       	rcall	.+0      	; 0x4f2 <logg_rec_get+0x26>

these are two snippets from the .lst

 

1. the addressing beyond .eeprom_end ?? what is meant ...  ( it seems to be associated with calls to AVR-lib routine itoa / ltoa...

2. then, whats the use of putting the address of current (!) rutine onto stack TWICE,  just in order to do 4 extra POPs at the end..

   (this is at the routine entry when saving registers / PUSHing )

 

/g

Last Edited: Thu. Aug 22, 2019 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gechxx wrote:

1. the addressing beyond .eeprom_end ?? what is meant ...  ( it seems to be associated with calls to AVR-lib routine itoa / ltoa...

This is a consequence of the way different address spaces are handled by GCC.

 

The rcall is to an address 3568 (0xdf0) bytes >>backwards<<, counting from the word after the rcall, i.e. from 0x0000025c.  0x025c minus 0xdf0 is -0xb94.  This results in a 'wrap' below the start of flash 'around' to end of flash.  Your device has 8K of flash, so that corresponds to address 0x146c.

 

Now, binutils (the tools which generate the .lss) computes that as a 32-bit address, or as 0xFFFFF46C.

 

Part of the confusion is that GCC doesn't inherently understand different address spaces.  It was, after all, tailored for Von Neumann architectures, not Harvard architectures like the AVR.

 

AVR GCC maps EEPROM start to 0x00810000 internally, so the difference between the computed 32-bit destination of the rcall 0xFFFFF46C and the start of EEPROM is 0xFFFFF46C - 0x00810000 = 0xFF7EF46C, which is close to the offset you're seeing.

 

The offset is w.r.t. the end of EEPROM, but that's not the end of physical EEPROM, rather the end of the EEPROM segment your app is consuming.

 

I don't see the rest of your .lss file, so I can't confirm, but I'd suspect that you're using 0xFF7EF46C - 0XFF7EF464 = 8 bytes of EEPROM?  You can examine the .map file and look for the symbol __eeprom_end.

 

Binutils is trying to be helpful.  It doesn't always succeed ;-)

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

gechxx wrote:

2. then, whats the use of putting the address of current (!) rutine onto stack TWICE,  just in order to do 4 extra POPs at the end..

   (this is at the routine entry when saving registers / PUSHing )

I'd have to see more context, but this is likely just creating a 4 byte stack frame for the subroutine in question.  Two 'fake' rcalls are shorter and faster than RMW operation on SPH/L.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

gechxx wrote:
1. the addressing beyond .eeprom_end ?? what is meant ...  ( it seems to be associated with calls to AVR-lib routine itoa / ltoa...
avr-objdump has a nasty habit of using the first symbol it finds to annotate code. So say there are three different things with the value 0x123 like:

 

UART_putchar 0x123

_ee_end 0x123

multiply_float 0x123

 

then if it finds something that is 0x123 in the code it will go to this list and just pull out the first of them that looks like it could be a match and put that on the disassembly. Most of the time this works because any location maybe only has one label attached so it fins 0x456 and labels it with the one thing that is defined as 0x456 but sometimes there are multiple labels and, almost randomly, you get the first it saw.

gechxx wrote:

2. then, whats the use of putting the address of current (!) rutine onto stack TWICE,  just in order to do 4 extra POPs at the end..

   (this is at the routine entry when saving registers / PUSHing )

C generally works with "stack frames". When you enter a routine and it has a number of "local variables" (often called more accurately "stack frame automatics") then it has to create a copy of the variable in RAM. That is, set aside some space to hold them. Because the same function might call itself (recursion) and each time you'd want a DIFFERENT set of the variables, then it has to create them so new ones are created each time the function is called. In some C compilers they have two stacks - one where the CALL/PUSH data is stored and one where the stack frame autos are created. In avr-gcc it chooses to use the hardware stack for everything. So when it enters a function first the return address from the CALL is pushed to the stack. Then if the function itself might change some registers (that must be preserved) it will have to PUSh those too. Then it comes to creating the local variables. For a lot of them what it can do is read the current stack pointer, subtract a big chunk from it then write it back. What it also does is set the Y (R29:R28) register to the base of the chunk of variables. Y is known as the "frame pointer" and all the locals are from Y+1 upwards so they can be accessed using indirect ST/LD operations at Y+n. When there's only a couple of int/char locals so only a few bytes then the creation of the space on the stack for them can be done without doing a "read SP;update SP; write SP". For an odd number of bytes a PUSH will create one byte on the stack. To create 2 bytes at a time you can use a CALL/RCALL (each time you use that it puts 2 bytes on the stack) but if you want to "push 2 bytes on stack then some straight back here" you use "RCALL .+0" which "calls" the next instruction - in other words it just carries on at the next instruction but now there are 2 bytes of space added to the stack. So in:

     4ee:	00 d0       	rcall	.+0      	; 0x4f0 <logg_rec_get+0x24>
     4f0:	00 d0       	rcall	.+0      	; 0x4f2 <logg_rec_get+0x26>

that's simply putting 4 bytes on the stack. My guess is you have one (u)int32_t or a couple of (u)int16_t variables being created as locals at the entry to this function.

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

HIllarious, I like these machines,esp. the m8, its so, well most of the time, straight forward (but this is of cause gnu and not atmel...)

 

Yes! right on. I have two 32bits vars in EEprom, and they are missbehaving when I link the total assembly, but while running "cut out" testprograms, alls is fine.

Errors are also "shifting" meaning that i can do one first occurance of my UART command to set clock  (which is a totally different branch from the EEstorage)

first time it fails, repeated exacct same it goes to the D1302 and sets the clock. (works perfect in clock test, or rather when removing routines using EE,

which is code to handle HX711 adc for a weight-scale-sensor). The two stored values that dont get EEstored, in the assembled version are tare and calibration

(two 32bitters), while well and all stored when linking test prog for only that part.

 

 

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

Thanks for explanation, of case I should have associated stackframe with this. And yes, correct, I have a local 32bitter.

AND thanks for explaining the Y register, hadnt got to reading about the relative addressing, of cause, based on routine entry,

solicited by  Hw filling the Y with a base address. /g

 

-- slowly also goes forward; as a colleague said about&to me once ... :)