CCS 5 (LM4F120H5QR) Variables overlap

Hello,

in which file is the code containing tx_buffer_head etc?

thanks

Interesting project.

The code really  is at the web address given -- do look. Impossible to post easily and there is a zip to download.

The IDE is now at version 5.3.

You do not state which compiler you are using and that is a separate issue. is it the 4.9x series or the 5.0X series? Just have a look in your options.

If you do not have the 5.0x compiler you can download that and give it a try via the add software route on the help menu.

Are you getting any warnings that you should post?

Hi,

Dave you are rigth, the link works. But I was asking for the file because there are many files. Now I found it : tx_buffer is in serial.c . However, I am still looking for inverse_millimeters....

It might be a memory leak : Does the overlap happens at the first call of the funciton containing inverse_millimeters? Have you try to define inverse_millimeters as global (to see if it temporarly solves the problem)?

Esaki.

The compiler is tms470_4.9.5. I will try new compiler. Thank you for the idea!

I've got absolutely no warnings during compilation. Settings for warnings are default..

inverse_millimeters you can find in planner.c function plan_buffer_line.

Yes, the overlap happens at the first call of the function. I will try do declare inverse_millimeters as global.

About memory leak - there is no dynamic allocation of memory, so there should be no memory leaks.

As for the Volatile keyword...

see here: http://www.embedded.com/electronics-blogs/beginner-s-corner/4023801/Introduction-to-the-Volatile-Keyword#

They are right that we don't pay enough attention generally as to when it is appropriate or not...

And that is a good question -- are you optimizing the code? At this point you should not be doing so.

Declaring float inverse_millimeters as global really solved the problem. What does this mean? I tried to make it volatile instead of global, it works too.

The code works well now, but i can't say if any other variables are not going to overlap.

Now other temporary float variables in the same function plan_buffer_line overlap my variables.

Thank you for a good article!

So, all vars which can be changed enexpectedly are already declared as volatile.

The problem is that compiler arranges memory for variables in a bad way: some variables overlap. Unfortunately, there are no warnings during compilation.

The optimisation of the code is switched off.

Good to know. So now it works?

Actually no. Other temporary vars began to overlap. I can begin to declare all vars as global or volatile, but this seems to be a mistake. Obviously, overlapped variables should not exist. This is either my fault or compiler fault.

An easy work around (that I use) is to use buffer an temp var that are all global. I guess there may be a more professional way but it wokrs at least for me in most cases.

This is a good solution if there is no other way to solve an issue, thank you.

I still hope to find a better way.

I looked at the code. I do not have a lot of time so it was pretty cursory. I noticed that a lot of the variables were declared as eight bit -- no surprise since the AVR line is eight bit. I worked with the Mega2560 a fair bit so I know the limitations of an eight bit processor.

What you might also think about is reviewing the code for variables that could be better expressed as an Integer (32 bit) as opposed to an eight bit like uint8. You may spot something

More bugs are found in a code review than will ever be found by a compiler or debugger.

Besides, if you take the code review path,  you can put your feet up and relax while looking at paper instead of staring at a screen.

On another note: Are you actually getting errors or is it just strange behaviors when you attempt to run the program? What other information can you give out?

If you keep it up to date I can download the complete system again and give it a quick look if it is "up to date". Unless I need special equipment or programs I believe I can duplicate your setup.

One more thing... Do a code review looking for variables of the same name.

Are the local variables (static) declared properly.

Have you used Global only where appropriate.

Is there any possible confusions between actual variables, pointers and address resolutions?

Hello!

I've installed a new CCS 5.3 with a new compiler arm_5.0.1. The issue is still the same.

Here are addresses of variables when tx_buffer_* and rx_buffer_* are 8-bit volatile.

Here is a picture where rx_buffer_* and tx_buffer_* are 32-bit volatile:

In both cases variables overlap.

The latest compiler I have is 5.03.

At the point where you give up for the day bring your zip file on github up to date -- then post a note here.

If I get back in my humble office tonight I will download it and attempt to compile.

For the time I have to go -- exercise and supper.

BTW: One of the most effective trouble shooting techniques I know is to "walk way"  and "give up". The answer often appears in a moment of insight. And no, I'm not joking, I spent hard time as "the person of last resort" -- for many years. It's an effective technique.

I'm interested in the project for a variety of reasons it would be nice to see you succeed.

Good news.

Solved the issue by changing

volatile uint8_t rx_buffer_head = 0;

to

volatile uint8_t rx_buffer_head;

and moving =0 to corresponding init function.

Could please anybody say if it is really important not to initialise volatile variables? Was that my fault or compiler fault?

Dave, i agree with you about "walking away". It took a week to solve this issue... Why are you so interested in this project? There are better CNC solutions for ARM: R2D2, Smoothie... They support SD, FAT and others goodies.

One more question to experienced embedders: is there any file with description of addresses for each variable? I want to be sure that no other variables overlap.

It does look like good news. I was just walking away when this popped up.

The way you are setting up the variables is the way I always do it. Just a habit where I guess I must have seen a problem and chose a way that seems to always work.

I do this with all variable types. I do not recall why I became leery of the the declaration plus initial -- I just am.

Declare all variables at the top of the section to which they belong. The initialize them at the beginning of the procedure/function if required. (Pascal style)

It never seems to fail.

I got the impression that your problem is not the code itself, but the stack size.

This value is itself not "in the code", or "part of the project", but rather a property of it. Project wizards of most toolchain just set it to a default value - some more generous, some rather tight. I had some rather cumbersome problems in those cases, so I tend to be more generous here.

I would retry with the original project, and set the stack size to 1.5 ... 2 fold the original.