Check if there is a Serial-communication between Nextion and Esp32

Projects Programming
22

Not sure why you are creating a new post if it is related to the same issue

what is a "Stack smashing protect failure!" ?

23

Topics merged

24

I suspect you are exceeding the bounds of an array somewhere else in the code. The print statement is somehow altering the arrangement of variables in memory and altering the effects of the error.

25

Did you do this

for( i = n; i-- > 0; )
{
    // Use i as normal here
}

?

26

you mean like this:

for(i=8;i-- >0; )
{
    Serial2.print("j");
    Serial2.print(t);
}

still causes the problem

thank you

27

Sorry no more ideas.

28

just to be clear there is NOTHING wrong with that code

for (int t = 8; t >= 0; t--) {
  // send "j<n>.val = 20" + termination
  Serial2.print("j");
  Serial2.print(t);
  Serial2.print(F(".val="));
  Serial2.print(20); // or anything dynamic as a value
  Serial2.write(0xFF);
  Serial2.write(0xFF);
  Serial2.write(0xFF);
}

At the back of Serial2 you have a Nexion screen and software handling (and if the work they did on their library is an indication of the quality of the code they provide), they could have bugs

so the question is can you describe what is " Stack smashing protect failure" ?

29

You need to look at the code outside of the function that you believe is causing the error. This type error is often a symptom of another part of the code writing to a memory location improperly, such as writing outside the bounds of an array. The print statement appears to affect the problem because it causes the compiler to somehow rearrange where variables are stored in memory, altering what the out of bounds write is overwriting.

30

The other possibility is that the ā€œproblematicā€ print statement is the straw that broke the camelā€™s back for stack usage in the task that is running the code. If it were my project, Iā€™d abandon the Arduino setup() / loop() paradigm that I assume the code is using and totally rewrite it to logically divide itā€™s various parts into well-thought out FreeRTOS tasks. That would allow the stack allocation and priority of each task to be properly set.

Either way, itā€™s impossible for anyone on the forum to provide informed, detail advice without seeing the entire code.

1 Like
31

My thought exactly.

32

We don't know if there is anything that is long / synchronous and requires a blocking call. If that's not the case then a good old fashioned state machine with setup() and loop() should work....

I've heard not so great things about Nexion so would question how the screen is managed, what library is used if any etc...

33

That is, assuming OP's code (that STILL hasn't been posted) and/or the library code being used isn't blowing up the stack allocation of the single task that it's all is running in. Admittedly, it's much more likely that the code is somewhere writing to memory it doesn't own.

34

that's what I found about "Stack smashing protect failure"

Stack smashing protection mode. Emit extra code to check for buffer overflows, such as stack smashing attacks. This is done by adding a guard variable to functions with vulnerable objects.

The guards are initialized when a function is entered and then checked when the function exits. If a guard check fails, program is halted. Protection has the following modes:
- In NORMAL mode (GCC flag: -fstack-protector) only functions that call alloca, and functions with buffers larger than 8 bytes are protected.
- STRONG mode (GCC flag: -fstack-protector-strong) is like NORMAL, but includes additional functions to be protected -- those that have local array definitions, or have references to local frame addresses.
- In OVERALL mode (GCC flag: -fstack-protector-all) all functions are protected.

  • Modes have the following impact on code performance and coverage:*
    - performance: NORMAL > STRONG > OVERALL
    - coverage: NORMAL < STRONG < OVERALL
35

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.