Accessing I/O space in avr-gdb; uzem bug?

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
Post Reply
charliegreen
Posts: 22
Joined: Wed Jan 14, 2015 7:28 pm
Location: California, USA

Accessing I/O space in avr-gdb; uzem bug?

Post by charliegreen »

Hello!

I'm writing a video mode, and I'm not using AVRStudio for debugging, as I'm on Linux and AVRStudio is Windows-only. Right now I'm using uzem's gdb debugging mode and avr-gdb instead. I'm trying to read the TCNT1 I/O register to make sure my timing is right when emitting hsync pulses.

I found this, which told of the avr-gdb "info io_registers" command, but this hits on a bug in gdb (here's a paste of the output, if you want it). I figured I could just use the register file memory mapping, then, and use gdb to examine 0x800084 (since TCNT1L is at SRAM address 0x84), but this only ever shows zeroes! After adding a quick `lds r8, TCNT1L` to my code, though, I can read the value just fine by looking at r8. Not only this, but when I write to TCNT1L (`set *0x800084 = 0x42`), then read the value back in my program, it's unchanged!

At first I thought uzem wasn't mapping the entire register file to the bottom of SRAM like it should, but it definitely maps r0-r31, SREG, and SP properly, and many of the values I see up to 0xFF look right. Maybe it isn't updating all of the I/O space that it should on each cycle, or models the timers separately from the I/O space? I'm not sure.

If I'm overlooking something obvious, please let me know. Also, this isn't a huge issue for me, since I can just use `lds` to read TCNT1 at key points in my program, but I thought I'd let you know in case this counts as a bug in uzem. Thanks!
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Accessing I/O space in avr-gdb; uzem bug?

Post by D3thAdd3r »

Out of curiosity have you tried running what you have in CUzeBox? I had an RLE mode roughed out, but cycles were off quite a bit. 5 minutes of changes and recompiles, it was easy to make the red lines(bad HSYNC timing) go away without cycle counting; it was very cool how easy that was compared to using AVRStudio cycle counting I did in the past. Just an option if you hadn't considered it, I have no clue about the state of Uzem though.
charliegreen
Posts: 22
Joined: Wed Jan 14, 2015 7:28 pm
Location: California, USA

Re: Accessing I/O space in avr-gdb; uzem bug?

Post by charliegreen »

Oh, cool, I hadn't! I had no idea CUzeBox had a feature like that! I'm still roughing out a lot of the logic of the video mode, though, so I'm sticking with uzem until I don't think gdb will be useful anymore, but that's good to know, and I'll probably use CUzeBox to finalize the timing. Does CUzeBox have other neat features like that? What does "RLE" mean in this context?
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Accessing I/O space in avr-gdb; uzem bug?

Post by D3thAdd3r »

Nothing in context, the experience I had with that particular CUzeBox feature just happened to be a simple Run Length Encoding based video mode but would apply equally as well to anything. For additional features it can also help with vsync timing, and has the same convenient "whisper port" like Uzem. Ultimately GDB can do deeper debugging, but usually such things are not required and it is definitely slower for those types of things IMO. Also the frame by frame analysis might be helpful in some cases.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Accessing I/O space in avr-gdb; uzem bug?

Post by Jubatian »

I never used a debugger :p gdb is missing from CUzeBox since it was a rather large C++ code in Uzem (and CUzeBox by decision is C89 conforming, so no C++), and I don't even understand the mechanics of this as I never used it (that way it is difficult to debug something).

With CUzeBox it is rather easy to get a video mode functional as you will immediately see what and where could be wrong in the timing. There are some pitfalls when a mode is really broken, but once you can get CUzeBox sync, it is just some knowledge of the kernel and your code to track back problems by the red and yellow indicators (I developed it after the patches I added for myself into Uzem when creating Mode 74; those patches were simple prints, quite unwieldy, you had to know what you are doing and what you are getting).
Post Reply