No way to trace USUART or GPRs

[jeffpc]

The tracing support seems to be incomplete. Specifically:

(1) I can't find a way to trace (or otherwise access) the USUART output. The portpin trace kind seems to work only with GPIO output. (I don't expect USUART to be unique with this, I just haven't tried other devices.)

(2) Since at least some AVRs allow multiple ways to access the GPRs, I was hoping that access via any method would trigger the trace. For example, I have these with my ATmega48p simulation (i.e., the Y register):

            --add-trace yh=trace@0x1d/0xff
            --add-trace yl=trace@0x1c/0xff

but the trace file doesn't include any values for logic.yh and logic.yl.

Am I missing something? Thanks.

[gatk555]

1. Have you tried tracing the UDR register?
2. I think it is a design choice that the GPRs can not be traced. Speed was preferred over an arguably pointless feature. If you really want it, a simple code modification in sim_core.c would probably make it work, but if you want to see what the firmware is doing there is --trace.

[jeffpc]

1. Yes, I traced UDR but some of the bytes I expect to see are showing up as 0x00 in the trace. Hence my interest in getting at the the various state. (I fully expect that this is a bug with my code.)
2. I tried using --trace, but that doesn't print anything and doesn't write any trace data to a file (and it looks like the binary was built with tracing enabled).

E.g.,

$ simavr -m atmega48p fw.elf --trace 
Loaded 142 .text at address 0x0
Loaded 8 .data

(fw.elf sets up USUART and sends about half a dozen bytes before going into an infinite loop.)

[gatk555]

If you are using a pre-built binary, --trace likely fails silently if tracing is not configured. An error message was added in April. I do not know of any source for binaries with tracing enabled. If you are happy to post your firmware (source or binary) I can run tracing on it, as I want to expose my tracing enhancements to additional test material. Running with gdb may be an alternative.

[jeffpc]

Ah, you are correct. The package I was using doesn't have tracing enabled - and I was looking at the latest code which has the "(Off)" string in the usage text. I built simavr from source with -DCONFIG_SIMAVR_TRACE=1 and now --trace works.

I tweaked the dumping function a bit to get the full list of register values and dump the first 512 bytes of ram using `_avr_get_ram'. This certainly explains why I'm seeing zeros in the vcd file for UDR values - the memory that it's loading the characters from are full of zeros. The ELF file I'm loading certainly has the data bytes (at 0x00800060 vaddr), so I'll have to figure out where things go wrong during loading.

I can share the ELF (beware, it is silly and minimal at this point); what's the best way to get it to you?

[gatk555]

You can attach files here, or if that seems too permanent, email to my associated mailbox: gatk555(at)gmail.com.

But if you are using the shared library, why not compile it yourself? (Not that I would not like a real-world test case.)

[jeffpc]

I finally figured out what the problem was. As I predicted, it was with my code. Specifically, I was assuming that the SRAM would be populated with .data from the ELF file on reset. This of course doesn't make sense with real hardware. I modified my bootstrap code to copy the data (that was in .data) into SRAM and things started to work both in simulation and on a real atmega48p. I want to mess with it a bit more, but I'll email you the binary as a tracing test case in a few days.