A stranger problem

It was me, my actions, I deeply regret.

The problem is on line 158 in your main C file.

Rich Webb ??:

I think that is not my wanted answer, anyone give some tips?

Ask a better question.

Don't smoke, drink excessively or shag other chaps.

Your question includes far too little information for any "detailed" answers to be meaningful. Some (but not all) possible causes include uninitialized or misdirected pointers, misuse of casts, stack overflow, overrunning array bounds, and improper return from interrupts.

What Rich is trying to tell you is that you haven't included anywhere near enough information for any such specific advice to be given. A few possibilities:

Rouge pointer.

Indeed. Everyone knows that the R8C architecture greatly prefers pointers verde.

You can put lipstick on a pointer, but...

(An uninitialized or corrupted pointer would be high on my suspect list, too. Also look out for manual allocation of something else over the top of the global. Configuring the compiler/linker to generate a map file displaying the address of everything, and then reading through it can be quite informative as to how your program is actually getting allocated and implemented)

Check the memory map of your linker output, you may well have this vatiable as the last variable in RAM, and something due to miscast or otehr pointer problems writes over the variable above AND your vriable, especially if it is byte/16 bit length.

Try defining some INITIALISED vriables before and after yours and see if the problem persists. Making sure something somewhere does something like read one of them or something.

Make sure thevariable actually is located in real RAM not undefined memory areas or port registers!

Make sure that it is not in a memory overlap, it is possible on some linkers to define one set of variables/memory block INSIDE another memory block.

It appears that someone has cast a black magic variable changing spell on your system. This can be easily fixed by using a standard Hex Inverter to invert the hex that was placed on your system. I suggest using a 74HC04.

I hope this helps...

OK, here's the straight answer.

Some of the possible reasons:

These pretty much reduce to: You're reading the wrong memory. You're writing the wrong memory.

Finally, since this is about an embedded system, you might consider Your hardware doesn't work reliably. Your software tools don't work reliably.

And one of the most common causes: Your system is fine, it's your test that's wrong.

Then it must be line 42. Why don't you like line 158?

Definitely. Always use mauve pointers. The rouge ones never work right.

ROTFLMAO!

I kill myself.

You're available ?

Good, saves me some work ;>)