Odd dependency between GPIO and DMTIMER

[cwl...@mst.edu]

I've been doing some bare-metal assembly programming, and have been bashing my head for a few days trying to figure out why this happens.

Writing to one device seems to prevent me from writing to another for some time. I noticed while trying to use the timer and gpio in the same program.

Attached is some example code (as simplified as I could make it) that fails to turn on USR0 when there shouldn't be a problem.

However, if you put the instruction that turns on USR0 before the instruction that stores the counter, the light works (and the counter does not).

This is not a huge deal as the problem only exits with Timers 0 and 1, but it bothers me that I can't figure out why. I've spent hours looking at
the manuals for the processor and architecture, but I don't know what could be causing this.

Has anyone seen this before or have suggestions what it could be?

[Colton Lewis]

After spending a few more days on the issue, the problem is not what I thought.

The problem was my misunderstanding of the manual about how timers need to be enabled.

I was thrown off track because Timer 2 worked, but this was because U-Boot enables it before I launch my own program.

Sincerely,
Colton Lewis

BSc in Computer Engineering
Missouri University of Science and Technology
573.202.4219

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/8XzzCvwfZ2U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/41f2237a-5928-4687-aa6b-cd7b0c9579dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.