• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 29 subscribers
  • Views 886 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

resetting RTI counters

Dan S17
Expert 1510 points
Other Parts Discussed in Thread: HALCOGEN

I have tried to reset the counters with the following code snippet:

    rtiStopCounter(rtiCOUNTER_BLOCK0);
    rtiREG1->CNT[0U].UCx = 0x00000000U;
    rtiREG1->CNT[0U].FRCx = 0x00000000U;
    rtiStartCounter(rtiCOUNTER_BLOCK0);


This code doesn't appear to be working and I am trying to determine why not. The technical reference manual (RTI section, page 364) says that the "counter can be preset by writing (in privileged mode only) to this register". I would think that the mode would already be set to privileged but since the code doesn't appear to be working and since I can't find anywhere in the HalCoGen GUI to set or check the microcontroller mode settings I have to ask - How do I check the mode settings?


Thank you,

Dan

  • 0
    TI__Guru 59540 points
    Hello Dan,

    The privelege mode is set in one of the CPU registers and would be covered in the R4 TRM. I am looking up the details and how Halcogen implements setting the mode. I will get back with you shortly.
  • 0 in reply to Chuck Davenport
    TI__Guru 59540 points
    Hello Dan,

    Please refer to this post for additional information on Privilege Mode.
    e2e.ti.com/.../185286

    Unless you have explicitly put the core in a non-privilege mode, it should already be in privilege mode as it will default to Supervisor mode out of reset. Supervisor Mode is a Privilege mode and all registers are accessible.

    How are you determining that the write is not happening?

    Another possibility is latency issues. i.e., the write to stop the counters may take a few cycles to complete. Can you try placing a delay between the call to stop the counters and the writes to clear them to zero?

    If this doesn't work, can you zip your project and attach it to this thread so that I can try and recreate the issue on my bench for debug?
  • 0 in reply to Chuck Davenport
    Expert 1510 points
    Thanks Chuck!
  • 0 in reply to Chuck Davenport
    Expert 1510 points

    Hi Chuck

    Well, I am glad to hear that it is in a privileged mode. Do the writes to the counter preset registers work in any privileged mode?

    You asked: "How are you determining that the write is not happening?". An event which is scheduled to occur, by using the counter and associated hardware interrupt, doesn't occur. The event does occur if I don't try to do the reset of the counters.

    I do not like the idea of placing a delay of any sort into the code. Timing accuracy and low latency is important to me in this project. Do you know whether the latency of the counter start actually is an issue?

    Daniel

  • 0 in reply to Dan S17
    TI__Guru 59540 points
    Hi Dan,

    Typically, its not an issue. Another approach you can take is to simply run the code debug mode and put a breakpoint after you write the counters to 0x00000000. After you do that you can look at the register in the register window to see what the counter value is. To enhance this, put a breakpoint before the write and after the write to confirm the change.

    The issue may not be the write to reset the counters but the startup after. To check the startup after, again, place a breakpoint after you start the counters and check the values in the register window.

    If you can send small project that demonstrates the behavior (write not happening or event not triggered), I can have a look at your code on my bench.
  • 0 in reply to Chuck Davenport
    Expert 1510 points
    Thanks Chuck. I want to try something tomorrow and if that does not work then I will set the breakpoints as you suggested. I'm not a big fan or user of debuggers so that might take me a while if it comes to that.
  • 0 in reply to Chuck Davenport
    Expert 1510 points
    Hi Chuck

    The code now works. I moved the four above lines of code within in a conditional statement that determines if the counter is needed yet (Nevermind what that depends upon because it would only be specific to my needs.) for scheduling the events. So it appears that the problem was that the counter was started when it should not have been and as a result was putting the code into a nonfunctioning state.

    Thanks for your help verifying that privileged mode is the default state for HalCoGen generated code.
  • 0 in reply to Dan S17
    TI__Guru 59540 points
    Hi Dan,

    Glad to hear you were able to get it working in your application!

    Let us know if anymore issues come up and we will be glad to help work through them.
  • 0 in reply to Chuck Davenport
    Expert 1510 points
    Looks like I wrote to soon. It's not working consistently. Maybe per previous suggestions the problem is that it takes a number of clock cycles to restart the counter.
  • 0 in reply to Dan S17
    TI__Guru 59540 points
    Hi Dan,

    Sorry to hear that. Maybe if you can send me a small project with an paired down version of your project, I can have a look at debugging it. If you project isn't too large, you can post the whole thing as well. Also, if there is proprietary info or your not comfortable posting, I can take the project through a private message via the forum. Let me know how you would like to try and resolve it.