CPU Up Time with NetOS 7.3

Embedded Devices NET+OS
1

I am using NetOS 7.3 and running the same application on the Connect ME, Connect EM, and on the new ConenctCore 9P 9215.

On the new ConnectCore 9P 9215 the Up Time seems to operate correctly and I now have a module that has been running for nearly 4 days and the display on the home page is correct.

Both the Connect EM and the Connect ME have been running for about 16 hours, but are both displaying an up time of about 4 hours. The Up time seems to be wrapping around at about 12 hours. Does anyone eles have this problem or any ideas on how to fix it.

Roy

2

Install the patch files available on Digi supported.
That happens to me and I install the patches and the system apers to work fine.

3

Which patch? I thought I already had applied the patches from the site, but I’m still seeing the issue.

4

Hi,

I have certainly solved the problem now and the up time works on all platforms. I do remember trying to sort out the problem but I cannot find out exactly what I did. It may be that the patches fixed it as I have certainly got the system patched to the latest patches at:>

http://www.digi.com/support/productdetl.jsp?pid=2466&osvid=159&tp=6&s=53

If you have this patch and still have problems I will try again to track how I solved it

5

I’ve applied the patches (again) and rebuilt. I’ve got it running now, but I won’t know until tomorrow if it kept the uptime past the 12 hour mark or not. (unless there is a way to “fake” the uptime).

I’m using the ESP/eclipse thing, and every time it needs to compile the BSP I get make file errors. Not sure what is going on, Digi has assured me that it shouldn’t matter. However, if I’m still dealing with the 12 hour rollover, I’m going to guess that those errors might be preventing the patches from actually showing up in my image.

Nathan

6

If you are using ESP then, i believe there can be a problem when applying patches. The bsp directory in the ESP project contains some files that are part of the BSP source. These files do not get updated when the patch is applied.

I have found that the thing to do is to create a new project under ESP, and then to compare the files under BSP to the ones in your old project and where there are differences, you need to evaluate them to work out if they are due to the patch or if they are due to modifications you have made.

7

Ya, I’ve read about that. When I applied the patches, I followed all the directions on what needed to be updated in the ESP project.

Ironically, I haven’t left it on yet overnight to test the patch, I’ll need to do that tonight.

Is there a documented way to go about compiling/debuggin the image without using ESP? I have to say that it isn’t the most stable environment.

8

Well… no dice. Uptime still resets at 12hours.

Examining the source code, I don’t see anything different that I haven’t changed between my project and a “new” project. (Though I haven’t verified that a new project has this problem fixed either)

Is it possible this is one of those things they fixed in the “release” libs and not the “debug” libs? Because I’m still running Debug.

Might be time to create a support ticket.

9

I don’t think it is a problem with a fix in the libraries, but there is a problem with patches not copntaining debug libraries so you need to be carefull.

I have searched again but I still cannot find out how I fixed things.

The Uptime counter ultimately relies on using tx_time_get() to determine the time so it is possible to uses calls to tx_time_set() to speed up the timer and then you can try to step through with the debugger

10

Is this fixed? I am experiencing the same problem.

What patch are you talking exactly about?

Arne

11

I haven’t worked on that project in awhile, but after using the Set function to try and debug it, and then removing it my problem seemed to go away. However I probably changed a bunch of other things while I was trying to solve it, so I can’t isolate what caused it.

I’d recommend doing the set route and debugging the tick code near the rollover.

As for the patches, they are on the digi website for NetOS7.3.

12

The NS_TICKS_TO_MILLISECONDS macro overflows at ~12h.

#define NS_TICKS_TO_MILLISECONDS(t) ((1000 * (t)) / BSP_TICKS_PER_SECOND)

I changed the following functions in nsuptime.c to not use the macro and now it is working. I get a simulated uptime of 497 days 2 hours 30 minutes 17 seconds on the status page of the web server.

There is only one problem left: if you don’t call ns_get_uptime_sec() for ~ 490 days the overflow will not be noticed. So just start a timer which will run every 0xFFFFFFFE timer ticks and call ns_get_uptime(), okay make that 0xFFFFFFF0 for safety reasons :-).

unsigned long ns_get_uptime_sec(void)
{
return ns_seconds_from_ticks();
}

static unsigned long ns_seconds_from_ticks(void)
{
unsigned long ticks;
unsigned long secs;

ticks = tx_time_get();
if (ticks < last_ticks) {
    ticks_overflow++;
}
last_ticks = ticks;

secs = (ticks_overflow * (0xFFFFFFFF / BSP_TICKS_PER_SECOND)) +
	(ticks / BSP_TICKS_PER_SECOND);
	
return secs;

}