#avr Logs

Mar 10 2022

01:21 AM jancoow: Damn, such annoying bug. It took me weeks to reproduce and figure out. For some reason, the 32khz crystal is turned off randomly...
01:30 AM Phantom: stray capacitance?
01:30 AM jancoow: Which means that our product littarly went radio silence. Which is weird, because we have many checks to prevent this (silence timers, no downlink timer etc.) And ofcourse a windowed watchdog
01:30 AM jancoow: But guess what
01:30 AM jancoow: Freetos timers don't work without the clock..
01:30 AM jancoow: And the watchdog neither......
03:38 AM jancoow: I'm just clueless how the 32khz crystal turned of.. I neither can turn it on with the debugger
03:59 AM specing_ is now known as specing
10:11 AM Zazem: Hi there !
10:12 AM qu1j0t3: Zazem: o/
10:13 AM Zazem: I'm making my way on simavr, I beging to understand how it works with gdb
10:14 AM Zazem: I can now debug line by line of assembbly and see the general registers
10:15 AM Zazem: But can not se changes on the SREG, see the ports with display
10:15 AM Zazem: The `load` command does not work, I dont find solutions on the web
11:51 AM josuah: Zazem: how did you get your gdb plugged to the board?
11:51 AM josuah: something like "target extended-remote :3333"?
11:51 AM josuah: did you use the "file" command before "load"
11:52 AM josuah: and most useful for anyone to help you: what error did you get?
11:52 AM josuah: without us knowing that well... :P
11:55 AM Zazem: I comment my problem here: https://github.com/buserror/simavr/issues/371
11:55 AM Zazem: May there get's easier to read
11:58 AM Zazem: I'm the last comment xd
12:03 PM josuah: thanks for the very complete report
12:03 PM josuah: unfortunately I have not tested with simavr :S
12:03 PM josuah: > Remote target does not support flash erase
12:03 PM josuah: weird, why would it try to erase the flash?
12:03 PM josuah: maybe unrelated to the "load" command not working
12:06 PM Zazem: Thats what I want to know. I only get how to see the registers, but not the memory or the ports. I following a blog tutorial.
12:06 PM Zazem: https://blog.oddbit.com/post/2019-01-22-debugging-attiny-code-pt-1/
12:09 PM josuah: Zazem: you might not need the "load" for memory or port, is that not only for loading the elf binary?
12:10 PM josuah: I have not managed to do it yet, but you should be able to read memory addresses directly, without loading a binary
12:10 PM josuah: that does not fix the problem though :/
12:11 PM Zazem: That's what I think. The blog says use `display` to see the port values but shows nothing so I think it need to load the elf binaty may be?
12:11 PM josuah: ah, though to do things like "display PORTB" I suppose it would take the source code, deduced from the .elf source I guess
12:11 PM josuah: as you said is my guess
12:13 PM Zazem: I'm reading that simavr need info code to trace the signals. Maybe that's what I missing?
12:13 PM Zazem: https://blog.oddbit.com/post/2019-01-22-debugging-attiny-code-pt-3/
12:13 PM Zazem: But how I do that on assembbly code XD
12:15 PM josuah: interesting tool, no idea it existed
12:15 PM josuah: Zazem: why not use C?
12:16 PM Zazem: First it is required asm on school and second: I love pain :3. Assembbly is a really interesting lenguaje
12:16 PM josuah: Zazem: well you could doit in C and then watch the assembly
12:17 PM Zazem: Tha's a way, I can not deliver homewok on C. My guess is i can combine asm and C on teh same file to trace signals
12:19 PM josuah: Zazem: I mean writing in C to let the compiler tell you what kind of assembly you need to write to get it that way
12:19 PM josuah: iirc something like this: avr-gcc -S -o $file.s $file.c
12:20 PM josuah: or regular compilation, then objdump -d $file.o
12:20 PM Zazem: josuah: That's great
12:20 PM Zazem: I gonna give it a try
12:20 PM Zazem: thanks
12:20 PM josuah: Zazem: but with plain assembly, you could also try by guessing how the structure is packed
12:20 PM josuah: each of the line such as { AVR_MCU_VCD_SYMBOL("PIN_POWER"), .mask = (1<<PIN_POWER), .what = (void*)&PINB, },
12:21 PM josuah: would end-up in memory, with the pointer to AVR_MCU_VCD_SYMBOL("PIN_POWER") first, then the mask (1<<PIN_POWER), then the address &PINB
12:21 PM josuah: some assembly pseudoinstrution such as ".word" would let you push all sort of thins onto memory
12:21 PM josuah: the address for these things is chosen by the linker script
12:22 PM josuah: the linker script is the real core that tells which code goes to which kind of storage at which address
12:22 PM josuah: and there is an instruction in the C snippet example that tells something to the linker:
12:22 PM josuah: const struct avr_mmcu_vcd_trace_t _mytrace[] _MMCU_ = {
12:22 PM josuah: there is something odd with this line: _MMCU_
12:23 PM josuah: what is that? between a variable and the equal sign?
12:24 PM Zazem: I dont fully understand what's going on there.
12:24 PM Zazem: In any case I have a way to work around during the day
12:24 PM josuah: that is most likely something a #define to __attribute__ ((section (".mmcu")))
12:25 PM josuah: so in assembly, you can try with: .section .mmcu
12:25 PM josuah: then: .word .....
12:25 PM josuah: then: .word .....
12:25 PM josuah: then: .word .....
12:25 PM josuah: etc for filling the structure
12:25 PM josuah: and hmm... that's it? :P
12:26 PM Zazem: This is very usefull, I saving this conversation so I can check it later :3
12:26 PM Zazem: Thanks
12:26 PM josuah: not sure everything I said is accurate, and when in doubt, feel free to ping me about something
12:26 PM josuah: I'd prefer spending some more time than misleading someone and waste precious time
12:27 PM josuah: good luck!
03:59 PM specing_ is now known as specing