Recently I've been trying to debug one problem with a 6502 based device with a code written in C and compiled with CC65. It was kind of weird issue because the same library that seemed to cause the problem worked fine in different project. Entire situation is described here. Yesterday I finally found out that it was and issue related to the stack overflow. I've able to work it around by reducing size of some buffers and making some other buffers and variables local. Now device ceased to reset itself, but there still are some bugs (for example quite rare false detection of button being pushed) which may or my not be caused by the same issue.

I am kind of bothered by the fact that there was thank kind of a problem in a first place. Device has 8kB SRAM chip, which is a lot for such system. There are two larger buffers, each 256 bytes long. Beside that there is only a couple of smaller buffers and global variables. There is nothing that could eat up all that RAM, leaving no space for CC65 software stack.

Is there any way to generate summarized information about RAM usage in cc65 compiled project. AVR-GCC provides such information regarding to flash (program size) and RAM (sum total size of all global variables). Can I get something similar here? Is there a way to diagnose and fix this problem?

The main.map file that was generated should show you the memory usage somewhat. I had looked at that when you posted the "broken" code with the output files. I also looked at the data stack usage for the update_keys routine and could not find any issue with that. I was wondering if the hardware stack was getting corrupted or overflowing and RTS cmds were sending you to non-program code. a BRK will cause your code to restart. You may want to look at your hardware Interrupt sources to be sure its not overloading your system. you could rewrite the BRK handler to dump a string and stop vs. restarting, that way you'll know if that is the cause.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Then there should be plenty of memory left...





I also spent a lot of time looking at that code and I am quite sure it is fine. It works with the other device...



If there is some way to check if that is the case?



Ok, I will try it. What should I do next, If I'll find out that BRK was the cause of resets?

Perhaps your interrupt handler could inspect the page 1 stack pointer and keep a kind of high water mark (which is to say, keep a record of the smallest value seen.)

I try to optimize use od hardware stack, bu removing unnecessary nested subroutine calls. In previous version of my code I had such a call inside interrupt subroutine:


Which was calling this C function:



Which compiled to following assembly code:



I decided to write my own code into interrupt subroutine:



Unfortunately, now it shows rubbish instead of correct value. I can't see anything wrong there. Where I made a mistake?

Your call to "_update_geiger_pulses" within your Interrupt service routine did have a problem. The CLI command would reset the IRQ Enable before the current interrupt routine was done. That could cause another IRQ to start before the last was finished. If too many came in, your hardware stack would overflow.

I will need more time to read over your new code - its good that there is no more CLI, but not good that it does not quite work as needed.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

You are not multiplying geiger_ind by two (shifting left one bit) to account for geiger_pulses being an array of words and not bytes.

[/quote]

Can you explain? I am not quite sure if I get it.

The compiled C code is doing this...

Sorry, I am still not sure how to include it into my code. I am still learning assembly and I has some difficulties with understanding all of compiled code. This was one of problematic parts.
Can you tell me how to use it in my code. Be aware of the fact, that I load _geiger_ind to X and then use X to address buffer in absolute indexing mode.

geiger_pulses is an array of 16-bit values. Do you understand that part?

As written, your code writes to _geiger_pulses and _geiger_pulses+1 the first time through (geiger_ind is 0.)

The second time through, geiger_ind is 1 and you write to _geiger_pulses+1 and geiger_pulses+2, overwriting the value in _geiger_pulses+1 from the first time.

You can do one of two things:

* Double geiger_ind before doing "sta _geiger_pulses,X" and "sta _geiger_pulses+1,X" but this makes incrementing it afterward more difficult. It is also a bit slower if that matters.

* Increment geiger_ind by doing "inx" twice, then comparing with $3C*2 when deciding whether to roll it back to 0.

Ok, now I see how silly my mistake was. I kind of think slowly today.
I've been interpreting compiled code in a wrong way.

Is it fine now?

Actually, I would take what you had and do this:

I'm glad to hear you located the issue. A stack overflow makes sense for global variables being overwritten. Many compilers place the stack right after the global variables and so this isn't as uncommon an issue as one might like.You determined the stack size in your lib/ethergeiger.cfg file when you said:The compiler likely looked at where your last global variable was placed, added the $200 you requested for the stack and started the stack there. Because the stack grows down towards lower addresses, once it got too full it started to overwrite the global variables. Unfortunately there isn't really any collision detection built in, so it's something you will need to watch for. Global variables that mysteriously change are indeed one of the symptoms. BigEd's suggestion of having your ISR keep tabs on it is not unreasonable. If you were able to simulate your program (difficult because of how much hardware is involved) you can put a breakpoint on a write to the last (lowest) byte in the stack so you know if it ever grows that large.Kind of. One issue is the way you are compiling your program. Your Makefile is compiling your .c files into .s files, then you are using the assembler to assemble your .s files into .o files, and then finally you link all of them together. The issue with this method of assembling your executables is that you are losing symbol information along the way. You can get some of the symbols by adding the -g command line option to ca65 when assembling, but I wasn't able to get them to flow all the way to the map or listing file. Your better option might be to use cl65 which knows how to compile and (optionally) link files and can turn a .c file directly into a .o file (including the variables). I modified your Makefile like so (only main.c shown):The -c option tells cl65 to compile but not link (so it will make a .o file) and the -g tells it to include extra debugging information (including the variable names). I also added "-Ln main.lst" to your a.out target's command line to create a list file. This is the file where the value (address) for a given symbol (variable or function name) will appear. Looking for your key variables, I find: and so I would be looking for writes to $04ED through $0500 (your key_t structures are 5 bytes big and this only shows the starting address). Unfortunately, it's really up to the application engineer to make sure the stack size is reasonable for the application, and I suspect there are a good number of devices that occasionally trash some of their variables due to a stack overflow that occurs on rare conditions and wasn't caught during development. Interrupts that happen during your ISR (it looks like your original ISR might be re-enabling interrupts before it finishes) are a very quick way to eat through a stack of any size, as 8BIT noted. Hopefully your rewritten ISR fixes that.