A stranger problem

It was me, my actions, I deeply regret.

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

--
Rich Webb     Norfolk, VA

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.

--
Rich Webb     Norfolk, VA

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:

1) Have you actually initialised the variable? Are you also sure that its value is maintained across any sleeps or suspends you use in your program? 2) Is there any reason that you can't declare the variable static with local or module scope if it is really only used in one location? 3) Have you tried setting a watchpoint in your debugger on the variable in question? I'm not sure what debug facilities you have on R8C - never worked on that architecture - but you can always try compiling the code for your desktop if watchpoints aren't supported natively. How easy this is depends on how modular your code is. 4) Alternatively, have you tried declaring variables with known contents immediately before and after the variable in question? Check the contents of those. If the variable is not referenced by name or a pointer is not taken it would be comparatively unusual for just that variable to be altered. Checking variables before and after would alert you to anything sweeping through memory, quite possibly a buffer overflow.

--
Andrew Smallshaw
andrews@sdf.lonestar.org

Rouge pointer.

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

--
Rob Gaddi, Highland Technology
Email address is currently out of order

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate

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...

--
Guy Macon

OK, here's the straight answer.

Some of the possible reasons:

1) You never set the variable, so the compiler never reserved memory for it, so you're reading random memory. 2) You didn't reserve memory for the variable, either because you declared too small an array, or because you forgot to malloc() memory. 3) You're using a subscript beyond the valid end of the array, or you're using an invalid pointer. 4) You are using a pointer incorrectly, so some assignment through that pointer is hitting that memory. 5) You're calling some subroutine with an invalid pointer, whch leads to 4) above.

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.

--
	mac the naïf

6) Your stack is overflowing. 7) Your stack and heap are crashing. 8) You have a re-entrancy problem.

--
Regards,
Richard.

+ http://www.FreeRTOS.org & http://www.FreeRTOS.org/shop
17 official architecture ports, more than 6000 downloads per month.

+ http://www.SafeRTOS.com
Certified by TÜV as meeting the requirements for safety related systems.

9) Don't forget alpha-particles and cosmic-rays! [Though it's almost undoubtedly a programming error.]

--
Grant Edwards                   grante             Yow! Vote for ME -- I'm
                                  at               well-tapered, half-cocked,
                               visi.com            ill-conceived and
                                                   TAX-DEFERRED!

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

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
            Try the download section.

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

ROTFLMAO!

I kill myself.

--
Grant Edwards                   grante             Yow! Loni Anderson's hair
                                  at               should be LEGALIZED!!
                               visi.com

You're available ?

Good, saves me some work ;>)