#avr Logs

Apr 25 2017

12:04 AM daey_ is now known as daey
03:11 AM daey_ is now known as daey
03:23 AM jaggz is now known as meditation
04:06 AM noHitW_work: morning
04:07 AM polprog: morninf
04:23 AM Emil: xentrac: I am aware
04:23 AM polprog: saturday was a day open at school
04:24 AM polprog: they liked my thermometer :D and some other blinkenlights
04:25 AM Emil: nice
04:26 AM polprog: i got a scope from the technical school, shown them the oscillofun demo from my mobile
04:26 AM polprog: it was cool
06:28 AM Tachyon` is now known as Tachaway
06:47 AM blathijs: Hey folks. Anyone got some pointers on creating a proper backtrace from a raw stack dump from an AVR uc? I'm trying to get a backtrace from a watchdog interrupt, but I haven't found much about this yet. I added some code to dump the stack (SP to RAMEND) to serial, but now I'm looking to analyze that dump. I found a tool from Atmel that brute-forces the dump by looking for any address that actually has a call
06:47 AM blathijs: instruction, which works but is rough, gives extra entries in the trace, misses interrupt invocations, etc.
06:48 AM Lambda_Aurigae: never had to do such a thing.
06:48 AM blathijs: Ideally you'd have a tool that knows about the stack usage of each function and through that figures out the exact backtrace. I think gdb can do this, but you'd need to feed it a coredump, and I'm not quite sure what the fileformat for AVR coredumps is (and if it's even supported at all).
06:49 AM Lambda_Aurigae: if the flash isn't read protected then you can use whatever programmer hardware you have to read the flash...closest to a "coredump" you are going to get.
06:49 AM Lambda_Aurigae: avr-gdb is going to need a simulator to run it on so you will need one that supports your chip.
06:50 AM Lambda_Aurigae: or you can connect avr-gdb to your actual chip with jtag or debug-wire
06:50 AM Lambda_Aurigae: and debug onchip.
06:50 AM Lambda_Aurigae: sounds to me like you really just need to do a bit of code review and figure out what your code is doing.
06:50 AM Lambda_Aurigae: going for a backgrace and all is a bit overkill on something as small as an avr really.
06:51 AM Lambda_Aurigae: all that dumping the stack is going to tell you is what is in the stack at that point in time...it changes constantly.
06:51 AM blathijs: I have the .elf file, so no reason to read the flash. I'm dumping RAM, not flash.
06:51 AM Lambda_Aurigae: or, should change as you call functions and use stack commands
06:52 AM blathijs: And I want to know where my lockup occurs and what it is doing at that moment, so I make a dump of that moment.
06:52 AM Lambda_Aurigae: if it locks, how do you dump?
06:52 AM blathijs: Using the watchdog interrupt (which, when configured, fires instead of resetting the board)
06:53 AM Lambda_Aurigae: if you have serial port access, just write some debug lines in there to write data out to the serial port at various points in the code.
06:53 AM Lambda_Aurigae: if you have windows, run your code on the atmel studio simulator.
06:54 AM Lambda_Aurigae: that has full debugging capability as I hear.
06:54 AM blathijs: A simulator won't help, since the lockup seems to be triggered in very specific hardware circumstances. Debug printing only provides limited help, since the problem is hard to reproduce, so I'll have to get as much data as possible from a single lockup.
06:55 AM Lambda_Aurigae: I've never seen anybody doing backtrace on an AVR before.
06:55 AM Lambda_Aurigae: no clue where to start other than google.com
06:55 AM blathijs: Also, I have a JTAG debugger available, but I want to collect data from multiple devices at the same time, so I need something that works without JTAG
06:59 AM Lambda_Aurigae: I suspect you are going to have to manually look at the stack and see what has been called.
06:59 AM Lambda_Aurigae: which means reading the avr-libc manual and figuring out what gets pushed on the stack for a function call and interrupt and all that.
07:02 AM Lambda_Aurigae: ok...time to go break some copiers.
07:02 AM Lambda_Aurigae: have fun.
07:03 AM blathijs: Yeah, I can figure that out from the disassembly as well, but I was hoping to reuse some existing code (I'm pretty sure gdb has the code to analyze things, if I can get the data into gdb)
07:03 AM blathijs: Lambda_Aurigae: Have fun as well, thanks for your thoughts!
08:02 AM JanC_ is now known as JanC
08:43 AM Apocx_ is now known as Apocx
01:56 PM JanC_ is now known as JanC
02:22 PM robinak is now known as robink
11:34 PM daey_ is now known as daey