Difference between flashing with DC9.52 and RFU3.02 - Virtual Watchdog

Virtual Watchdog Operation.

I am observing a difference in a program compiled to an RCM3xxx directly
with DC9.52, compared to compile-to-disk and load via RFU 3.02.
(Everything works correctly, including chkWDTO(), with direct DC9.52
compile to target in release mode; no RST 28)

For our "real" program:

With the RFU load version, I can lock the program in a loop, and it does
not reset.

For the minimal program (see below):

The unit DOES reset, but never displays the "Watchdog reset" message
(chkWDTO() always returns false)

The attached program assumes a terminal attached to Port C.
Pressing the space-bar will lock it in a closed loop.

How can I make certain that RFU & DC produce the same result? All BIOS
files, etc. are from the same working directory.

I even went as far as a fresh load of DC9.52 from Digi.

= = = = = = = = = = = = = = =
#define CINBUFSIZE 255
#define COUTBUFSIZE 255

#define ScaleWDSec(X) (int)(X * 1000.0 / 62.5) // Watchdog Timebase is
62.5ms

void main(void)
{
int wd;
int bEnable;
static int ModeWD;
unsigned long dwDelay;

ModeWD = chkWDTO();
wd = VdGetFreeWd(ScaleWDSec(5));

serCopen(19200);

if(ModeWD)
serCputs("\r\n>>> System W/D restart! <<<\r\n");
else
serCputs("\r\n>>> System normal restart. <<<\r\n");

serCputs("Press the space-bar to block the watchdog-reset.\r\n");

bEnable = TRUE;

while(1)
{
costate
{
if(bEnable)
VdHitWd(wd);
waitfor(DelaySec(1));
}

if(serCgetc() == ' ')
{
bEnable = FALSE;
serCputs("\r\bClosed Loop ... should reset in 5 sec.\r\n");
dwDelay = SEC_TIMER;
while(1)
{
if((SEC_TIMER - dwDelay) >= 1)
{
serCputs("Reset pending ...\r\n");
dwDelay = SEC_TIMER;

// Don't use 'waitfor()' to ensure no other costate gets a chance
to run
}
}
}
}
} Start a New Thread

On 11/16/2011 8:00 PM, mario_wtbbh wrote:
> *Virtual Watchdog Operation.*
>
> I am observing a difference in a program compiled to an RCM3xxx
> directly with DC9.52, compared to compile-to-disk and load via RFU
> 3.02. (Everything works correctly, including chkWDTO(), with direct
> DC9.52 compile to target in release mode; no RST 28)
>
> *For our "real" program:*
>
> With the RFU load version, I can lock the program in a loop, and it
> does not reset.
>
> *For the minimal program (see below):*
>
> The unit DOES reset, but never displays the "Watchdog reset" message
> *(chkWDTO() always returns false)*
>
> The attached program assumes a terminal attached to Port C.
> Pressing the space-bar will lock it in a closed loop.
>
> *How can I make certain that RFU & DC produce the same result? * All
> BIOS files, etc. are from the same working directory.
>
> I even went as far as a fresh load of DC9.52 from Digi.
>
> = >

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
------ Start a New Thread

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
> ------
>

Start a New Thread

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
------

Start a New Thread

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
> ------
>

Start a New Thread

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
> > ------
> > Start a New Thread

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
> > > ------
> > >
> >
>

Start a New Thread

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
> > > > ------
> > > >
> > >
> > >
>

Start a New Thread

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
>> > > > ------
>> > > >
>> > >
>> > >
>> >
> Start a New Thread

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
> >> > > > ------
> >> > > >
> >> > >
> >> > >
> >> >
> >>
> >
> >
> >
> >
>

Start a New Thread