Codes working and then failing.

Folks,

I am working on my alarm clock code - still.

Luckily I am keeping older copies so if problems arise, I can go back to older ones and have something that works.

NOTE: I am NOT CHANGING ANY ELECTRICAL PART OF THE PROJECT.

I am perplexed.

I have learnt how to do things and "make my life easier" - also so I can release the code for others to use and make it easier for them to change things which are unique to me and allow it to work for them.

So: Things were going good.

The latest version was working.

I did a few changes and flashed the card. It hung. Bugga!

So I went back to the old version.

This worked - originally.

I "debugged" the problem, and flashed it gain, and that time it worked.

So I kept on "building" on that version.

A few steps later, it hung again.

So I went back to my earlier version - which as I said works.

Guess what: Now it fails too.

About 20 seconds in, up to a few minutes, it hangs.

I now have to go back TWO versions.

I dug around and got a "compare" program. Went through them and there is very little difference.

A couple of extra lines here and there. No big code re-structure. Just a couple of line changes here and there.

So riddle me this:
Why would it be that code which used to work doesn't work now if I haven't done any mechanical changes?

The earlier code (2 revisions back) does work.

THE latest hangs - well that is sort of to be expected as it is still "work in progress".
But my first back up doesn't work, yet before I started this latest effort, it did work.

Thoughts?

I'm guessing the "int" at line 7 should be "unsigned long".

(You're much more likely to get help if you post your code.)

-br

lost_and_confused:
Why would it be that code which used to work doesn't work now if I haven't done any mechanical changes?

It could have a race condition that is temperature dependent.

You could have been just lucky before.

It might rely on uninitialized variables that have different contents this time.

Well, if someone could PLEASE be bothered looking here is the story:

"afy" works.

afya is one of the "work in progress" but used to and now doesn't. It hangs anywhere from a few seconds into to a few minutes into running.

afya_old IS the original KNOWN WORKING version.

I luckily had this backed up.

afya_W is the next generation of mods to do and get working.

I am working on another version with a whole lot of code re-written but for now it all has to wait on understanding what is going on with the code now because it used to work and now doesn't.

V10afy.zip (22.4 KB)

V10afya.zip (22.9 KB)

V10afya_old.zip (22.9 KB)

V10afya_W.zip (22.9 KB)

Other things that were noticed to happen:

(Yeah, shame on me for not really noting which version)

There is a "skip day" function to allow flexy days to be skipped by the alarm.

I was flashing it on said day.

So what happened/s:
When the sketch runs, it looks at the DOW (day of week) and checks it to a value. If they match, it sets another flag to "Skip the alarm".

As it was on the SKIP DAY, the sketch would run and I would expect the flag to be set.
Some sketches would set it, some would not.
Some would set it then re-set it.

All would also die/hang/crash.

I have studied the { } matching and I can't see any problems.

There is a possible problem that some of my routines return things when the calling routine isn't expecting a value back.
So I tried to tidy that up and put in things like:
dummy = my_routine(1);

but the sketch still died.

Rip me a new one if you must, but I would really find it more useful and educational if I was helped and not anatomically modified.

I would worry that V10afy_W.zip includes a copy of Arduino.h. That might cause a conflict with the standard Arduino.h.

F

johnwasser:
I would worry that V10afy_W.zip includes a copy of Arduino.h. That might cause a conflict with the standard Arduino.h.

They all have a file called Arduino.h so I am missing something.

Nothing jumps out as broken. It is a lot of code.

You don't need to do the dummy=function(…) thing. The compiler will warn you but it won't break anything.

Your complaints about the problem behavior are very general. I would start by characterizing what happens when "it dies" a little better using carefully placed Serial.print() statements and maybe toggling an LED or two if that's possible.

-br

lost_and_confused:
F

johnwasser:
I would worry that V10afy_W.zip includes a copy of Arduino.h. That might cause a conflict with the standard Arduino.h.

They all have a file called Arduino.h so I am missing something.

WHY do you have a file called Arduino.h? That's a very important header in the standard Arduino libraries. If you have one of your own it may cause a conflict.

I note that your sketch includes:

#define alarm_EEPROM_storage 100 // Where the alarm is saved.  The first 100 bytes are for other things.
#define EEPROM_user 0           // Where I put my things/

If the format of stuff you store in EEPROM changes from version to version you will have a problem with running different versions in different orders. Do you have version information in the EEPROM that you check before using any of the data? Doesn't look like it.

Ok, granted.

The EEPROM data is simply the alarm times, and the list of variables shown/listed/declared shortly after.

There may be new ones added - thus the 100 offset - as the original offset was 10.
I realised that 10 just wasn't enough.

However: There are no new variables.
As "fanatical" as I may seem with them, I realise that it can become too confusing and I am trying to keep GLOBAL variables to a minimum.

What I was told is that each "routine" should do their thing and return a basic "go/no go" value which tells the bigger program the result. Nothing too complicated.

But sometimes I can't work out an easier way of doing it than with global names, especially if the same is used by many routines.

It is more the code's structure and functionality which have changed between "releases".

I have sat down and used a compare program to find the differences with the files I use, not the .h and .ccp files, and there are hardly any.

And what I see them as I can't understand how they are causing the crash.

I suspect there are other underlying problems which I haven't seen/found yet. But I can sit here until the cows come home, I can't see them with the understanding I have.

What you say is true. You won't solve the problem with the understanding you have.

So go get some more understanding by instrumenting what it's actually doing. Put some print statements in places you expect to generate periodic output. What is the last thing it does before it dies?

You haven't even, really, told us what you mean when you say "it dies". Once you understand that better, by instrumenting your code a bit, you might see the answer.

-br

Well, dying meaning the program just stops running.

I have lines which print the time out the serial port and a wee bit more stuff, but that just stops happening also.

It isn't I want to be spoon fed the solution, but I am stumped to what in the small difference there is between the codes that makes it crash.

As I mentioned, one code works perfectly - as in runs without crashing - but the next version it crashed usually within a few minutes.

I don't know if there is a correlation, but sometimes as soon as I press a button it dies. Sorry: crashes.
I can't say if it was caused by the button press or not, but if I reboot it and don't press the button, it doesn't crash then, but does a few seconds/minutes later anyway.

I think johnwasser raised a very important question that needs immediate attention. If you had EEPROM_storage as 10 before in past versions and 100 in current versions, then how does your current version know that it should rewrite EEPROM with 100 offset, instead of assuming 100 offset format was already in place and be mistaken. I am sorry I am on my ipad again, no zip files get opened on this tech wonder. Where in your code do you erase EEPROM and rewrite it in 100 offset format?

I've been researching.

Question:
Has anyone actually tried to compile the codes?

I know this is going to be a bit stupid sounding, but anyway.....
I am not sure what Arduino I have - I am pretty sure it is an "Uno" or copy.

How much memory do these things have?
Will I be told if the program/sketch exceeds the memory limits of the board?

Why I am asking:
The other night I had time to try and find out why the other sketches are failing.

So, starting with the one which does work, I added TWO lines of:
Serial.println(" ");
with text between the "

The sketch failed/died/crashed/hung/what ever.

Removing the lines, it worked.

So when it was compiling, I noticed that it got to 27,xxx of 32,xxx and thought: Wow that is getting to be abig sketch.

Then it hit me that maybe there is a memory problem.

Anyone, please?

So when it was compiling, I noticed that it got to 27,xxx of 32,xxx and thought: Wow that is getting to be abig sketch.

Using that amount of flash probably also point to you running out of RAM.

Has anyone actually tried to compile the codes?
I think I compiled one of the four versions you posted.

How much memory do these things have?
– 32K Bytes of In-System Self-Programmable Flash program memory
– 1K Bytes EEPROM
– 2K Bytes Internal SRAM

Will I be told if the program/sketch exceeds the memory limits of the board?
FLASH, yes. SRAM or EEPROM, no.

Example_menu seems to have a lot of strings not in PROGMEM.

//        This routine is now not used.

Nice. Thanks.

AWOL:
Example_menu seems to have a lot of strings not in PROGMEM.

//        This routine is now not used.

Nice. Thanks.

I think some of the code might have come from my original alarm clock code for phi-2 shield and the OP is no longer in need of those.

Guys,

That code is not used. Granted.

It was blocked out so if there were problems I could quickly get back to it.

As it is remarked out, it won't be uploaded to the Arduino - right?

So really I could have 2 meg of comments and it wouldn't really change how much the ACTUAL sketch uses/needs.

Now I have to go through and remove all the old stuff from the original alarm clock code which I don't use/need.

Like the big font and remove all references to it.

I hope that gives me more memory. Well, a LOT MORE memory.
What I am wanting to add may need a fairly good bit of memory.

When I get time I will try and and see what happens.

Thanks for now.

You don't have much flash remaining to store strings so unless you can trim your code and structures it might be worth considering some external flash for storing strings in.