@TJO: I will share some contact details with you privately. In the mean time we will setup up a long term test with the I2C test application we wrote on our side, so far we run the tests only for a few hours.
Possible to get you E-mail to send the needed datasheet for display/touch connections?
I tried disable the DFS and fix the CPU frequency at 400 MHz, but the module eventually runs to hot.
The other values (EMC, AHB, SYS etc) are set to 100% when DFS is disabled. I guess that’s way the module runs to hot. I also tried dismantling the housing so the module got some free air. Stills runs to hot with DFS disabled.
And it seems I cant fix the other frequencies for AVP, EMC etc with the task manager…
So I cant test it with DFS disabled…
PS: Tried on a free on desk Iris Carrier board. Stills runs hot and reboots
Do you have any kind of a fan? This helps quite a lot normally. Just send us the datasheet on our email support channel.
Maybe a Fan works. But that would be difficult to do with unit in production.
They have to remove the housing and install some ventilator during the calibration and testing during production.
I will try to see if we can do that with some of the unit when produced.
But if that gives us enough units to conclude anything from I don’t now. Maybe we just where lucky.
Of cours that is not a final solution but only to test if we can eliminate the issue by switching off the DFS. I expect the display may still fails but the system should not crash any longer.
I have run some test on a unit that had one Touch stall, where I disabled DFS and fixed the speed to 400 MHz. I managed to open the cabinet and attach a FAN so it don’t run hot.
I has so far (5 days) not had a Touch stall. But I don’t know if we can conclude anything. Maybe we just are lucky.
How are the progress at you end? Have you received the display and does it work??
@TJO: On the current setting you also have a touch and it the touch is still running after 5 days?
The touch arrived here last week. I want to to have similar setup as you have. Do you have an adapter to connect it to the irs?
Yes the touch is still working on my test setup.
Sounds good the display did arrive.
I do not have an adapter to connect it, Maybe the 4 wire can be solered on to a connector that fits?
@TJO: Ok, we will build a connector on our side. Just to make sure again: In the current setup as well as in the setup where the stuff fails there was nothing else than our standard image runngin: No additional tool from you, no communication over I2C or any other peripheral?
Our application is running on the units. It don’t know if we have seen it on a unit running without any application. That we do not do very often.
We don’t have the luxury to take away 10 station, remove the application and then let them be for 1 day or 2. So that is not a test we have done yet.
The issue do happen rarely and they may see it only once or twice day on some of the units.
I must add, that the application has been running on our older platform, that used the PXA320 module, for many years. (+6 years).
Our application is made in C# and uses the CAN library on a SJA1000.
the Ethernet may also be connected but it have been seen on station with and without Ethernet connection.
@TJO: I think we found out some more. Due to the high priority which is set in SJA1000 library for the CAN handler, we get stuck with with the I2C communication. We see two ways to get this fixed. Reduce the thread priority of the CAN thread. Depending on the ammount of packages and the size of them, this may could cause that some packages are lost. You could try to tweak this with the Toradex Task Manager: Click in the Process List to your application that does the SJA communication. If you click on it, you see some threads listed bellow. Find the one that has priority 1. Right click on the thread and set the priority to LOW. Do you lose any packages like this?
That great news.
Our CAN thread to have a high priority. It is actually boosted in the code. as I remember it was so we didn’t loose any packets.
I will try some test with lower thread priority to see how the communication does work. We are a bit sensitive about lost packets. (Specially where we do set some outputs on modules on the CAN bus).
But I will try with normal thread priority to see how the station manage.
I have tried to change the priority to LOW.
I will leave it running the next couple of day to see if I have any lost packages.
I have tried running with the SJA thread set to low priority. It seems to be working without packet loss.
I would like a bigger scale for testing and try to run unit during production with this lowered priority.
Is it possible to get a new CAN lib with a lower thread priority I can use for further testing?
I built a SJA CAN lib with thread priority 254. You can get it from here.
Let us know if this helps. If so, we will do further investigations to prevent these kind of situations. Lowering the priority is only one way, we probably have to improve also some parts in the OS itself to prevent such a situation.
Possible to get it made for WEC7 (Toradex_CE600 (ARMv4I))??
I’m running with WEC7 because our current application is build for that and it is easier to test with it.
With the new SJA CAN lib we do get some CAN communication error from time to time.
So the lower priority to result in some timeouts and missed packages
We haven’t used it on so many unit currently to say something about the HMI stall.
Would it be possible to generate a new SJA CAN lib with priority 100 or something in between?
@TJO: We did already some tests with other priorities, everything we do there probably shifts the problem. We created an issue and plan to solve the root of this issue for the next beta release. It is planned in Q4 2018. As far as I understand your schedule is tight. Would it be to late if you have a fix end of Q4?