Page 1 of 1

Think i have found the Base Timing Bug ...

Posted: Fri May 09, 2014 4:49 pm
by Rudi
PIC24FJ256GB106
32000000clk
20MHz/Div5


hi

i have make a simple Project with LED and Delay
all is the same - only delay i change ...


( Millisec only 0...2000 )
250ms, 500ms, 1000ms, 1250 ms, 1500ms, 2000ms

and same code but in sec

1s, 2s, 3s

2 sec delay
i get a value of 30 in Real Time 60 sec .. this is right

2000ms delay
i get a value of 15 in Real Time 60 sec.. this is wrong // must be 30

same in

1sec delay
i get a value of 60 in Real Time 60 sec.. this is right

1000ms delay
i get a value of 30 in Real Time 60 sec .. this is wrong // must be 60

..
750ms delay
i get a value of 40 in Real Time 60 sec ... this is wrong // must be 80

500ms delay
is the same Delay like 1s . i get a value of 60 in Real Time 60 sec .. this is wrong // must be 120

whats happend?
;-)..

I think i find the "little bug" that in Uart, USB, SPI, SD, Delay.. in ms ..
..this a calculate mistake in s / ms ? ;-)

can u please check it - i am sure - this is going wrong ;-)

..
TIP:
-----
The
#define MX_CLKS_PER_INST 2
or
#define MX_CLKS_PER_INST 1
do not change the value in ms delay
( same value*s )

but
change in s delay
example

1s delay with #define MX_CLKS_PER_INST 2 .. the Value is 60 in a Real Time 60 sec... thats right
1s delay with #define MX_CLKS_PER_INST 1 .. the Value is 30 in a Real Time 60 sec... thats changed the value


..
1000ms delay with #define MX_CLKS_PER_INST 2 .. the Value is 30 in a Real Time 60 sec ...
1000ms delay with #define MX_CLKS_PER_INST 1 .. same Value 30 in a Real Time 60 sec ...





Best wishes.
LG
Rudi
;-)

Re: Think i have found the Base Timing Bug ...

Posted: Sat May 10, 2014 3:35 pm
by Rudi
Hi
Sorry, now i know, without the Custom Compo can someone not test.
I will upload the *.fcfx from the Custom compo too.
it's my own "First Compo" ;-)

at time i search for it.. i do not know at time, have i renamed the src ;-/
.. but i will make it all new if i not find..

but

For testing the ms / s delay

Create a new project
Pic24FJ256GB108
32000000 CLK
20 MHz/div5
supplementary code
#define MX_CLKS_PER_INST 2

make a simple Flashing LED

with 1000ms delay

with 1s delay.

it will be a difference

the #define MX_CLKS_PER_INST
set it to 2
set it to 1

in s delay it will be a change
in ms delay no change


..
Best wishes
Rudi
;-)

Re: Think i have found the Base Timing Bug ...

Posted: Sat May 10, 2014 4:37 pm
by Rudi
Hi,
I added a new with Base Compo.

(
i do not find my src to my first compo just in time.. this is not good so must make later new
lection 1. do not forget your src code for your own compo... ok i will remeber next compo... ;-) ;-) )
)

but here :
two project with base compo..
one with 1s delay
one with 1000ms delay.

the 1s delay runs ok
the 1000ms delay runs 2xslower

the
#define MX_CLKS_PER_INST
in supplementary code
example
#define MX_CLKS_PER_INST 2
to
#define MX_CLKS_PER_INST 1
..

in the s delay project is changed the delay
in the ms delay project no change in delay.

i hope this helps to find the ghost in Timing..

Best wishes
Rudi
;-)
btw
in sumulation: the s / ms delay is same.

Re: Think i have found the Base Timing Bug ...

Posted: Tue May 13, 2014 2:48 pm
by Rudi
?

Re: Think i have found the Base Timing Bug ...

Posted: Tue May 13, 2014 5:23 pm
by DavidA
Hello Rudi,

The bug is on our lists, we are not due another release however for a while and hopefully it will be fixed when the next release is due

Re: Think i have found the Base Timing Bug ...

Posted: Tue May 13, 2014 7:04 pm
by SHORTCIRCUIT
Hi David

Just about when is the next release due to be released?

Re: Think i have found the Base Timing Bug ...

Posted: Thu May 15, 2014 5:25 pm
by mikn
SHORTCIRCUIT wrote: Just about when is the next release due to be released?
+1
Also waiting for new release with bug fixed. No need for new features while there are so many current bugs. :-(

Re: Think i have found the Base Timing Bug ...

Posted: Thu May 15, 2014 7:30 pm
by Rudi
DavidA wrote:Hello Rudi,

The bug is on our lists, we are not due another release however for a while and hopefully it will be fixed when the next release is due
Thanks for the confirmation, David! If at least a workaround possible?

Only in demand:
Is there an official open bug list to read? Which are resolved or a workaround?
It may happen so that you can just try something new, which at the moment is not possible perhaps due to a known bug. That would help a little in go on with new/next projects.
Not everyone reads all threads ;-)
Ok.

Best wishes.
Rudi


"Do not fret ... ;-) "

Re: Think i have found the Base Timing Bug ...

Posted: Tue May 20, 2014 2:05 pm
by RobH
Is this a similar bug to the one you guys are talking about?

Loop 500 counts of 10ms delays ran fine in simulation, but not on hardware (16f917 intosc). It seemed to get stuck somewhere in a loop. I ended up making two 250 counts of 10ms and it worked fine. Or is this a hardware issue?

Re: Think i have found the Base Timing Bug ...

Posted: Wed May 21, 2014 10:46 am
by Rudi
RobH wrote:Is this a similar bug to the one you guys are talking about?

Loop 500 counts of 10ms delays ran fine in simulation, but not on hardware (16f917 intosc). It seemed to get stuck somewhere in a loop. I ended up making two 250 counts of 10ms and it worked fine. Or is this a hardware issue?

Make a simple LED Flashing

in one Try make the delay 1S
flash your Mikrocontroller and controll the time

in one Try make the delay 1000ms
flash your Mikrocontroller and controll the time

same you can try with

in one Try make the delay 2S
flash your Mikrocontroller and controll the time

in one Try make the delay 2000ms
flash your Mikrocontroller and controll the time

and you know that will be go right or fail..
if fail, please post yours.

TY
Rudi

Re: Think i have found the Base Timing Bug ...

Posted: Wed May 21, 2014 1:50 pm
by RobH
I fixed my issue by nesting loops.

Re: Think i have found the Base Timing Bug ...

Posted: Tue May 27, 2014 1:39 pm
by SteveM
RobH wrote:Loop 500 counts of 10ms delays ran fine in simulation, but not on hardware (16f917 intosc). It seemed to get stuck somewhere in a loop.
Hi Rob,
I just checked this out in the compiled code - it seems that the hardware is always using a single byte as the loop index counter, even if you specify a "wider" variable type for the loop index (e.g. a UINT). That limits the maximum number of loops to 255 - any more than that, and the 'counter' byte will 'wrap around' to zero, making the loop get stuck, as it will never reach any bigger number.
I'll add this to our bugs list - either the hardware code should use a 'wider' variable, or we should make sure that simulation matches the hardware (with an appropriate warning if the loop count is too large!).
Best regards,
Steve.