www.beck-ipc.com
www.beck-ipc.comwww.beck-ipc.com  | ImprintImprint
FAQFAQ  | SearchSearch  |
  |LoginLogin

network services pb

Questions and discussions about the operating system RTOS and the corresponding C-LIB.

network services pb

Postby Pierre » 03.03.2020, 16:15

I run on sc23/24 (RTOS 1.90..2.04) a C++ program who reads datas on serial line, and serve these datas on several network protocols (TCP, UDP, HTTP). And after some time (from few minutesr to 1 day) , i lose all the network services!
But my program seems to continue running in the SC23/24, because the watchdog doesn't restart it, and serial communication runs always...
Then, the only way i have to communicate again with the SC23/24 is to reboot it manualy.
How can i debug this problem ???
thanks
Pierre

Re: network services pb

Postby Jack Gatrost » 05.03.2020, 17:13

You might try monitoring the situation with the TCPIPMEM console command.

Code: Select all
A:\>tcpipmem

Reserved TCPIP memory: 143360 bytes, used 36962 bytes
Number of sockets    : 10 used, 246 available

A:\>


If the TCP/IP resource situation deteriorates with time, then a resource leak in your program could explain the network services loss.

The CV "Code Verify" console command can be used to make sure that your software has not accidentally overwritten some of the RAM resident sections of the @Chip-RTOS.

If still no clues are found as to the problem, you could start to turn off some of your program's functionality in search for the part of the program whose execution brings on the problem. A binary search done in this manner can often narrow down the problem.
Jack Gatrost
Software Development
Beck IPC GmbH

Re: network services pb

Postby Pierre » 06.03.2020, 14:37

ok i've tried.

i had once
Code: Select all
A:\>cv
@Chip-RTOS code verified: All 755712 bytes RAM match flash image
IVT[19] was 0237:08B0, is now 0237:08D8


what is IVT ? an interruption service ?

Re: network services pb

Postby Jack Gatrost » 06.03.2020, 15:50

The CV report shows that one entry in the system's Interrupt Vector Table has changed. This is not unusual, and this does not generally indicate any problem.

The IVT[decimal 19] is IVT[0x13] which is the Timer #2 hardware interrupt vector. These vectors are documented here: https://www.beck-ipc.com/api_files/scxxx/program.htm#System

The Timer #2 is used internally by the @Chip-RTOS to provide its 1000 Hz heart beat. One thing that will cause a change of this vector is to use the task monitoring command at the console.


The HAL API
Code: Select all
hal_install_isr()
does not change this Timer #2 vector (contrary to what I posted earlier).

So this guess at what to look at did not help. Did the TCPIPMEM command also show no problems?

Turning off sections of your program to investigate when the problem appears would be the last resort that I can think of. When the problem takes a long time before it appears, that always makes for a tiring search.
Jack Gatrost
Software Development
Beck IPC GmbH

Re: network services pb

Postby Pierre » 09.03.2020, 11:15

Did the TCPIPMEM command also show no problems?

no, the only thing that i notice is, when I stop normaly my program and restart it again the used TCPIP memory increase by a 'random' value.
Yet it seems to me that i free all allocated memory when exiting...

Re: network services pb

Postby Jack Gatrost » 09.03.2020, 18:28

Does the number of sockets reported by TCPIPMEM remain steady as you exit and restart your program several times?
Jack Gatrost
Software Development
Beck IPC GmbH

Re: network services pb

Postby Pierre » 10.03.2020, 10:00

This is another strange thing, TCPIPMEM does not report any open socket, even i'm getting data upon tcp on the sc23...

Code: Select all
A:\>tcpipmem
Reserved TCPIP memory: 143360 bytes, used 71630 bytes
A:\>

Re: network services pb

Postby Jack Gatrost » 10.03.2020, 10:18

Now I see that the socket usage report was something that was added to the TCPIPMEM command back in year 2018. So the latest @Chip-RTOS version V2.05 would be required in order to view this information.

In general, maybe it would be a good idea to test with the latest @Chip-RTOS version.
Jack Gatrost
Software Development
Beck IPC GmbH

Return to RTOS


Who is online

Users browsing this forum: No registered users and 1 guest


cron