I have weird situation with one of the projects I develop currently.
A little bit of background: some time ago I developed Arduino-like platform with WDC65C02 microprocessor. After designing additional I/O boards I currently develop two projects around it:
1. Talking clock with SP0256 chip (not yet described anywhere on-line)
2. Digital Geiger counter (described here, I need to update it.)


I wrote the code in C and compiled it with CC65. Sources are available on GitHub:
https://github.com/marekw1986/TalkingClock
https://github.com/marekw1986/RetroEG

In talking clock I use my, simple library for key debouncing. It uses structures to keep information about key state and pointers to the function that will be executed after detecting proper key push.
https://github.com/marekw1986/TalkingCl ... /code/io.c
https://github.com/marekw1986/TalkingCl ... /code/io.h

It works fine, but only with my TalkingClock project. I tried to use this library also with other project, but then entire device starts to behave unstable. There are false key pushes detected and device resets itself constantly. For now I replaced key_update calls with instructions hardcoded directly into main loop (unfortunately CC65 doesn't support inline functions) and it works for now (check this main.c file to see what I mean). So it looks like there was some kind of a stack overflow problem caused by key_update call, but I am unable to track down the cause of this behavior.

Any ideas?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

There are no delay loops in my code (with just few exceptions, when very short delay is required). I use MC6840 timer to implement something like systick or Arduino milis() function and then I check if it was incremented by the required value since last operation. Library has been tested and works just fine with the first project. It only causes problems with the second one.

Otherwise (when library is not being used) device works fine, so it is rather not a hardware issue. I even checked if the RAM chip not damaged, with my TL866 programmer. It turned our to be fine.

I don't see an example of code where it doesn't work (eg. I am unable to view the code for your Geiger counter where it doesn't work - I only see the "fixed" version). I didn't see any earlier version on Github. Can you show your non-working code/project?

There is no any. I created this repository only after creating this temporary workaround.



Non-working code was identical with the one I use in my "TalkingClock" project. This is why I also posted link to that repository. The same library used the same way to call the same functions that are executed now by the workaround code.
But for some reason this code works perfectly fine in one project, but breaks stability of the other.

The issue is that it works in your TalkingClock project, so looking at your TalkingClock project isn't really instructive.

In C, the compiler generally arranges things in memory in the exact order they are declared in the C code (with some distinctions made between initialized variables and uninitialized variables, which are often stored in separate sections). If you have some piece of code that is accidentally writing beyond it's reserved memory, it will overwrite whatever comes next in memory, which might be your "key_t" structures. If you rearrange the order the variables are declared, then it might overwrite other variables that are not used at that time and go unnoticed (therefore it "appears" to work fine).

This means that, for troubleshooting, the exact order and types of variables declared matters. I would be looking at variables above your key_t structures that might accidentally write too much, like the buffer and the other variables declared just above your structures.

Ideally, I'd compile your non-working code and then investigate where the compiler actually put things by looking in the listing or map file (which you can ask the compiler to make for you). I also might try to run it in a simulator with a breakpoint on write to the memory locations of the key_t structures to try to capture the rogue writes and see where they come from (but your project has enough hardware dependencies that it might not be feasible to do that). I would need the misbehaving code, in a compilable format, to do any of that. It's very important when asking for help on a bug to give a method to reproduce the bug (ideally a "simplest working example", which might have a lot of your other libraries/code removed if the bug still shows up without them). If you can work the problem down to a simplest-working-example of the bug, that also helps narrow down the problem significantly, and you may even discover the root cause of the issue while trying to narrow things down.

Because you are using github, you can make a branch without disturbing your working code and try to build a minimum working example of your problem. Removing code for hardware that is not related to the problem also makes the code easier to simulate. Once you have a good example of the bug in action, you can push your branch to github and then post the link to your branch for people to look at.

Ok, I created branch called "testing" and then broke the code once again by adding those functions from 'TalkingClock" project.

https://github.com/marekw1986/RetroEG/tree/testing/code

I also commited all the files created by the compiler. Any idea what may be wrong?

EDIT: Maybe there is something wrong with custom run-time library? I created mine using process described HERE, with supervision.lib file.