Task/Process hängt sich scheinbar auf.

1
2
3
4
5
6
Page 1 of 6

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Task/Process hängt sich scheinbar auf.

· Posted: 07.07.2022 - 13:07 · #1

Hallo Leute,

vielleicht hat einer von euch eine Idee.

Ich nutze ein XMEGA384C3 für unsere aktuelle Steuerung.
Hier laufen verschiedene Tasks/Process-Systeme ab.

Wir haben von der Steuerung schon sehr viele im Einsatz, diese laufen ohne Probleme und haben
alle EMV-Tests ohne Beanstandungen bestanden.

Nun haben mir 2 unserer Kunden ein Problem mitgeteilt, bei je einer Steuerung.
Das Display (Soft-SPI) scheint wie eingefroren zu sein, die Steuerung arbeitet aber ohne Probleme ihr Main-Programm ab.

Task/Process-System:

Code

MainProcess (das eigentliche Mainprogramm))

process ControlJobZKS(128, 180 : iData; 1, suspended); // Ausweislesersystem RS485

Task ControlJob(iData, resumed); // USB

Process USB_RxTx (256, 512 : iData ); // USB

process LCD_Displ(256, 384 : iData; 5); // LCD Hauptbildschirm wird oft schlafen gelegt wenn auf Eingabe gewartet wird

process LCD_DisplBott(180, 384 : iData; 5); // LCD Statuszeile unterer Bildschirmbereich

Im Main läuft das Hauptprogramm, die PAE (Prozessabbild der Eingänge) / PAA (Prozessabbild der Ausgänge). Hier wird auch immer der Hardware-Watchdog angetriggert. Sollte sich die Steuerung da irgendwo aufhängen wird ein Reset angestoßen. Somit ist sichergestellt, dass die eigentliche Steuerungs-/Überwachungsfunktion immer läuft.

Da ich dieses Fehlerbild noch NIE hatte, kann ich es nicht richtig einkreisen. Entweder hängt sich das Display auf, die SPI Kommunikation (AVRcoTreiber) oder der Process vom Display/Display-Statuszeile.

Um sicherzustellen, dass der SPI Treiber nicht in 2 verschiedenen Processen auf das Display zugreift, sperre ich immer das Tasksystem während die Daten an das Display gesendet werden:

Code

//-------------------------------------------------------------
// nur die Fußzeile Refresh
procedure DispBottomRefresh;
var
  xDispFor : byte; // Zeile
  xiDispFor : byte;// Spalte
  xiii     : word; // Adresse GraphColArr
begin
  xiii:= 54 * 32;   // Speicher Adresse für Start setzen

  for xDispFor:= 54 to 63 do// Zeile
    LOCK(LCD_DisplBott);  // Lock für Adresse und Zeile
    display_address(0, xDispFor);  // hier Zeile setzen
    for xiDispFor:= 0 to 31 do // Spalte
      DispBW2RGB(GraphColArr[xiii]);  // Daten via SPI an LCD schreiben
      Inc(xiii);
    endfor;
    UNLOCK(LCD_DisplBott); // Nach der kompletten Zeile kann der Process unterbrochen werden
  endfor;

end DispBottomRefresh;

Da ich den Fehler nicht greifen kann, würde ich gerne überprüfen ob sich der AVRco-SPI-Treiber oder das LCD-Display aufgehängt hat. Und wenn ja würde ich hier gerne den Treiber oder das LCD neu initialisieren.

Hat Jemand von euch eine Idee wie man den Treiber oder das Display Checken könnte?
Angenommen ich versuche vom LCD-Treiberbaustein etwas zu lesen und dieser antwortet, dann sollte ja der SPI-Treiber und das Display funktionieren oder? Klar, wenn ich zwischen dem Display und dem Treiberbaustein im Display irgendwas aufgehängt hat, bekomme ich das so wahrscheinlich nicht mit.

Was macht ihr bei sowas? Resetet ihr euere Displays regelmäßig mal?

Gruß
Thorsten

Harry

Moderator

Gender:
Location: zwischen Augsburg und Ulm
Age: 59
Posts: 2090
Registered: 03 / 2003

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 07.07.2022 - 18:27 · #2

Hallo Thorsten,

versteh ich nicht so ganz .... deine Procedure sperrt den Process, aber woher willst du wissen, daß der Process grad dran ist? Ich glaube auch nicht, daß ein Lock(Process) zur sofortigen Ausführung dieses Processes führt. Wenn dann im Process ein Lock(self).

Der eigentliche Refresh (Datenübertragung) passiert im Process? Auch komisch, da der Process auf die Procedure warten muß.

btw "LCD-Display"? Ernsthaft?

Gruss
Harry

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 07.07.2022 - 21:09 · #3

Hallo Harry,

Quote by Harry

...versteh ich nicht so ganz .... deine Procedure sperrt den Process, aber woher willst du wissen, daß der Process grad dran ist? Ich glaube auch nicht, daß ein Lock(Process) zur sofortigen Ausführung dieses Processes führt. Wenn dann im Process ein Lock(self).

Also ich könnte auch genauso gut "Lock(self)" schreiben. Die Procedure wird 1x im Process "LCD_DisplBott" aufgerufen, danach wird mit shedule sofort die restliche Rechenzeit vom Process für die anderen Processe freigegeben. Sobald er die Daten an das Display schreibt lockt er diesen Process und er kann erst nach dem unlock wieder unterbrochen werden. Der einzige Task der ihn unterbrechen kann ist der USB-Task, aber eben nicht beim schreiben der Daten.

Aus Gründen der Lesbarkeit und Übersichtlichkeit schreibe ich immer die Processnamen beim Lock/Unlock.

Quote by Harry

Der eigentliche Refresh (Datenübertragung) passiert im Process? Auch komisch, da der Process auf die Procedure warten muß.

Siehe oben die Procedure wird im Process 1x durchlaufen und fertig. Der einzige Process der frei durchlaufen darf ist der "Main". Bei allen anderen wird am Ende immer mit Shedule die Rechenzeit sofort freigemeldet. Und diese Prozesse haben eine sehr kurze Durchlaufzeit und müssen auch nur 1x durchlaufen werden.

Quote by Harry

btw "LCD-Display"? Ernsthaft?

Ja, LCD Grafik Display 256x64 (Liquid Crystal Display, STN Negative Blue)

Geht von -20 °C bis +70°C, das Display arbeitet mit dem UC1698u Treiber.

Der Controller ist ja eigentlich ein RGB-Controller, das Display macht da aber keinen Unterschied, da es nur eine Farbe hat. Also könnte ich in dem RGB-Daten an einer Stelle imme ein etwas anderes RGB-Muster reinschreiben und es dann wieder auslesen. Bekomme ich hier keine korrekten Daten zurück, setze ich das Display und den UC1698u einfach zurück.

Hat der SoftwareSPI eigentlich eine einfach Möglichkeit ein TimeOut zu verwenden? Oder kann man irgendwie überwachen wenn dieser sich irgendwie mal aufhängt?

Ich weiss halt nicht woran es liegt, da es von einigen hundert Steuerungen jetzt 2x aufgetreten ist, würde ich sowas aber gerne abfangen. Vielleicht ist ja ein Kondensator oder ein Widerstand an der Schnittstelle zum Display knapp an der Grenze der Toleranz.

Thorsten

Attachments


Filename:	07-07-2022_20-54-11.png
Filesize:	8.3 KB
Title:	RGB
Information:	RGB
Download counter:	121

Harry

Moderator

Gender:
Location: zwischen Augsburg und Ulm
Age: 59
Posts: 2090
Registered: 03 / 2003

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 08.07.2022 - 16:20 · #4

Quote

Quote by Harry

btw "LCD-Display"? Ernsthaft?

Ja, LCD Grafik Display 256x64 (Liquid Crystal Display, STN Negative Blue)

Geht von -20 °C bis +70°C, das Display arbeitet mit dem UC1698u Treiber.

Hi Thorsten,

das hab ich anders gemeint .... du schreibst "LCD-Display" ..... da aber LCD Liquid Crystal Display heißt, schreibst du "Liquid Crystal Display Display" ..... ist wie ABS-System oder OBD-Diagnose

.

Gruss
Harry

Avra

Schreiberling

Gender:
Location: Belgrade, Serbia
Age: 53
Homepage: rs.linkedin.com/in…
Posts: 653
Registered: 07 / 2002

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 13.07.2022 - 10:50 · #5

1. Can you check if normal behaviour is restored after power down/up cycle of the board or power down/up of the display? Are you able to do such separate test?
2. Do you overclock your XMEGA?
3. How is display powered? Do you have one power supply for everything or separate? Is grounding proper everywhere?
4. Do you have anything else on your SPI? If not then put something else there that can be visually inspected (GPIO for led, or some peripheral that can be visually inspected) and change it cyclically in your program. That would confirm if SPI works as expected.
5. Can you put some LED on or SERIAL msg out after LOCK(LCD_DisplBott) and UNLOCK(LCD_DisplBott) commands so that you can inspect if those commands have executed properly at the moment of display freeze? That would confirm if LOCK/UNLOCK works as expected and other tasks or interrupts do not interfere.
6. Have you checked if display or some of the components related to it are working within temperature and voltage specification now and in the freezing moment?
7. Do you have some motors or heavy power consumers that can disturb your power source at some moment?
8. Do yours and other related circuit power lines have at least 20-30 cm distance from data lines everywhere? If not possible then do power lines cross data lines at 90 degrees? I do not mean on your PCB but in the cabinet where your circuit is, but also look at the cable that goes to the display or display driver.
9. Do you have a different batch of displays to try?
10. In complex applications for each process I use GetStackFree() and GetFrameFree() so that at any moment I can find out what was the minimal amount of such memory for the life of the application. For the same reason I also use CheckStackValid() and CheckFrameValid(). That can help you to see if there are any related problems with memory amount you reserved. I can share some related code if needed. You might also consider GetProcessState() and MCUCSR.
11. You can also increment in each process/task some process/task specific heartbeat counter, and then at the end of each process - or if that is not possible then cyclically or on demand output to serial all counters (I personally reset them each second so that I know how many times each process is executed per second). That would give you an idea if some process/task is frozen.
12. To completelly avoid locking display (and therefore even theoretical possibility to have problems with sharing display resource), you can put all display data into a record (or separate vars if you want to use LOCKED on vars to protect them) which holds data that needs to be put on display, and then have a single dedicated process which would just display those vars cyclically on the display. You seam to lock the process that handles the bottom of the display, but what if in the middle of the bottom process display, some process starts to update the middle of the display? Maybe at that moment some strange SPI combination sometimes happens that confuses the display and it needs to be restarted. Remember that the whole display is a shared resource that needs access protection, not parts of the display. If you decide to stick with 2 processes accessing display then consider using SetDeviceLock/ClearDeviceLock/TestDeviceLock/WaitDeviceFree.
13. Do you have brown-out protection activated?

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 13.07.2022 - 18:33 · #6

Hello Avra,

Quote by Avra

>> 1. Can you check if normal behaviour is restored after power down/up
>> cycle of the board or power down/up of the display?
>> Are you able to do such separate test?

Unfortunately no, because this error does not occur
in my case, that's why I can't grab or isolate it.

Quote by Avra

>> 2. Do you overclock your XMEGA?

Partially, but adapted to the peripherals, 32MHz and partially 62MHz.

Code

OSCtype = int2MHz, PLLmul = 16, prescB = 1, prescC = 1; // 32MHz f
OSCtype = int2MHz, PLLmul = 31, prescB = 1, prescC = 1, overdrive; // 62 MHz

Quote by Avra

>> 3. How is display powered? Do you have one power supply for
>> everything or separate? Is grounding proper everywhere?

The whole system works with an input voltage of 8V to 32V DC, this is brought to 5V max. 2A by a switching regulator VDRM, with strong / fast capacitors (MLCC). With this 5V the disyplay, extensions and the relays of the controller are supplied. The 5V are brought to 3v3 with max. 1,5A by a LDO TL1963A-33DCYR. This supplies the CPU, MicroSD and 3pcs I2C devices.

Quote by Avra

>> 4. Do you have anything else on your SPI? If not then put
>> something else there that can be visually inspected
>> (GPIO for led, or some peripheral that can be visually
>> inspected) and change it cyclically in your program.
>> That would confirm if SPI works as expected.

No, only the display works on this interface.

Quote by Avra

>> 5. Can you put some LED on or SERIAL msg out after
>> LOCK(LCD_DisplBott) and UNLOCK(LCD_DisplBott) commands
>> so that you can inspect if those commands have executed
>> properly at the moment of display freeze? That would
>> confirm if LOCK/UNLOCK works as expected and other
>> tasks or interrupts do not interfere.

I can do that and increment a counter and output it periodically (RS485).
In the same Process at the end the LOGs are pulled from the PIPE and saved to the SD card.

Quote by Avra

>> 6. Have you checked if display or some of the components
>> related to it are working within temperature and voltage
>> specification now and in the freezing moment?

All components have been tested from -20 to +50 °C, a corresponding test was also made here in a climate chamber at the TÜV, there were no problems here.

Quote by Avra

>> 7. Do you have some motors or heavy power consumers that
>> can disturb your power source at some moment?

These do not run via the switching regulator, these are switched separately with relays mostly these are 24V/DC up to max. 2A.

Quote by Avra

>> 8. Do yours and other related circuit power lines have at
>> least 20-30 cm distance from data lines everywhere? If
>> not possible then do power lines cross data lines at
>> 90 degrees? I do not mean on your PCB but in the cabinet
>> where your circuit is, but also look at the cable that
>> goes to the display or display driver.

The control system is built in such a way that no sensitive wires go out or in from the control system. Of course, there are different wires running in the control cabinet above and below. But all lines and cleanly filtered, run through optocouplers and relays. This was also tested under extreme conditions during EMC testing.

The control system is built on 3 levels.

1st lower level, load, 5V switching regulator, optocoupler inputs.
2. middle level, CPU, RS485, optocoupler, MicroSD, analog inputs and USB
3rd upper level, interface to display, I2C device for buttons and lighting display, RTC and battery.

The levels are provided with ZIFF cables, data lines and 3v3 are provided with ferrite filters. There are GND lines between the sensitive signals.

Quote by Avra

>> 9. Do you have a different batch of displays to try?

I'm getting a new shipment of 200pcs in the next 2 weeks, then I can try another batch.

Quote by Avra

>> 10. In complex applications for each process I use
>> GetStackFree() and GetFrameFree() so that at any moment
>> I can find out what was the minimal amount of such memory
>> for the life of the application. For the same reason
>> I also use CheckStackValid() and CheckFrameValid().
>> That can help you to see if there are any related problems
>> with memory amount you reserved. I can share some related

I use this in my controller as well, so I can monitor if there was an overflow somewhere or if I'm running low. But that's not the case here.

Quote by Avra

>> code if needed. You might also consider GetProcessState()
>> and MCUCSR.

I'll take a look at that, I don't currently use that.

Quote by Avra

>> 11. You can also increment in each process/task some
>> process/task specific heartbeat counter, and then at
>> the end of each process - or if that is not possible
>> then cyclically or on demand output to serial all counters
>> (I personally reset them each second so that I know how many
>> times each process is executed per second). That would
>> give you an idea if some process/task is frozen.

I already use this approach with the Main process and am already incorporating this into the others.

Quote by Avra

>> 12. To completelly avoid locking display (and therefore
>> even theoretical possibility to have problems with sharing
>> display resource), you can put all display data into a
>> record (or separate vars if you want to use LOCKED on vars
>> to protect them) which holds data that needs to be put on
>> display, and then have a single dedicated process which
>> would just display those vars cyclically on the display.
>> You seam to lock the process that handles the bottom of
>> the display, but what if in the middle of the bottom
>> process display, some process starts to update the middle
>> of the display? Maybe at that moment some strange SPI
>> combination sometimes happens that confuses the display
>> and it needs to be restarted. Remember that the whole
>> display is a shared resource that needs access protection,
>> not parts of the display. If you decide to stick with 2
>> processes accessing display then consider using
>> SetDeviceLock/ClearDeviceLock/TestDeviceLock/WaitDeviceFree.

All graphics data is prepared in memory by the driver and then updated in the status/lower part in one piece. In the upper part, a whole line is always written before it can be interrupted.

Both processes main screen and status line, can't be interrupted while writing, for that these are lock()/unlock().

Quote by Avra

>> 13. Do you have brown-out protection activated?

Yes, in the AVRco "FuseBits5 = [BodLevel0, BodLevel2, BodAct0, EESAVE];// 2.6V: " and I use an external watchdog "TPS3823-30DBVT", which ensures that if the voltage is too low the CPU is held in reset.

My problem is here at the moment, I don't have this error here. I can not cause him either, the in the DisplayStatus Process also the logbooks are written to the SDCARD, I have here first set the speed to "fast" instead of "superfast". And I have built counters into the processes. I must try to detect a possible failure somehow, so that I can simply restart the SPI or the display.

I have been running one of our controllers 24/7 with a simulator for days, it simulates about 5,000 runs within 24h. Including all necessary loads on the system. Until now, the controller did not even show this problem.

Tomorrow I will connect one of the other controllers of the batch to the simulator and run it as well.

Thorsten

pvs-deck

PowerUser

Gender:
Age: 53
Homepage: pvs-deck.de
Posts: 1340
Registered: 02 / 2009

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 14.07.2022 - 18:20 · #7

Hallo Leute,

ich bin verwundert evtl. kann mir das mal Jemand erklären.
ich habe in jedem Task/Prozess eine Variable eingefügt und mit inc() entsprechend hochgezählt. Im Sekundentakt wird diese Zahl dann über die RS485 ausgegeben und danach wieder auf 0 gesetzt.

Wenn ich jetzt bei einem Systick von 10 ausgehe (10ms) reden wir von max. 100 Taskaufrufen in der kompletten Summe. Es wird bei mir evtl. etwas höher liegen da ich viel mit shedule arbeite.
Aber diese Zahlen können doch gar nicht sein (siehe Bild)!

Code

Main // Prio 5
Task ControlJob(iData, resumed); // Prio 5
Process USB_RxTx (256, 512 : iData ); {Stacksize = 256 bytes, Framesize = 256 bytes}// Prio 3
process LCD_Displ(256, 384 : iData; 5); {Stacksize = 256 bytes, Framesize = 512 bytes, 5 Systicks}
process LCD_DisplBott(180, 384 : iData; 5); {Stacksize = 256 bytes, Framesize = 512 bytes, 5 Systicks}
process ControlJobZKS(128, 180 : iData; 1, suspended); // War 256, 512

Habe ich ein Verständnisproblem mit dem Tasksystem und deren Aufrufe?

Ich habe Heute auch den ganzen Tag eine andere Steuerung aus der Charge am laufen, bereits mehrere tausend Simulationen ohne auch nur einen einzigen Fehler.

Thorsten

Attachments


Filename:	14-07-2022_17-59-09.png
Filesize:	22.56 KB
Title:	TaskAusgabe
Information:	TaskAusgabe
Download counter:	76

Merlin

Administrator

Gender:
Age: 24
Posts: 1373
Registered: 03 / 2005

Subject:

Re: Task/Process hängt sich scheinbar auf.

· Posted: 15.07.2022 - 10:41 · #8

Without seeing your code it is difficult to assess, but processes loop so it is likely that a process will increment several times per call, but equally it is possible that several calls are required for a single increment. Tasks exit on completion so they will only increment once per call. So your approach makes sense for tasks, but probably not for processes. But also note that tasks can exit and restart without completing, whereas processes do not.

1
2
3
4
5
6
Page 1 of 6

Task/Process hängt sich scheinbar auf.

Attachments

Attachments

Registered users in this topic