keeps looping setup [closed] [not solved]

This program keeps looping Setup part. But if i remove the line

char *rcv=encandenc(bu);

then program works perfectly. I need this line for encryption purposes.
Everything works fine but i need encryption so i added function and just this *rcv=encandenc(bu); line and code starts looping in setup. But if i comment this line everything works fine.

void setup()
{
  Serial.begin(9600);
  if (gsm.begin(9600))
  {
    Serial.println(F("\nstatus=READY"));
    started = true;
  }
  else
  {
    Serial.println(F("\nstatus=IDLE"));
  }
  delay(300);
};


void loop()
{
  char *rcv = encandenc(bu); // if i comment this line then program works totally okay but i want this line for later use
  delay(1000);
 };

char *encandenc(char * bu)
{
  CBC<AES128> cbc;
  uint8_t key[16] = {97, 115, 100, 102, 103, 104, 106, 107, 108, 112, 111, 105, 117, 121, 116, 114}; //asdfghjklpoiuytr
  uint8_t iv[16]  = {113, 119, 101, 114, 116, 121, 117, 105, 111, 112, 108, 107, 106, 104, 103, 102}; //qwertyuioplkjhgf
  uint8_t input[96];
  size_t len = 16;
  memcpy(input, bu, 96);
  delay(1000);
  cbc.setKey(key, 16);
  delay(1000);
  cbc.setIV(iv, 16);
  delay(1000);
  cbc.encrypt(input, input, 96);
  delay(1000);
  cbc.clear();
  int inputLen = sizeof(input);
  int encodedLen = base64_enc_len(inputLen);
  char encoded[encodedLen];
  base64_encode(encoded, input, inputLen);
  delay(1000);
  return encoded;
}

alforhad:
This program keeps looping Setup part. But if i remove the line char *rcv=encandenc(bu); then program works perfectly. I need this line for encryption purposes.

Something in that function must be causing data corruption (perhaps writing past the end of an array) and causing the Arduino to reset.

What does CBC cbc;do? It looks like the sort of thing that should be at the top of the program so it only happens once

...R

Robin2:
Something in that function must be causing data corruption (perhaps writing past the end of an array) and causing the Arduino to reset.

What does CBC cbc;do? It looks like the sort of thing that should be at the top of the program so it only happens once

...R

Its for AES encryption class. Moved it to top still looping setup

A couple of suggestions:

  1. Stop using the String class. Eventually, it is going to cause you problems, especially when it comes time to debug them. Some of the C string processing functions can be found here.

  2. Before you post your code, place the cursor in the source code window and press Ctrl-T. This will reformat your source code into a more readable format.

  3. Using a loop to copy things can often be simplified. For example, your code:

  for(int i=0; i<96; i++){
    input[i]=bu[i];
  }

could be wrtten as:

  • memcpy(input, bu, sizeof(input));*

The link above explains how memcpy() works.

updateString.toCharArray(bu,updateString.length()+1);

The second argument to toCharArray() has NOTHING to do with the length of the stupid String. It is the size of the array.

econjack:

  1. Stop using the String class.

I had not spotted that as it does not appear in the function the OP mentioned. Looks like the problem is not where he thought it was. Quelle Surprise!

...R

econjack:
A couple of suggestions:

  1. Stop using the String class. Eventually, it is going to cause you problems, especially when it comes time to debug them. Some of the C string processing functions can be found here.

  2. Before you post your code, place the cursor in the source code window and press Ctrl-T. This will reformat your source code into a more readable format.

  3. Using a loop to copy things can often be simplified. For example, your code:

  for(int i=0; i<96; i++){

input[i]=bu[i];
  }




could be wrtten as:

* memcpy(input, bu, sizeof(input));*


The link above explains how *memcpy()* works.

Check my updated code.
I stopped using Shring Class.
Still same problem

PaulS:

updateString.toCharArray(bu,updateString.length()+1);

The second argument to toCharArray() has NOTHING to do with the length of the stupid String. It is the size of the array.

I totally removed string part, check my code.
Still same problem exists.

Robin2:
I had not spotted that as it does not appear in the function the OP mentioned. Looks like the problem is not where he thought it was. Quelle Surprise!

...R

Where is the problem? I stopped using string class check my updated code but still same problem

Where is the problem?

Since you replaced the code in the first post, making all of us that commented on it look like fools, where is our motivation to help you?

How much memory does this thing say it uses when you compile? Running out of memory can look like a reset.

Taking out one line which references a variable may cause the compiler to optimise that variable out of existence so memory is not filled.

[Edit: fix fruity typo.]

PaulS:
Since you replaced the code in the first post, making all of us that commented on it look like fools, where is our motivation to help you?

Sorry I didn't get it. I thought it will be helpful for you.

MorganS:
How much memory does this thing say it uses when you compile? Running out of memory can look lime a reset.

Taking out one line which references a variable may cause the compiler to optimise that variable out of existence so memory is not filled.

Global variables use 1404 bytes (68%) of dynamic memory, leaving 664 bytes for local variables.

alforhad:
Sorry I didn't get it. I thought it will be helpful for you.

It would be helpful if you posted your updated code in a new post in this thread instead of updating the existing code in the opening post. Now some (or all) of the comments people posted no longer make sense.

sterretje:
It would be helpful if you posted your updated code in a new post in this thread instead of updating the existing code in the opening post. Now some (or all) of the comments people posted no longer make sense.

Okay, sorry for my mistake and I already replaced it so I don't have my previous code. I just used char array instead of string in this new code but still same problem.

MorganS:
How much memory does this thing say it uses when you compile? Running out of memory can look lime a reset.

@OP
Add the size of the variables declared in loop() (about 70 bytes) to what is reported.
As loop() calls encandenc(), add to the reported size the size of the variables used in encandenc() (about 130 bytes) as well.

That's a total of 200 bytes extra; if you're running this on a 328 based micro (e.g. uno or nano) with 2k RAM, and the sum adds to around 1400 bytes or more, you probably have the culprit. I don't have all your libraries so can't compile your code.

char *encandenc(char * bu)
{
  CBC<AES128> cbc;
  uint8_t key[16] = {97, 115, 100, 102, 103, 104, 106, 107, 108, 112, 111, 105, 117, 121, 116, 114}; //asdfghjklpoiuytr
  uint8_t iv[16]  = {113, 119, 101, 114, 116, 121, 117, 105, 111, 112, 108, 107, 106, 104, 103, 102}; //qwertyuioplkjhgf
  uint8_t input[96];
  size_t len = 16;
  memcpy(input, bu, 96);
  delay(1000);
  cbc.setKey(key, 16);
  delay(1000);
  cbc.setIV(iv, 16);
  delay(1000);
  cbc.encrypt(input, input, 96);
  delay(1000);
  cbc.clear();
  int inputLen = sizeof(input);
  int encodedLen = base64_enc_len(inputLen);
  char encoded[encodedLen];
  base64_encode(encoded, input, inputLen);
  delay(1000);
  return encoded;
}

Why do you think returning the address of a local buffer will work (reliably)?

I don't think the local copy of the passed string is neccessary.

What are the delays for?

If RAM is a problem, there are many constant strings that could be moved to PROGMEM only.

sterretje:
@OP
Add the size of the variables declared in loop() (about 70 bytes) to what is reported.
As loop() calls encandenc(), add to the reported size the size of the variables used in encandenc() (about 130 bytes) as well.

That's a total of 200 bytes extra; if you're running this on a 328 based micro (e.g. uno or nano) with 2k RAM, and the sum adds to around 1400 bytes or more, you probably have the culprit. I don't have all your libraries so can't compile your code.

I am running UNO.
If it is causing problem how to solve it?? I have no idea about optimizing library

Whandall:

char *encandenc(char * bu)

{
 CBC cbc;
 uint8_t key[16] = {97, 115, 100, 102, 103, 104, 106, 107, 108, 112, 111, 105, 117, 121, 116, 114}; //asdfghjklpoiuytr
 uint8_t iv[16]  = {113, 119, 101, 114, 116, 121, 117, 105, 111, 112, 108, 107, 106, 104, 103, 102}; //qwertyuioplkjhgf
 uint8_t input[96];
 size_t len = 16;
 memcpy(input, bu, 96);
 delay(1000);
 cbc.setKey(key, 16);
 delay(1000);
 cbc.setIV(iv, 16);
 delay(1000);
 cbc.encrypt(input, input, 96);
 delay(1000);
 cbc.clear();
 int inputLen = sizeof(input);
 int encodedLen = base64_enc_len(inputLen);
 char encoded[encodedLen];
 base64_encode(encoded, input, inputLen);
 delay(1000);
 return encoded;
}




Why do you think returning the address of a local buffer will work (reliably)?

I don't think the local copy of the passed string is neccessary.

What are the delays for?

If RAM is a problem, there are many constant strings that could be moved to PROGMEM only.

I dont know if RAM is problem. I deleted this function moved whole function to loop still same problem.

moved whole function to loop still same problem.

You don't seem to understand that EVERY time you make a code change, you need to POST YOUR CODE!

You CAN, quite easily, add MORE Serial.print() statements to SEE what your code is doing. There is NO reason to guess.