Gen4-uLCD-70 and Atmega2560 lag and reset problem

[matrixgta]

Hi Guys, I have a problem on a project i'm working on.

The board is based on an Atmel2560 (arduino Mega like) programmed as a standard arduino board with arduino IDE, the board has multiple sensor onboard and an SD card to log some activity. The LCD ( Gen4-uLCD-70 ) is connected directly to the Serial3 of the micro.
Everything works good but if for some external reason I lost the power supply of the uLCD I face a lag on the loop of about 3000 ms and i'm not able to recovery this lag, even forcing a new reset "on the fly" will cause the micro to reboot.
The problem occurs after some time of working, sometimes minutes, sometimes hours, but I'm able to replicate it by force a glitch on the serial line or a power cycle on the +5v of the display.

I try catch the lag with this code but will cause unexpectedly the 2560 to reset, after reset everything work again but of course I loose the running data and logs.

timerled = millis() - currentMillis ;  // Calculate looptime in ms


if (timerled > 1000 && millis()-last_reset > 15000 ){   // if I face a Lag > 1 sec try reset the display in 15 sec shedule
  
last_reset = millis();

  digitalWrite(lcd_reset, 0);        // Reset the Display via D30
  delay(100);
  digitalWrite(lcd_reset, 1);        // unReset the Display via D30

  delay (5000);                           //let the display start up
  
}

the question is if there is a way to catch a timeout on uLCD comunication that will non block the code and try a reset of the uLCD, like in case of a power glitch that will reset the display but not the 2560.

The whole code is very long and articulated but I think is not involved in this problem.

Sorry for my bad English and thanks for any help

Flavio

[matrixgta]

****UPDATE

I try editing the genieArduino Library in genieArduino.h

#define TIMEOUT_PERIOD 100
#define RESYNC_PERIOD 100

lowering the timeout period to 100 ms the loop not freeze , if I give back power to the uLcd within 5 seconds I'm now able to recovery from failure, after that time the micro reset as before, I think there is another counter or timeout function involved in the library that cause the reset

#define MAX_GENIE_EVENTS 16 // MUST be a power of 2
#define MAX_GENIE_FATALS 10

Maybe this FATALS are a counter for timeout strikes ?

[John Kevin]

Hello Flavio,

Welcome to the forum!

The 'lag' issue that you experienced when an interruption (e.g power)
occurs is due to the buffered data on the library that is not yet released
which continuously sends data without confirming if the display is still
connected.

Reducing the timeout period works but if the interruption occurs
frequently the lag 'issue' may still arise.

A beta library is produced to fix this issue, although it is not yet
an official release and is still in the process of improvement you can
try and see if the 'lag' issue when an interruption occurs will be resolved.

You can find the beta version here

I hope this helps.
Best regards,
Kevin

[matrixgta]

Hello Flavio,

Welcome to the forum!

The 'lag' issue that you experienced when an interruption (e.g power)
occurs is due to the buffered data on the library that is not yet released
which continuously sends data without confirming if the display is still
connected.

Reducing the timeout period works but if the interruption occurs
frequently the lag 'issue' may still arise.

A beta library is produced to fix this issue, although it is not yet
an official release and is still in the process of improvement you can
try and see if the 'lag' issue when an interruption occurs will be resolved.

You can find the beta version here

I hope this helps.
Best regards,
Kevin

Hi John, Thanks for the reply, I had no time to try the beta library but I make this mod on GetLinkState() in the official one and it works like a charm even with long "display no power" maybe this can help you better debugging the future official release:
In my loop I catch the timeout event and if true I reinizialize the display with genie.begin(Serial) and serial.flush() commands, In this way I'm able to recovery from serial or power supply issue without permanently lag the rest of the code.

    switch (GetLinkState()) {
        case GENIE_LINK_IDLE:
            switch (c) {
                case GENIE_REPORT_EVENT:
                    // event frame out of the blue, set the link state
                    // and fall through to the frame-accumulate code
                    // at the end of this function
                    PushLinkState(GENIE_LINK_RXEVENT);
                    break;

                case GENIEM_REPORT_BYTES:
                    magicByte = 0;
                    PushLinkState(GENIE_LINK_RXMBYTES);
                    break;
   
                case GENIEM_REPORT_DBYTES:
                    magicByte = 0;
                    PushLinkState(GENIE_LINK_RXMDBYTES);
                    break;

                default:
                    // error, bad character, no other character
                    // is acceptable in this state
                    return GENIE_LINK_IDLE;                                             //on error loop IDLE for non blocking code than catch the timeout  -- MOD -
            }

[John Kevin]

Hi Flavio,

Thank you for coming back at us.

We will surely check your provided solution
Thank you for sharing your knowledge.

Best Regards,
Kevin

[matrixgta]

Hi Flavio,

Thank you for coming back at us.

We will surely check your provided solution
Thank you for sharing your knowledge.

Best Regards,
Kevin

Hi Kevin,
I can confirm you that my mod on the original library work good, I test it for several hours debugging my code and I had no further lag problem, I count the times it strike to timeout and recovery and seems to be cyclic in time but not seems to be related to instructions sended by my software. semms to be more related to the user touch activity (I.e. move fast up and down a slider bar or touch two buttons alternatively fast ). Anyway with UART TTl and distance from micro to the display I can't go over 115200 and if this problem is related to the serial buffer limit I wold like to ask you if there is problems on converting TTL to RS422 along the cable and then again RS422 to TTL near the uLCD to try to go faster in serial baud rate.
The second question is about a strange behavior of the slider bar thet happened randomly, I have a slider setted in the GUI from 0 to 3000 , if I move the slider up and down in mid position everythings work ok, but If I slide to 0 quickly and the finger pass the bottom of the slider (that is vertical) sometime I face the error on the object, It disappear and I see only the boundary in red with a cross line, If I touch again in some other point of the slider It return working, this error did not occour every time, I did not find any relation with other objects in my layout and with my software, as I only read the value of the slider but I have no routine to set a value back to the slider.
Is there some bug related to a slieder with Min value set to Zero ?

Thanks for your support and patient :P

Flavio

[John Kevin]

Hello Flavio,

I can confirm you that my mod on the original library work good, I test it for several hours debugging my code and I had no further lag problem, I count the times it strike to timeout and recovery and seems to be cyclic in time but not seems to be related to instructions sended by my software

Again thank you for your contribution. We appreciate you for taking your time to look into our library and through giving us your feedback. If you'd like you can post here a step by step procedure on how you solved the problem which can also be beneficial to others.

The second question is about a strange behavior of the slider bar thet happened randomly, I have a slider setted in the GUI from 0 to 3000 , if I move the slider up and down in mid position everythings work ok, but If I slide to 0 quickly and the finger pass the bottom of the slider (that is vertical) sometime I face the error on the object, It disappear and I see only the boundary in red with a cross line, If I touch again in some other point of the slider It return working, this error did not occour every time, I did not find any relation with other objects in my layout and with my software, as I only read the value of the slider but I have no routine to set a value back to the slider.

Upon changing the minimum and maximum value of the slider, have you build again the graphics of your project? Usually the error on the object (boundary in red with a cross line) occurs when the value of the widget exceeded the specified range that you set.

If you'd like, you can also attach a sample video where the problem starts to occur.

I hope this helps.
Best Regards,
Kevin

[matrixgta]

If you'd like, you can also attach a sample video where the problem starts to occur.

Hi Kevin, I attach a video of the slider problem and a print screen of the Visi_Genie setup for that object , I rebuild the graphic just before the test and the display is only powered up (no serial connection with Pc or my atmel board)

[John Kevin]

Hello Flavio,

The error is due to the overflow of the computation which is processed on the mapping function. The variables on 4DGL is signed 16 bit. Due to
a large number of frames, the computation exceeds the 16 bit which results on the image error of the slider widget.

On ViSi Environment, you can check a sample computation by using the paste code on the slider widget.

You can try to lower the frames on your slider widget and map the values on your microcontroller.

I hope this helps.

Best Regards,
Kevin