Hi Tom/Pete,

I DID include a minimized version in my original posting on this thread. Take a look - it's still there in the body.

I also sent this to Digi support and we are working through it. They suggested going to 9.62, and they cannot reproduce the behaviour using an RCM3700.

My problem manifests itself with an RCM3000, and 9.62 still shows the problem.

I asked them to try an RCM3000 ... no reply yet.

We are continuing ...

Regards,
Mario

--- In r..., Tom Collins wrote:
>
> Pete's right about that -- and you can then contact support@... to have them investigate the problem as well.
>
> -Tom
> On Nov 21, 2011, at 5:44 AM, Fournier, Peter wrote:
> > Sounds like it is now the time to build a minimized version of your program to make it easier to see if there is some function or statement that causes the issue. Something which other people might be willing to build/look at and see if they get the same results.
> > -Pete F

Pete's right about that -- and you can then contact s...@rabbit.com to have them investigate the problem as well.

-Tom
On Nov 21, 2011, at 5:44 AM, Fournier, Peter wrote:
> Sounds like it is now the time to build a minimized version of your program to make it easier to see if there is some function or statement that causes the issue. Something which other people might be willing to build/look at and see if they get the same results.
> -Pete F
> -----Original Message-----
> From: r... [mailto:r...] On Behalf Of mario_wtbbh
> Sent: Sunday, November 20, 2011 5:15 PM
> To: r...
> Subject: [rabbit-semi] Re: Difference between flashing with DC9.52 and RFU3.02 - Virtual Watchdog
>
> Just tried DC9.62+patches. Now direct DC9.62 compile (UN-checked RST28 and UN-checked Debug kernel) works correctly. However, RFU3.05 burn still does not. RFU has same symptom as before: always returns false on chkWDTO().
>
> I am still to see if our "real" program can be locked in a closed loop with 9.62 with the watchdog enabled, and loaded by RFU3.05.
> (As was the original symptom, in addition to the non-detection of chkWDTO())
>
> --- In r..., Steve Trigero wrote:
> >
> > You might try v9.62. As I recall, there were problems with all
> > versions between 9.25 and 9.62.
> >
> >
> >
> > >________________________________
> > > From: mario_wtbbh
> > >To: r...
> > >Sent: Thursday, November 17, 2011 6:42 PM
> > >Subject: [rabbit-semi] Re: Difference between flashing with DC9.52
> > >and RFU3.02 - Virtual Watchdog
> > >
> > >
> > >br /> > > >MORE INFO (While comparing the LST file)
> > >
> > >* DC-Direct build to RCM, with RST28 UN-checked, [Debugger] Enable Debug Kernel UN-checked, build/disconnect/run:
> > >
> > >* Result: The Watchdog (mis)behaves like the build loaded from RFU.
> > >According to Help, the debug kernel "... (only) affects the behavior of Dynamic C while running/debugging a program" (implying N/A for RFU). I've confirmed this with the larger LST file produced.
> > >
> > >So therefore, here is the REAL question: Why does the Virtual Watchdog need the Debug Kernel to operate correctly?
> > >
> > >--- In r..., "mario_wtbbh" wrote:
> > >>
> > >> Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
> > >> (If I intentionally enable RST28, the file grows as expected)
> > >>
> > >> P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.
> > >>
> > >> This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).
> > >>
> > >> The fact that I can isolate the problem to the simple program listed worries me.
> > >>
> > >> We are an experienced developer with over 2000 units in the field
> > >> (see www.eStateAutomation.com.au)
> > >>
> > >>
> > >> --- In r..., Tom Collins wrote:
> > >> >
> > >> > You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
> > >> >
> > >> > Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
> > >> >
> > >> > -Tom
> > >> >
> > >> >
> > >> > On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
> > >> >
> > >> > > Thanks for your reply, Scott.
> > >> > >
> > >> > > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> > >> > >
> > >> > > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
> > >> > >
> > >> > > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
> > >> > >
> > >> > > I will try it with our "real" program to see if I can still lock it up.
> > >> > >
> > >> > > >
> > >> > > > Have you set the correct board type for targetless compile?
> > >> > > >
> > >> > > > Make sure "include bios' is checked in the advanced options.
> > >> > > >
> > >> > > > Try using "compile to .bin using attached target".
> > >> > > >
> > >> > > > ------
> > >> > > > Scott G. Henion, Consultant
> > >> > > > Web site: http://SHDesigns.org
> > >> > > > ------
> > >> > > >
> .
>
>
>

Sounds like it is now the time to build a minimized version of your program to make it easier to see if there is some function or statement that causes the issue. Something which other people might be willing to build/look at and see if they get the same results.
-Pete F

-----Original Message-----
From: r... [mailto:r...] On Behalf Of mario_wtbbh
Sent: Sunday, November 20, 2011 5:15 PM
To: r...
Subject: [rabbit-semi] Re: Difference between flashing with DC9.52 and RFU3.02 - Virtual Watchdog

Just tried DC9.62+patches. Now direct DC9.62 compile (UN-checked RST28 and UN-checked Debug kernel) works correctly. However, RFU3.05 burn still does not. RFU has same symptom as before: always returns false on chkWDTO().

I am still to see if our "real" program can be locked in a closed loop with 9.62 with the watchdog enabled, and loaded by RFU3.05.
(As was the original symptom, in addition to the non-detection of chkWDTO())

--- In r..., Steve Trigero wrote:
>
> You might try v9.62. As I recall, there were problems with all
> versions between 9.25 and 9.62.
>
>
>
> >________________________________
> > From: mario_wtbbh
> >To: r...
> >Sent: Thursday, November 17, 2011 6:42 PM
> >Subject: [rabbit-semi] Re: Difference between flashing with DC9.52
> >and RFU3.02 - Virtual Watchdog
> >
> >
> >br /> > >MORE INFO (While comparing the LST file)
> >
> >* DC-Direct build to RCM, with RST28 UN-checked, [Debugger] Enable Debug Kernel UN-checked, build/disconnect/run:
> >
> >* Result: The Watchdog (mis)behaves like the build loaded from RFU.
> >According to Help, the debug kernel "... (only) affects the behavior of Dynamic C while running/debugging a program" (implying N/A for RFU). I've confirmed this with the larger LST file produced.
> >
> >So therefore, here is the REAL question: Why does the Virtual Watchdog need the Debug Kernel to operate correctly?
> >
> >--- In r..., "mario_wtbbh" wrote:
> >>
> >> Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
> >> (If I intentionally enable RST28, the file grows as expected)
> >>
> >> P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.
> >>
> >> This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).
> >>
> >> The fact that I can isolate the problem to the simple program listed worries me.
> >>
> >> We are an experienced developer with over 2000 units in the field
> >> (see www.eStateAutomation.com.au)
> >>
> >>
> >> --- In r..., Tom Collins wrote:
> >> >
> >> > You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
> >> >
> >> > Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
> >> >
> >> > -Tom
> >> >
> >> >
> >> > On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
> >> >
> >> > > Thanks for your reply, Scott.
> >> > >
> >> > > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> >> > >
> >> > > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
> >> > >
> >> > > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
> >> > >
> >> > > I will try it with our "real" program to see if I can still lock it up.
> >> > >
> >> > > >
> >> > > > Have you set the correct board type for targetless compile?
> >> > > >
> >> > > > Make sure "include bios' is checked in the advanced options.
> >> > > >
> >> > > > Try using "compile to .bin using attached target".
> >> > > >
> >> > > > ------
> >> > > > Scott G. Henion, Consultant
> >> > > > Web site: http://SHDesigns.org
> >> > > > ------
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> >
>

Just tried DC9.62+patches. Now direct DC9.62 compile (UN-checked RST28 and UN-checked Debug kernel) works correctly. However, RFU3.05 burn still does not. RFU has same symptom as before: always returns false on chkWDTO().

I am still to see if our "real" program can be locked in a closed loop with 9.62 with the watchdog enabled, and loaded by RFU3.05.
(As was the original symptom, in addition to the non-detection of chkWDTO())

--- In r..., Steve Trigero wrote:
>
> You might try v9.62. As I recall, there were problems with all versions
> between 9.25 and 9.62.
>
>
>
> >________________________________
> > From: mario_wtbbh
> >To: r...
> >Sent: Thursday, November 17, 2011 6:42 PM
> >Subject: [rabbit-semi] Re: Difference between flashing with DC9.52 and RFU3.02 - Virtual Watchdog
> >
> >
> >
> >MORE INFO (While comparing the LST file)
> >
> >* DC-Direct build to RCM, with RST28 UN-checked, [Debugger] Enable Debug Kernel UN-checked, build/disconnect/run:
> >
> >* Result: The Watchdog (mis)behaves like the build loaded from RFU.
> >According to Help, the debug kernel "... (only) affects the behavior of Dynamic C while running/debugging a program" (implying N/A for RFU). I've confirmed this with the larger LST file produced.
> >
> >So therefore, here is the REAL question: Why does the Virtual Watchdog need the Debug Kernel to operate correctly?
> >
> >--- In r..., "mario_wtbbh" wrote:
> >>
> >> Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
> >> (If I intentionally enable RST28, the file grows as expected)
> >>
> >> P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.
> >>
> >> This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).
> >>
> >> The fact that I can isolate the problem to the simple program listed worries me.
> >>
> >> We are an experienced developer with over 2000 units in the field (see www.eStateAutomation.com.au)
> >>
> >>
> >> --- In r..., Tom Collins wrote:
> >> >
> >> > You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
> >> >
> >> > Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
> >> >
> >> > -Tom
> >> >
> >> >
> >> > On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
> >> >
> >> > > Thanks for your reply, Scott.
> >> > >
> >> > > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> >> > >
> >> > > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
> >> > >
> >> > > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
> >> > >
> >> > > I will try it with our "real" program to see if I can still lock it up.
> >> > >
> >> > > >
> >> > > > Have you set the correct board type for targetless compile?
> >> > > >
> >> > > > Make sure "include bios' is checked in the advanced options.
> >> > > >
> >> > > > Try using "compile to .bin using attached target".
> >> > > >
> >> > > > ------
> >> > > > Scott G. Henion, Consultant
> >> > > > Web site: http://SHDesigns.org
> >> > > > ------
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> >
>

You might try v9.62. As I recall, there were problems with all versions
between 9.25 and 9.62.

>________________________________
> From: mario_wtbbh
>To: r...
>Sent: Thursday, November 17, 2011 6:42 PM
>Subject: [rabbit-semi] Re: Difference between flashing with DC9.52 and RFU3.02 - Virtual Watchdog
>
>MORE INFO (While comparing the LST file)
>
>* DC-Direct build to RCM, with RST28 UN-checked, [Debugger] Enable Debug Kernel UN-checked, build/disconnect/run:
>
>* Result: The Watchdog (mis)behaves like the build loaded from RFU.
>According to Help, the debug kernel "... (only) affects the behavior of Dynamic C while running/debugging a program" (implying N/A for RFU). I've confirmed this with the larger LST file produced.
>
>So therefore, here is the REAL question: Why does the Virtual Watchdog need the Debug Kernel to operate correctly?
>
>--- In r..., "mario_wtbbh" wrote:
>>
>> Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
>> (If I intentionally enable RST28, the file grows as expected)
>>
>> P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.
>>
>> This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).
>>
>> The fact that I can isolate the problem to the simple program listed worries me.
>>
>> We are an experienced developer with over 2000 units in the field (see www.eStateAutomation.com.au)
>> --- In r..., Tom Collins wrote:
>> >
>> > You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
>> >
>> > Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
>> >
>> > -Tom
>> >
>> >
>> > On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
>> >
>> > > Thanks for your reply, Scott.
>> > >
>> > > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
>> > >
>> > > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
>> > >
>> > > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
>> > >
>> > > I will try it with our "real" program to see if I can still lock it up.
>> > >
>> > > >
>> > > > Have you set the correct board type for targetless compile?
>> > > >
>> > > > Make sure "include bios' is checked in the advanced options.
>> > > >
>> > > > Try using "compile to .bin using attached target".
>> > > >
>> > > > ------
>> > > > Scott G. Henion, Consultant
>> > > > Web site: http://SHDesigns.org
>> > > > ------
>> > > >
>> > >
>> > >
>> >
>

MORE INFO (While comparing the LST file)

* DC-Direct build to RCM, with RST28 UN-checked, [Debugger] Enable Debug Kernel UN-checked, build/disconnect/run:

* Result: The Watchdog (mis)behaves like the build loaded from RFU.
According to Help, the debug kernel "... (only) affects the behavior of Dynamic C while running/debugging a program" (implying N/A for RFU). I've confirmed this with the larger LST file produced.

So therefore, here is the REAL question: Why does the Virtual Watchdog need the Debug Kernel to operate correctly?
--- In r..., "mario_wtbbh" wrote:
>
> Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
> (If I intentionally enable RST28, the file grows as expected)
>
> P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.
>
> This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).
>
> The fact that I can isolate the problem to the simple program listed worries me.
>
> We are an experienced developer with over 2000 units in the field (see www.eStateAutomation.com.au)
> --- In r..., Tom Collins wrote:
> >
> > You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
> >
> > Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
> >
> > -Tom
> >
> >
> > On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
> >
> > > Thanks for your reply, Scott.
> > >
> > > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> > >
> > > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
> > >
> > > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
> > >
> > > I will try it with our "real" program to see if I can still lock it up.
> > >
> > > >
> > > > Have you set the correct board type for targetless compile?
> > > >
> > > > Make sure "include bios' is checked in the advanced options.
> > > >
> > > > Try using "compile to .bin using attached target".
> > > >
> > > > ------
> > > > Scott G. Henion, Consultant
> > > > Web site: http://SHDesigns.org
> > > > ------
> > > >
> > >
> > >
>

Excellent thought (LST output) - I'll try that next and will let you know. Definitely not RST28 enabled in both cases.
(If I intentionally enable RST28, the file grows as expected)

P.S. Do you happen to have an RCM3xxx and the quoted compiler version handy? It would be great if you tried the sample for yourself.

This is not the first time customers have noted different behaviour between a DC9 build and RFU. (Most recently we had one problem which I traced to a global variable I declared in a library and used in the main code - problem fixed by declaring low in main prog).

The fact that I can isolate the problem to the simple program listed worries me.

We are an experienced developer with over 2000 units in the field (see www.eStateAutomation.com.au)
--- In r..., Tom Collins wrote:
>
> You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.
>
> Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?
>
> -Tom
> On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:
>
> > Thanks for your reply, Scott.
> >
> > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> >
> > I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
> >
> > I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
> >
> > I will try it with our "real" program to see if I can still lock it up.
> >
> > >
> > > Have you set the correct board type for targetless compile?
> > >
> > > Make sure "include bios' is checked in the advanced options.
> > >
> > > Try using "compile to .bin using attached target".
> > >
> > > ------
> > > Scott G. Henion, Consultant
> > > Web site: http://SHDesigns.org
> > > ------
> > >
> >
>

You could try enabling the .LST file for each build, and then performing a diff on the two .LST files to see what changes.

Could it be that you have RST28's enabled in the Compile-to-target but they're disabled in compile-to-bin?

-Tom
On Nov 16, 2011, at 5:55 PM, mario_wtbbh wrote:

> Thanks for your reply, Scott.
>
> I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
>
> I have always checked "Include BIOS", and in the reload of DC9.52 from the web, that check is now on and greyed (so you can't turn it off).
>
> I have just tried your other suggestion "Compile to bin using attached target" and that shows the same problem with the minimal program.
>
> I will try it with our "real" program to see if I can still lock it up.
>
> >
> > Have you set the correct board type for targetless compile?
> >
> > Make sure "include bios' is checked in the advanced options.
> >
> > Try using "compile to .bin using attached target".
> >
> > ------
> > Scott G. Henion, Consultant
> > Web site: http://SHDesigns.org
> > ------
> >

Hi Scott, that's what I meant by "matching Rabbit 3000 revision ... "

Here is a full export of the RTI for "Board Selection, Targetless", precisely the same as the physical board.

Board ID=0x0F00
Board Name)MHz RCM3000, 512K SRAM, 512K Flash
CPU Name=Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T
CPU ID000
CPU Revision=1
Crystal Speed (MHz).7456
RAM Size (KBytes)Q2
(Primary) Flash Size (KBytes)%6

Regards,
Mario

--- In r..., Scott Henion wrote:
>
> On 11/16/2011 8:55 PM, mario_wtbbh wrote:
> > Thanks for your reply, Scott.
> >
> > I have been using the matching revision "Rabbit 3000 revision IL2T/IZ2T/UL2T/UZ2T", still with the same problem (also tried Rabbit 3000 revision IL1T/IZ1T).
> > I'm not talking about the processor version. I said the targetless board
> type (set in the targetless tab of the options.) It is the #1 reported
> problem with my DLM's. Seems everyone assumes it does not need to be set.
>
> Also, recent versions seem to randomly change the targetless option.
>
> --
> ------
> Scott G. Henion, Consultant
> Web site: http://SHDesigns.org
> ------
>