MOD54415 HiResTimer

[nicobari]

Hi,
I am trying to use HiResTimer to generate interrupts at regular intervals. I am using the HiResTimer.cpp,HirResTimer.h and main.cpp in the utils folder of the example codes as my reference. When Ia m using the following code for the timer.

(1)HiResTimer *timer;
(2)timer=HiResTimer::getHiResTimer(0);
(3)timer->setInterruptFunction(fucntioncall);
(4)timer->init(0.01);
(5)timer->start();

exactly taken from main.cpp in the utils folder of the example codes in nburn folder

While compiling I am getting error in line (2) and (3) that "undefined reference to `HiResTimer::getHiResTimer(int)' and undefined reference to `HiResTimer::init(double)'. I am out of ideas what I am doing wrong. Any Ideas? Thanks in advance.

Regards,
TM

[Arturino]

You need to recompile system files.

[nicobari]

Hi,
Thank you. After your reply I saw your other post regarding HiResTimer.

Regards,
TM

[nicobari]

Hi,
So this worked for me
Open Makefile in MOD5441X/systems folder
check if HiResTimer.cpp is commented or not included in the file.
If commented remove the # or add HiResTimer.cpp if not included.
Then run "Rebuild Modified Systems Files" in NBEclipse.

Thanks.

Regards,
TM

[Ridgeglider]

If you are using Eclipse, this might be easier:
Pulldown File, New, Project, NetBurnerProject to create a new, empty project named MOD54415_HiResTimer (NO SPACES!). Be sure to specify Release and Debug versions, the target platform of MOD54415, and set the proper IP. When you get to the appwizrd section, leave all boxes unchecked.

This will setup a blank, MOD54415 project folder in the Project Explorer.
Copy the main.cpp file from C:\nburn\examples\utils\HiResTimerDemo into the project folder. If automatic build is setup, it should build immediately. If not, try to clean the project by selecting the project folder, then right clicking to Clean Project.

If this fails, select the project and pulldown the NBEclipse menu and select the "Rebuild All System Files: option.

[mbaybutt]

I have been experiencing odd trap behavior when using the timer->setInterruptFunction() functionality. I am attempting to establish a timer to trigger a function call at a rate of 4ms. After debugging the issue a bit, my sense is the issue lies in the interrupt capability not being reentrant. Meaning the trap condition seems to trigger if the timer expires before the previous call to the interrupt function returns.

-------------------Trap information-----------------------------
Stack is corrupt A7=00000034
Trap Vector =
Stack Frame seems corrupt unable to do RTOS dump

-------------------End of Trap Diagnostics----------------------

I have implemented a semaphore within the interrupt function to protect the shared variable memory, but the issue seems to lie in calling the function itself. Has anyone else experienced this or have a work around?

Thanks,

- Mark

[dciliske]

So, if you've got a IRQ function that's running for 4 ms, it's probably starving the rest of the system of EVERYTHING. You really need to have the functionality of the your ISR in a separate task, waiting on a OS_SEM or OS_FIFO to kick it off.

[dciliske]

Actually, the issue you're probably running into is that you're probably calling OS level functions or IO. You can't do that inside an ISR.

[mbaybutt]

Hi Dan,

Thanks for the reply and insights. Those certainly could be causes for the issue, but if I adjust the timer to call the interrupt function at a slower rate (e.g. 250ms) the system seems to keep up. Let me provide a more clear and full picture of what I am trying to accomplish, I parse incoming UDP packets and depending on the contents push messages out the CAN, UART and I2C ports. Within those messages there is a rate parameter which I use to set how often to push a repeat of the same message to CAN, UART, I2C.

For sake of isolating the issue, I am confining testing to just one message type destine for UART. I use setInterruptFunction(SendToUart) to configure the interrupt function. Within SendToUart() there are calls to OSSemPend() and OSSemPost() to protect the variable that contains the message data destine for the UART bus since it can be modified by the ethernet parsing function and write(); those should be all the system level calls that are made.

What is interesting is that this paradigm works fine for (a) slower timer rates and (b) small packets of data pushed to the bus. In fact, for the UART bus, I can exercise this paradigm with 8 bytes of data being pushed to the UART at 4ms and the system seems to keep up (over the span of 5 to 10 mins of testing, could fail after that or if other aspect of the Nano are exercised can't say for sure). If I try to push a greater quantity of data to the UART at the same rate the trap condition is entered.

After putting print statements in to see where things were failing, it led me to believe it was a reentrant issue in that the first timer trigger made a call to SendToUart, but did not return before the timer went off again making another call to SendToUart. Is that a reasonable conclusion or could there be something else going on here?

Thanks,

- Mark

[tod]

Sounds like it could easily be a dead-lock/stack overflow issue. If you're pending on a semaphore that you already pended on the previous time through your routine would just wait there. Assuming this is all in one task you're never going to get back to the original invocation. You'll keep triggering your handler until you run out of stack space. Without seeing the code it sounds like you have to either prevent the timer from firing again or track that you were already processing and just return when that is the case.

Using serial I/O for debugging in this kind of situation is pretty dicey, serial I/O can take a lot of time and cause you problems. I find using leds (if they are available) is a better way to see where you are.