Why did you post the source code again? You still haven't managed to make use of the "Insert Program Code" button.

Why don't the code posted by you look like the following?

void int_to_digits(unsigned long number) //store the digits of an integer number in the variable a,b,c,d
{
    float itd_a,itd_b,itd_c,itd_d,itd_e;
    itd_a = itd_a = number / 10.0;
    dig[3] = floor((modf(itd_a,&itd_b)* 10));
    itd_b = itd_b / 10.0;
    dig[2] = floor((modf(itd_b,&itd_c)* 10));
    itd_c = itd_c / 10.0;
    dig[1] = floor((modf(itd_c,&itd_d)* 10));
    itd_d = itd_d / 10.0;
    dig[0] = floor((modf(itd_d,&itd_e)* 10));
}

 

And why do you still make use of floating point? What is wrong with integer arithmetic when your input is an integer and your resulting digits are expected to be digits? Right now, you seem to have removed that 0.5 rounding too which means that it was either arbitrarily you added the 0.5 or that you removed it...

"Programming by trial-and-error" is not an efficient method.

modf() seems to produce a modulo with floating point numbers. But if you google for modulo and integers, you might even find a suggestion how to find a modulo for integers without involving floating point values. If you search on this site, you can even find examples written by me (and probably also by others) for converting an integer into individual digits for presentation on some arbitrary display.

A lazy user could even make use of sprintf(). Big function but still better than using floor() and modf() and the use of "almost exact" floating-point numbers.

By the way - you still haven't mentioned what debugging you have done. If you had debugged your display output code by hard-coding a number to convert into digits and display, you would already have noticed that oops you had with copy-and-paste of same variable names in int_to_digits(). So it is quite obvious that you have not been busy debugging.

Debugging is the art of breaking a problem down into smaller problems, and evaluating which of them that does the expected thing (for all allowed input stimuli) and what doesn't. And then continue to break down the problem into smaller pieces until a piece is simple enough that you understand why it doesn't do what it should. Obviously, the same concept is done when writing the code in the first place too. You reduce a big problem into smaller sub-problems until they are simple enough that you can clearly see how they can be converted into source code.

Measuring with the wrong time constant?

So how hard is it to have your code generate a 1Hz signal on a pin and manually verify that you get 60 pulses in a minute? How hard is it then to have your own code measure the length of the pulse and see if the measured length of high+low is really 1000ms?

Get starting. Tell us what alternatives you see for testing different parts of the code. Then test the code. Then report the outcome and your conclusions. A doctor can't just mail a web forum and say: I have a patient. Here is a photo of the patient and a blood sample. Tell me what is wrong. A doctor has to make own deductions to narrow down the potential problems. Programming isn't the one magic area where web forums are the route to go.