I've got an PXA255 Intel ARM processor from 'arcom' (Viper board fromIt is running embedded linux slightly modified for their viper board. specifically
uname -a Linux bluebox 2.4.21-rmk1-pxa1-arcom1-2-viper #1 Tue Feb 10 15:33:52 GMT 2004 armv5tel unknown
I'm getting what appears to be serial port lockups with this and I'm wondering if, after reading my symptoms below, anyone can give me some pointers into solving this.
Basically I have a application that resembles a glorifed PLC/Telemetry system. It uses seperate threads that act as "PORTS" which use serial ports to connect to the outside world. Generally this includes engine managment systems, FSK radio modems, GPS and Touch screen.
The touchscreen is an intelligent device in that you program it with screens, it has memory etc. and it polls our program to find out what screen it should be displaying etc.. This is via RS232.
In production our application runs on bootup and any configuration changes you download into it force a restart of the application (Not the hardware). So our application on starting opens up serial ports uses them and then restarts, opening them up again.
After a few restarts of the application I noticed that, for example, the touchscreen would stop communicating, I thought well maybe its because we arent cleaning shutting down the serial ports, so I implemented that. (Please note that this application was previosuly running on a standard linux kernel on a PII celeron based system and worked fine). This didnt seem to solve anything.Resetting the hardware fixes the issues and the serial ports work fine again until you stop and start the application a number of times.
So I looked deeper.
When the application is running /proc/interrupts showns the serial ports interrupt numbers as normal and when the serial port is working that interrupt value is increasing when commands come in from the touchscreen. Once the serial ports lock up, that number stops incrementing.
I then plugged an RS232 LED debugging device onto the cable going to the touchscreen so I could confirm that the signal is in fact polling the application. And it is. Once the serial ports lockup the touchscreen can be seen to periodically poll the device. A digital CRO also confirmed this.
Can anyone suggest anywhere to look in the kernel or something so I can find out the cause of the problem? Any suggests would be most welcome.