[SOLVED]Processing to Mega2560 reset problem.

I have written a relatively simple sketch which transfers picture data in RGB565 format over the USB/Serial port between PC and Mega using Processing, also DUE, but the DUE doesn’t have the problem I am about to describe.

There is a small negotiation between host and Mega, then my loadS function looks for ‘IMAGE’ being sent from the host, and then follows the RGB565 data. The sketch on the Mega is basically this :-

void setup()
{
  myGLCD.InitLCD(LANDSCAPE);
  myGLCD.clrScr();

  // Open Serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial) ;
  // wait for Serial port to connect. Needed for Leonardo and DUE
}

void loop()
{
  while (!Serial.available()) ;                  // Wait for Serial activity
  if (Serial.find("HELLO\n")) {                  // Wait for host keyword
    Serial.println("OK");                        // Tell host we are ready
  }
  // loadS(port, x, y, xsize, ysize, buffermultiplier, invert colours)
  // port can be Serial / SerialUSB
  // x , y are the display coordinates
  // xsize , ysize are the expected image dimensions
  // buffer multiplier is used to potentially increase speed a little :-
  //      total buffer size = buffermultiplier * 2 * xsize
  // invert colours is used to swap the MSB/LSB if colour appears wrong
  myFiles.loadS(0, 0, 320, 240, 1 , 0);  // Draw Image
}

The important parts of the loadS function are this :-

int UTFT_SdRaw::loadS(int x, int y, int sx, int sy, int bufmult, bool iswap)
{
  while (!Serial.find("IMAGE")); // Wait for IMAGE command from host
  byte buf[2 * bufmult * sx];
  int cx, cy, cp;
  word result;
  while(!Serial.available());
  if (Serial.available() > 0)
  {
    cbi(_UTFT->P_CS, _UTFT->B_CS);
    cx = 0;
    cy = 0;
    result = bufmult * sx;
    if (_UTFT->orient == PORTRAIT)
    {
      _UTFT->setXY(x, y, x + sx - 1, y + sy - 1);
    }
    for (int n = 0; n < sy; n += bufmult)
    {
      result = Serial.readBytes(buf, ((2 * bufmult) * sx));
|
|
|
| draw to display stuff here.....
|
|
    }
    return 0;
  }
}

The purpose of the exercise is to display pictures on a TFT from computer over Serial. Once the sketch is running on the Arduino, it is supposed to receive an image from Processing, display it on screen until / if another image is sent, hence the gubbins being in loop. This works flawlessly on the DUE both on Native and Programming ports, however, on the Mega EVERY alternate image that is sent, the Mega resets, thus clearing the screen.

So the scenario is this, I upload my sketch to the Mega, it will wait indefinitely until I run the Processing sketch. The Processing sketch scans the available serial ports, the Mega resets when the port is found, the negotiation is performed as mentioned above, the image is slowly rendered to screen, the Processing sketch terminates, and the picture remains on screen.

That is what is supposed to happen.

The next time I run the Processing sketch, the Mega resets, the image is slowly rendered to screen. When the image is complete, the Mega resets.

That is NOT supposed to happen.

So then I run the Processing sketch again, and it works properly, terminating and leaving the image on screen, but the following time and EVERY 2nd time the Mega resets. WHY? ? ? ? >:(

Is there any way in software to prevent the Mega seeing DTR go high? Or is there a way in Processing at the end of the transfer to force DTR to remain low?

This is really irritating as I do not know what else I can try… I have put huge delays in all of the most obvious places to try to delay the reset effect but nothing makes any difference, every 2nd run, the Mega resets at the end of the transfer even though the transfer was successful.

I have even tried, fully closing Processing after the first run, and re-opening Processing, that makes no difference, so I really do not know what is causing the DTR line to toggle or how to prevent it.

I know there is a hardware link I could cut, but it is unreasonable to expect users of my library to cut tracks on their devices…

I would be very grateful to anybody if you have ANY suggestions what I can do.

If there is anybody that has a MEGA with a UTFT display and the UTFT libraries that would like to test this, the latest release is not on Git yet, so I would have to provide you with it via some other method.

Many thanks.

Regards,

Graham

ghlawrence2000:
The next time I run the Processing sketch, the Mega resets, the image is slowly rendered to screen. When the image is complete, the Mega resets.
That is NOT supposed to happen.

I doubt a connection to DTR, this would happen each time.

Without seeing the whole code I could only guess.

Whandall:
I doubt a connection to DTR, this would happen each time.

Without seeing the whole code I could only guess.

Not sure what else you need to see? But I have narrowed it down to Processing.

If I place a huge delay at the end of the data sending routine............ the reset is held off until the end of the delay.

After the 2nd transfer, but during the huge delay, if I manually stop the sketch, the board resets.

What does this tell us? It clearly is a toggle effect somewhere, whether it is a Windows gremlin I have no idea. But I am now stumped.

Regards,

Graham

ghlawrence2000:
Not sure what else you need to see?

What in 'the whole code' is hard to understand?

  • complete Arduino sketch
  • complete Processing sketch
  • links to all non-standard libraries
    As a starter. :wink:

http://www.rinkydinkelectronics.com/library.php?id=51

The Arduino sketches are in the Sd_Raw/examples folder.

The Processing sketch is in the Sd_Raw/Extras/Processing folder.

Git is now up to date, but I have not yet created a new release.

Thanks for your help.

Regards,

Graham

Is the Processing code closing the Serial connection between transmissions. The Mega will reset when the Serial port is opened. This may not happen on the DUE.

...R

With or without port.close() at the end of transmission, the Mega still resets after the 2nd upload.

Regards,

Graham

It works here - without any changes - multiple times without rebooting. :confused:

On Win7 64bit, Processing 3.0b5, Sainsmart Mega & TFT-320x240 shield, soldHouse_320x240.RAW

Just to confirm, you are running Examples\UTFT_SdRaw\AVR\SdRaw_320x240_Serial_Demo.

And uploaded soldHouse_320x240.RAW ?

I have Sainsmart Mega2560, TFT shield, 320x240 TFT, I am using Windows 7 x64 and Processing V3.0b5.

Once the sketch is on the Mega, you just repeatedly run the Processing sketch and you don't have the Mega restarting?

Regards,

Graham

Exactly.

Arduino IDE 1.6.5, no SD-card inserted.

At least we seem to have the same hardware. :wink:

Having a SD-card (8GB) inserted does not make a difference. It just works.

The sketch on the Arduino is 'SdRaw_320x240_Serial_Demo', on Processing 'SdRaw_Serial_Uploader'.

Well thank you so much for your help. I will just have to put it down to ‘one of those things’. But it is a little baffling. I don’t like things beating me, but I can’t fix what isn’t broke…

Regards,

Graham

If you ever need a comparison setup again, you know where to find it.

Maybe there are some subtile differences in the Java setup, that make your setup different.

Ok, thanks for that offer, I may well take you up on it in future ;):P. I have spent long enough today trying to fix this, only to find it is not broken.... That's as far as I am prepared to go.

+1 for your help.

Regards,

Graham

BTW. I tried the smaller image too, shouldn't it be possible to have that displayed correctly,
even if it were necessary to insert 'some' black on the Processing side?

If you mean SKA400400_240x240_inverted_color.RAW ?

Change line 59 to this :wink: :-

myFiles.loadS(0, 0, 240, 240, 1 , 1);  // Draw Image

Regards,

Graham

BTW, have you tried my library as it was intended? Drawing images from SD card? That's where you see the true benefit.

Regards,

Graham

No, I did not try it yet, but I definitely will. :wink: