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.

RM48 simple timer

Other Parts Discussed in Thread: RM48L952

Hello,

I want to implement a simple timer using RM48L952, for simple delays and timeouts, without using interrupts to do so.

My main idea was to use the RTI module, but  it seems to be such a waste, and besides, according to our specifications there must be only one timer interruption in the entire system, which must never be interrupted. The problem is that using the RTI for that seems to be wasteful and using the N2HET seems a bit complicated.

Does anyone have any suggestions?

  • Pablo,

    Ok, so you want a timer, but no interrupts?  This means when you use the timer for delays you'd be in a 'while()' loop -- right?  ie.. not doing anything else but you prefer the free-running timer to having to 'time' code execution.

    You could always read the RTI counter if this is the case, and then poll it until the RTI counter has reached your target value.   Alternatively you could do the same with the PMU that is part of the CPU core.

  • Thank you so much for your reply.

    I wanted to know if there was a simple way to use this without using this resource (RTI), because it really seems to be a waste, since it can do so much.

    I didn't know about the PMU. I'll get on reading the architecture reference manual now. I thought it was a resource available only in cortex a-15

  • I'm having a problem with the RTI module.

    I have this:

    #define RTI_Base    0xFFFFFC00U
    #define RTIReg      ((RTI_t *)RTI_Base)

    Which would allmow me to write at the module's address. The thing is that when I write to the registers nothing happens, but I can set them normally with CCS.

    I even tried assigning a different pointer to the same address, but it still doesn't work. Any ideas why?

  • Pablo,

    Some registers on the device are protected from user mode access,  in order to harden the part against problems in user mode code.   You might be running into this because the debugger always can write to any register (priv or non-priv..) but your code may not able to write to a register if it's priv and you are in user mode at the time of the write.

    For example the RTI Global control register is this way.

    This is a secondary level of hardening after the MPU - you can outlaw user code from writing to the RTI completely if you want by using an MPU channel but here you get some protection regardless.  

     

  • Here's the thing. For test purpouses, I've never put my code in user mode, it is always running in supervisor mode. But when I checked The M bits I could verify that I was actually in user mode, which doesn't make sense.


    When I reset the CPU by CCS and run my entire bootloader (I built my own bootloader and my own drivers) And it gets to the main function I can check that the M bits get there in supervisor mode (which conflicts with what happens when I load the program and push start). It's like whenever I run the program after a program load it isn't executing the bootloader.

    After that another strange thing happens. If I run the code without a reset, I can use printf, but after I perform a reset, an error occurs, and then the GEL messagebox appears and I have to leave debug mode.

  • Ok. I was able to solve the problem. I was missing the --entry_point command in the linker file.

    But still printf still isn't working. I'll create another topic for this, since it's an unrelated topic. Thank you very much for your help