C question

C question

Postby FZR1KG » Mon Aug 11, 2014 6:58 am

Squid, this probably means you.

While trying to debug my code I wrote a function that accepted an unsigned int a parameter.
So far so good but, I needed to call another function with the address of this parameter as its parameter.

The code is simpler, trust me:

Code: Select all
void write_ee2prom(unsigned int uINT)
{
ext_uint = uINT;

//Note that at this point, ext_uint and uINT are the same value

apd_reply_ram(&ext_uint); // THIS ONE WORKS CORRECTLY
apd_reply_ram(&uINT);   //PROBLEM IS HERE

}



I stripped away all the non relevant stuff in the code to show where it fails.
If I call the function above with a value of 0x1234, the pointer to the address is correct and has 0x234 in it.
If I do the same thing with &uINT it passes something else rather than the address of uINT. The contents of that address are not 0x1234

It's been a long time but afaik C supports pointing to local variables even if it is a risky thing to do.
In my case it's not so risky
1) I'm calling a routine with it rather than returning a value.
2) The called routine does not store the value, it uses it to get the data from it and send it to the RS232 port then returns. It has no global vriables of its own.
3) This is sequential code and not multi threaded. It's impossible for the local value to be reallocated before the other routine is finished with it.

It's riskier to make a global variable in my case since that takes up more memory and chews into the stack which kills the CPU process if it gets too big. I have 256 bytes of ram and I uses 185 bytes of global variables. Compiler uses 16 and the flash writes use 8. Doesn't leave much room for parameter passing or nested calls.
Yes the above code is using just as much as a global would but it's because I wanted to demonstrate the error and also it gets released once the functions are complete. A global wouldn't.
FZR1KG
 

Re: C question

Postby squ1d » Tue Aug 19, 2014 9:22 am

*** edited out
Last edited by squ1d on Tue Aug 19, 2014 9:36 am, edited 1 time in total.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby squ1d » Tue Aug 19, 2014 9:33 am

I reread what you wrote. If what you mean is "should this program print 666", the answer is yes, according to my z/OS C++ compiler.

Code: Select all
 #include <stdio.h>                 
 #define THE_VALUE 666               
 void f1(unsigned int v);           
 void f2(unsigned int *plv);         
 int main(int argc, char **argv) {   
    unsigned int value = THE_VALUE; 
    f1(value);                       
    return 0;                       
 }                                   
 void f1(unsigned int v) {           
     f2(&v);                         
 }                                   
 void f2(unsigned int *plv) {       
    unsigned int result = *plv;     
    printf("Value = %d\n", result); 
 }                                   


Output wrote:Value = 666
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby squ1d » Tue Aug 19, 2014 9:40 am

Also, look at your disassembly. What does &uINT decompile to? It could be something to do with your architecture/compiler? Is the stack getting clobbered?

If all you are doing is dereferencing the pointer, why not just pass by value and eliminate the need for addresses?
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby FZR1KG » Tue Aug 19, 2014 5:27 pm

uINT is just a 16 bit unsigned int.

I'll clarify the problem:



Code: Select all

void ee2prom(666);

void write_ee2prom(unsigned int uINT)
{
ext_uint = uINT; // at this point both uint and uINT should contain 666

//Note that at this point, ext_uint and uINT are the same value, of 666

apd_reply_ram(&ext_uint); // this passes the address of uint and that address contains 666
apd_reply_ram(&uINT);   //this should I think, pass an the address for uINT that contains 666, but it doesn't. I have no idea what address it is but it does not contain 666

}


I can't change the code to pass the value because what I have above isn't the actual program.
It's the simplest form I found that breaks so rather than complicating the question I just posted that.
The actual code has a pointer because the data changes width, so the next parameter is a sizeof(variable).
FZR1KG
 

Re: C question

Postby squ1d » Tue Aug 19, 2014 6:35 pm

The address-of operator must be working or your compiler is completely broken.

So in order to debug this problem, the first thing I would do is establish inside write_ee2prom that *(&uINT) contains 666. Can you confirm that?

If indeed this is true, then something is clobbering uINT on the stack after you call apd_reply_ram(). Can you record the address of uINT and its contents before, during and after the call to apd_reply_ram() ?

There's no reentrancy issues because of interrupts?
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby squ1d » Tue Aug 19, 2014 6:55 pm

I have been assuming locals are allocated on the stack .. you should probably check your compiler documentation to verify that.

Try disabling any optimizations.

The problem is likely to be specific to your compiler/architecture.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby FZR1KG » Tue Aug 19, 2014 9:02 pm

That code sample has two functions that are called to apd_reply_ram()
I only use one.
The one with the obvious problem failed, so I made another local variable and equated the two.
That worked.

So the work around is to use an intermediate local variable.
The problem with that is I'm really low on stack space and that's another byte for no reason.

The value equated to however contains 666 correctly.
So basically its a compiler issue. Both are located on the stack, one is addressed correctly, the other isn't.

Mind you I've now progressed beyond this problem since that was test code I put in that turned out to fail. Go figure.

Now I'm on the ICE and debugging more strange shit.
The library routines in assembler read the correct data from the serial port, and return the correct data in the SMM.
In the LMM, it reads the right data but somewhere between reading it and returning to the calling function it gets corrupted.

It's driving me nuts.
List files that are wrong. Confirmed by Cypress to be an issue with the Imagecraft compiler if absolute addresses are used anywhere in code.
Well, it's a uprocessor. Of course it's going to have absolute addresses used. That makes the list file useless for the application.

Then the problem where compiling under LMM does something internally so once compiled, the project breaks even if going back to the SMM.
Now I'm getting corrupt data in the LMM of Cypress library functions.

I'm just using my time debugging Cypress issues instead of moving forward with my own program changes , because I can't go forward till these issues are resolved. Arrgghhh.
FZR1KG
 

Re: C question

Postby squ1d » Wed Aug 20, 2014 9:22 am

I don't think I understand your English in the middle there, regarding 'equating' and an intermediate local variable, but if I do, your compiler sounds shit.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby FZR1KG » Wed Aug 20, 2014 3:18 pm

squ1d wrote:I don't think I understand your English in the middle there, regarding 'equating' and an intermediate local variable, but if I do, your compiler sounds shit.


value equated:

uint = uINT;

uINT was the parameter so it got filled with 666 correctly.
uint got equated to uINT correctly.

*(&uint) = 666
*(&uINT) = ????

That's the problem inn a nutshell.

And yes, I'm with you about the compiler being shit.
I found the problem with my code, or I should say I found where I can change a bit of code that breaks the EEPROM routines.
My issue with finding it is that it has nothing to do whatsoever with the EEPROM routines and resides only in the bootloader.
The bootloader is only used to load new firmware if required and then passes control to my code.
The bootloader is in protected memory. It cannot be overwritten.
That alone says there is a serious underlying issue. Adding or removing one instruction in the bootloader breaks the main code.
But it gets worse.
As I mentioned, the bootloader is inn protected memory.
Now, if I download the code and the bootloader with the code that works, everything works.
If I recompile it with the lets say, faulty bootloader code, then download the new main code, not that means the just my code, not the new compiled bootloader code. The project then fails.
The more serious side to this is that:
1) I don't even download the bootloader section of code to the chip
2) The bootloader is in protected memory so even if I did download it, no change should happen.
3) Recompiling with the "non faulty code in the bootloader" then downloading only my code, not the bootloader, fixes the problem again.

This is a real problem. It's the real world situation of me changing the tire on my motorbike but doing so causes the engine of my 4WD to fail.
Putting the old tire back on the motorbike, fixes the engine on the 4WD. This can be repeated enough times to show a positive cause and effect.
Then ask the mechanic to fix the 4WD...
FZR1KG
 

Re: C question

Postby Sigma_Orionis » Wed Aug 20, 2014 9:30 pm

I've been reading this and trying to understand the problem (why? no reason, just being nosy. So, ignore me while I make non-constructive comments. :P )

So you're passing the pointer of a local variable as a parameter to a function which might not exactly be kosher but it's supported (btw SURPRISE! squid's code compiled and ran on one of my linux boxes, using gcc, without any issues either). However, in yours it gets mucked up and squid speculates that it might be issues with how the compiler allocates those variables.

Furthermore, if I understand correctly, if you use an intermediate variable, it works. You don't want to do that because you have very limited memory resources on the device you're making the code for. Not to mention that there's no guarantee that it will work under different circumstances and that it's a messy hack on something that should need that kind of stuff.

So, both you and squid reached the conclusion that the compiler doesn't work correctly.

From Z's post I figured that the compiler he's using is this one

What amazes me is that a development tool for that kind of application (embedded systems) can be so fucked up.
Sic Transit Gloria Mundi
User avatar
Sigma_Orionis
Resident Oppressed Latino
 
Posts: 4496
Joined: Mon May 27, 2013 2:19 am
Location: The "Glorious Socialist" Land of Chavez

Re: C question

Postby FZR1KG » Wed Aug 20, 2014 10:44 pm

That's the compiler and yes you got the story right.
I found a few bugs in it when it was still in the beta release.
Overall it's not too bad.

The list file generation is however pathetic.
it doesn't align the opcodes with the assembler and often places opcodes into areas that are comments.
basically makes it really freaking hard to trust the listing or even use it.
Plus it sometimes just doesn't generate the opcodes but has the actual code in the object file.
Result: You can't use the list file to debug except for the simplest cases.

I can't blame them for the parameter issue, it's just a bug that's gone unreported because it would be highly unlikely anyone would use it. Shit happens.
The list file however is a known issue for a long time but remains undocumented so users don't know about it and unfixed.
FZR1KG
 

Re: C question

Postby Sigma_Orionis » Wed Aug 20, 2014 10:54 pm

Well, I guess I ain't as brain dead as Dijkstra claims (the first time I actually wrote code was in BASIC, and not your Mommy's Basic, this one had line numbers and you could only use 2 characters to name your variables).

Like I said earlier, I never ever used list files, the fact that that compiler has had that stupid bug in the list file generation for so long makes me suspect that most developers that use that tool never use it either. Which, considering the kind of stuff you have to do to write code for embedded devices, makes me think that those developers aren't the sharpest tools in the shed either....
Sic Transit Gloria Mundi
User avatar
Sigma_Orionis
Resident Oppressed Latino
 
Posts: 4496
Joined: Mon May 27, 2013 2:19 am
Location: The "Glorious Socialist" Land of Chavez

Re: C question

Postby FZR1KG » Wed Aug 20, 2014 11:00 pm

My basic started with line numbers and A-Z as variables. I'm that old apparently. lol

For normal debugging list files are not really needed. You store in your head what the instructions are meant to do.
If you don't know what they are meant to do then you have no business writing code.

The list file generation is the last line of defense for debugging.
If you're down to the list file you are now suspecting compiler or assembler issues or linker problems.
So it's pretty rare to have to go that deep.
When you do however, it's vital that the list file be correct or it's useless.
Knowing when to use them is the real trick.

For modern day compilers on large PC's they would rarely if ever be used in user applications.
The only real need would be for the compiler and assembler developers to test the validity and efficiency of their generated code.
FZR1KG
 

Re: C question

Postby Sigma_Orionis » Wed Aug 20, 2014 11:27 pm

Yep, yer that old. And that neither of us is old enough, Imagine working with Fortran' 66, no alphanumeric variables at all!

So, you don't have to dig that deep even when dealing with embedded devices? I figured that if you had to worry about absolute addresses and byte alignment, you'd have to do stuff with list files, tells you lot on how much experience I have on those things... (hint: NONE :P )
Sic Transit Gloria Mundi
User avatar
Sigma_Orionis
Resident Oppressed Latino
 
Posts: 4496
Joined: Mon May 27, 2013 2:19 am
Location: The "Glorious Socialist" Land of Chavez

Re: C question

Postby FZR1KG » Sun Aug 31, 2014 4:31 pm

Speaking of old.
It wasn't not long ago that when you fire up a compiler or environment for a programming language, it just fired up.
Lately everything seems to be about "preparing a solution".
W.T.F.?

Starting Visual C++ is not "preparing a solution".
If it was I'd have finished long ago with this job.
I've opened the IDE at least 50 times and it still hasn't solved the problem.
It LIES!!!!
FZR1KG
 

Re: C question

Postby Sigma_Orionis » Sun Aug 31, 2014 9:13 pm

Meh, a couple of months ago, two C# kids were bitching because one of their web services weren't "consuming" and said the problem had to do with some file ACLS on one of my servers...

Want to know the real reason for the problem? They were writing software for a Travel Agency Company and had to contact some SABRE web services, they kind of forgot there's a firewall in the middle and neglected to tell me they needed access SABRE.

THAT's the kind of people who use compilers or IDEs that say "preparing solution" when starting
Sic Transit Gloria Mundi
User avatar
Sigma_Orionis
Resident Oppressed Latino
 
Posts: 4496
Joined: Mon May 27, 2013 2:19 am
Location: The "Glorious Socialist" Land of Chavez

Re: C question

Postby FZR1KG » Sun Aug 31, 2014 9:33 pm

rofl
FZR1KG
 

Re: C question

Postby squ1d » Tue Sep 16, 2014 7:52 am

If Visual Studio says that when you start it, it's probably because the file that organizes a project in VS is called a solution (.sln)

THAT's the kind of people who use compilers or IDEs that say "preparing solution" when starting


What, human beings that make mistakes? :o
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby squ1d » Tue Sep 16, 2014 8:09 am

The worst part about being in software development and IT in general is the elitist attitudes and the fact everyone wants to be the smartest person in the room. When I was younger I was well up for it, but now it just makes me sad. Everyone, no matter how remedial their portfolio is, seems to feel the need to sneer at those they deem to be intellectually inferior. And I find this sneering to be largely without substance, because as I have stated before, good people, good developers, just get on with the job and make it work. It is also amazing the opinions people have about areas they are in no way qualified to comment on. For example, if I criticized one of Zee's PCB designs, I would be talking out of my ass. Yet this sort of thing goes on every day inside and outside of the industry. A little bit of respect goes a long way.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby FZR1KG » Tue Sep 16, 2014 11:18 am

Hmmm, me thinks you need to read my post with the humourous rant it was intended mate. :D

My PCB designs are pretty average. I can get the job done but I'm no pro draftsman I assure you.
The latest one looks pretty good though. Even had the guy that does the SMD stuff comment on it.

Likewise my circuit design.
Years ago the design area was about elegance. It's now about how fast you can get it to the market.
The trend has gone from making hardware perform magic to let the hardware be the skeleton that supports the software.
That's even in the micro/embedded world.

While it makes sense at the design level because software can be changed easily and hardware can't. It also dilutes the design process and introduces what we call hacks into the industry. I'm sure you have the same thing because the software industry was hit by the hacks before the hardware one was. While hardware was still the field of the specialists, the software industry was being infiltrated.
Everyone can now "write" software. Anyone with basic electronics can now "design" hardware.

As we know however, that just isn't the case. If you don't have the formal training and experience you can't write good code.
Same with hardware. Some people can, some can't. The result is unreliable hardware that depends on software to make it work but the software is now also usually done by hacks with the net result being poor products all round.

Your point is however largely true. That idiot I've been referring to has less than basic electronics experience, little or no coding experience and yet makes ignorant comments regularly. I say, learn to read a clamp meter properly, before judging a complex design. lol
FZR1KG
 

Re: C question

Postby FZR1KG » Tue Sep 16, 2014 11:36 am

Classic example of hardware hack follows.
While I was working for the guy that now makes my PCB's, he had a problem that he couldn't find a solution for.
Part of it was this hardware design that was meant to run a relay for a set time, the minimum being about 90 seconds iirc.
He had to test every unit because it was used with gas. So compliance was a key issue.
Now, you'd think someone designing systems that controlled gas appliances would be a specialist...you'd be wrong.
The guy was a hack. No formal training. Really basic flaws, some dangerous imho and I know because I've been in the gas design area before.

After years of reject cards costing thousands, the PCB/manufacturer getting the blame for incorrect assembly and tearing his hair out, he asked me to look at it as he knew I was a design engineer. Took all of about 5 minutes to find the problem. The circuit design used a standard transistor RC timing layout, except, instead of common emitter, he made the design common collector. Long story short, this is a classic noob mistake. The timing was no longer controlled by the RC components but by the drop out voltage of the relay. Since these specs are non adjustable and never designed for close tolerance, just a guaranteed minimum hold voltage, the times varied wildly. The fix was to swap relays and inform the customer. It's now been years since I told them, and they are only now redesigning the thing...

Then I could go on about MrDiode...
FZR1KG
 

Re: C question

Postby squ1d » Tue Sep 16, 2014 3:51 pm

NO HUMOUR IS ALLOWED

Computers are serious business.


The result is unreliable hardware that depends on software to make it work but the software is now also usually done by hacks with the net result being poor products all round.


I don't agree with this at all. Pretty much the only software application I use that I think is really shit is Lotus Notes. There is a whole heap of great software out there. And in my professional career with regards to co-workers, only a minority are hacks and they usually get moved on pretty quickly.

Back when Windoze 95 was a thing and software was becoming ubiquitous was a much better time to make this case.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Re: C question

Postby FZR1KG » Sat Sep 20, 2014 2:51 am

squ1d wrote:NO HUMOUR IS ALLOWED

Computers are serious business.


The result is unreliable hardware that depends on software to make it work but the software is now also usually done by hacks with the net result being poor products all round.


I don't agree with this at all. Pretty much the only software application I use that I think is really shit is Lotus Notes. There is a whole heap of great software out there. And in my professional career with regards to co-workers, only a minority are hacks and they usually get moved on pretty quickly.

Back when Windoze 95 was a thing and software was becoming ubiquitous was a much better time to make this case.


You are reading into it incorrectly because the computer field is no longer something which one person alone can do everything on and be able to make ground breaking innovations in.
The area I was referring to was the hardware/software interface. This area has a fundamental void in the computer industry.
People like yourself that know software don't know the hardware so can never be proficient at developing code to run it or understand the premise that the design of the hardware is based upon. I know this because I'm from the hardware and I have to struggle to work out the latest hardware and how to control it because of the sheer complexity of it. Someone without years of experience in it has no real hope.
By the same token, as a hardware engineer, I can write code to control the hardware but I am far more likely to put in code that is flawed because I do not have the same level of experience in algorithm's and data structures etc as you do.
So no matter who writes the code it's going to come out like crap, it's just the type of crap that varies.
So I'll look at code written by a software guru and wonder what drugs the guy was on that wrote the code because it's missed the entire point of the underlying hardware and might even be unstable.
You'd look at a hardware engineers code and wonder what kind of idiot writes hack code like this which will cause similar issues.

Most of my career I've been at that interface, the triangle in the sand separating analog/digital and software. All I ever see is problems. Mostly stupid ones.
Always because someone that has specialised experience in one , basic understanding in another and has misunderstood the remaining one(s).

This epiphany came to me after I did a test on an interview for a job. The owner/interviewer flat out told me he wanted to interview me first because I scored about 90% and everyone else was about 30%, he told me it's because everyone else knew one field but not the others. Got me thinking then and I've been observing it since.
It has not really changed in over 20 years now. If anything it's worse. Mind you, the test was basic at all three levels so getting 100% didn't mean much more than you knew the really simple basics of each. In fact, I rate my performance very poorly at the time but apparently it was something unique. Go figure. So I spent a lot of time getting more proficient in all three. Net result I now have a unique skill set that the world thinks is not needed. Yay fucking me. lol

But, the day is coming where this will become a hot field because someone will realise that many major issues are there and no one has the training to sort it out. Then everyone will want my unique skill and I'll be fishing on a boat retired saying FUCK YOU ALL!!!! Ya bunch of backward visioned imbeciles...pass the beer hon...oooh, I think I caught a beauty! :D
FZR1KG
 

Re: C question

Postby squ1d » Mon Sep 22, 2014 12:57 pm

... and yet amazingly, the world is chock full of great products used and loved by millions.

I do not share the same world view as you regarding the industry.

For sure there is crap out there. I have some tough times with co workers too. But they're not all idiots, and I've had the privilege to work on some great and very successful products, with some great and intelligent people.
squ1d
 
Posts: 679
Joined: Mon May 27, 2013 5:12 pm

Next

Return to Sci-Tech… and Stuff

Who is online

Users browsing this forum: No registered users and 18 guests