bug in compiler made code

I'm not sure what "passionate" actually means as an attribute of a programmer?

The key attributes required of a good programmer are Attention to detail, Meticulous thoroughness, etc..

"never leave bugs in my code"

Well, I don't suppose that anyone deliberately leaves bugs in their code - but that doesn't mean that it never happens!

How can you be so certain that you have no bugs in your code?
I'm not aware of any method or scheme that can 100% guarantee that there are absolutely no bugs whatsoever in the code - so what's your secret??

"i have a problem"

Must be a bug, then - surely?!

"i have my uvision project and it works great"

What, exactly, do you mean by "works great" here?

Have you exhaustively tested it - especially against all error cases and "corner" conditions?

"i download it to my dev board and it works great"

Again, have you exhaustively tested it - especially against all error cases and "corner" conditions?

Running it on just one Dev Board does not constitute exhaustive testing!

"into another board but it sometimes doesnt work"

In what ways(s), exactly, does it "not work"?
What testing and debugging have you done to determine what is going wrong?
What have you done to try to determine the difference(s) between the times that it works, and the times that it doesn't?

"the board works great"

Again, what does that actually mean?

"hw guy says i have a bug in my code"

That doesn't seem an unreasonable thing to say - but what testing and debugging has he done to demonstrate that it's not a hardware bug?

What have you done to prove him wrong?

"i put code into another board"

And what happened?

This doesn't sound very "passionate" - it sounds like you're just randomly putting your code into different boards and hoping that it'll run!

"the only thing i can think is the compiler added a bug"

That is highly unlikely!
Why do you think it is so much more likely than a bug in your code, and/or a bug in the hardware?

"anyone else seen this?"

Yes -it is a very common experience of all embedded developers!

Since it "works" (sic) on the Dev Kit, but not on the first board, you could start by looking at what, exactly, is different between those two boards...

It could be something like a timing difference - so that your code only just works on the Dev Kit, and only just fails on the other board...

Or uninitialised variables

Or...

One very common reason for software working on a Simulator or DevKit but not custom hardware is because of misconceptions, misinterpretations, or misunderstandings of the hardware operation.

It could be that the HW engineer misinterpreted the spec, so the actual hardware operation doesn't (quite) match the spec;

It could be that the SW engineer misinterpreted the spec, so the way he has coded the system doesn't match the actual hardware

Or a combination of the above!

This is before you even start to think about actual bugs in the HW or SW design, mistakes in the implementations, and/or faults in components, assembly, etc...

... hardware bugs that appear as software bugs and software bugs that appear as hardware bugs.

an example of a software bug that appear as a hardware bug would be clocking a peripheral device too fast, some may work, some may not.

Erik

This is precisely the kind of thing that would not show up in simulation, and result in some board "working" (sic) while others "don't work".

Which is exactly why, "dev board ... works great" is almost entirely meaningless!

Similarly for all sorts of other "timing issues"...

Another, I think, is Tenacity: that is, not just giving up and saying, "it doesn't work"; but hanging-in there until you find out why it doesn't work!

And, of course, once you know why it doesn't work - you're well on the way to fixing it!