Tiny Core Base > TCB Talk
Re: Tiny Core v17.0 upgrade issues
Stefann:
On configuration of the cable,
Probably easiest if I just share my "init code".
It's probably a bit dirty. I was learning the technology while doing the job.
It's a combination of code I grabbed from the internet with personal additions.
so.. baudrate is 11520
After this initialisation I just read the output.
The "temp" is a data structure I use for temporary results.
--- Code: ---int start_meter(char * dev)
{ struct termios pts = { 0 }; /* termios settings on port */
int fd;
/* some things we want to set arbitrarily */
pts.c_lflag &= ~ICANON;
pts.c_lflag &= ~(ECHO | ECHOCTL | ECHONL);
pts.c_cflag |= HUPCL;
pts.c_cc[VMIN] = 1;
pts.c_cc[VTIME] = 0;
/* Standard CR/LF handling: this is a dumb terminal.
* Do no translation:
* no NL -> CR/NL mapping on output, and
* no CR -> NL mapping on input.
*/
pts.c_oflag |= ONLCR;
pts.c_iflag &= ~ICRNL;
/* set hardware flow control by default */
pts.c_cflag |= CRTSCTS;
pts.c_iflag &= ~(IXON | IXOFF | IXANY);
/* set 9600 bps speed by default */
// cfsetospeed(&pts, B9600);
// cfsetispeed(&pts, B9600);
cfsetospeed(&pts, B115200);
cfsetispeed(&pts, B115200);
temp.E_night = -1.0;
temp.E_day = -1.0;
temp.E_rnight = -1.0;
temp.E_rday = -1.0;
temp.E_power = -1.0;
temp.E_rpower = -1.0;
temp.E_id = -1.0;
temp.gaz_time_sec = -1.0;
temp.gaz_count = -1.0;
fd = open(dev, O_RDWR);
if (fd>=0)
tcsetattr(fd, TCSANOW, &pts);
return fd;
}
--- End code ---
Stefann:
Update,
After 48hrs it was still running under TC17 with extra bootcode "usbcore.autosuspend=-1"
Logging at *.notice level but not much in logging. Only some application logging I made myself and some crontab-launches.
I stopped all manual.
I will be travelling April 2-10 during which period I cannot risk a crash.
So.. I reverted back to TC15 and restarted.
That gives me a few days of run hopefully without crash.
The thing did run for multipel month without crash before I started my upgrade work so in principle it should run without crash now.
However... there is always the possibility that during the upgrade I did something "TC17 unrelated" that is causing all this. So in itself this should also give confirmation that TC15 is stable.
Target to run until April 10...11.
Note...
On the positive side..
It's extremely convenient that going back to earlier release is as simple as:
- modify tce/boot/extlinux/extlinux.conf to pick the older core.gz and vmlinuz (I did not overwrite them but kept old version as core15.gz and vmlinuz15)
- rename tce/optional directory to get the previous one back (yes I made a backup :-)
- modify tce/onboot.lst to include correct kernel extension for usb-serial
try that with windows.......
unless I get a crash: dont expect to hear form me until April-11
in the mean time: any smart idea is welcome. I will not have access to my tinycore system but travel with laptop so will check this forum regularly.
Stefann:
Hickup when I restarted on TC15,
I thought it was running (all gets started automatically all seemed up) but I noticed that the state did not change.
Better checking revealed:
- yes TC15 was running
- but my application was not
Starting it from the command line gave me:
--- Code: ---tc@huis:/krubo/work$ /krubo/work/krubo /krubo/work/1wire.def
/krubo/work/krubo: /lib/libc.so.6: version `GLIBC_ABI_GNU_TLS' not found (required by /krubo/work/krubo)
/krubo/work/krubo: /lib/libc.so.6: version `GLIBC_2.42' not found (required by /krubo/work/krubo)
--- End code ---
What I did:
- completely recompiled my application on TC15
- restart
now all works.
Which makes me thinking:
- I probably need to do that on TC17: "completely recompile the application"
Anyway... I now want to run the thing "crash free" for upcoming days to allow me a headache-free travel April 2-10
Paul_123:
We update Glibc every release, For the most part Glibc is backwards compatible. So there should be no reason to recompile when moving from 15->17.....but if you compiled under 17, then it will not work on 15.
Note that we keep referencing the Serial USB interface, but it could be any of them. Now that you have logging figured out, it might be useful to set it so that it does crash, to hopefully verify the reason for the crash.
Stefann:
Yes I will “set it up to crash”.
But first travel between April 2-10 running on TC15.
IF it crashes I will notice that as the system runs an Apache webserver that is available from outside.
My brother lives nearby and could than give it a manual reset.
The fricky thing is that “the full OS crashes”. No way to reset from outside.
My application has a watchdog around it. If that crashes it gets a restart after 15 minutes.
When I get back to “let it crash” I will also search my vga-monitor and keyboard that I have somewhere at the attic for exactly this reason.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version