Reply by Mike McCarty ●February 21, 20072007-02-21
yuldu25 wrote:
> Hi and thanks again,
> Well, I'm not using a monitor, I can't do a memory dump and the
> program is :
> 28 298 bytes of CODE memory (not enough place for a monitor)
> 1 165 bytes of DATA memory
> I think the best way is to make a simpler program, I will do that in
> my free time.

That was my suggestion. Remove Check_Comms() (and all it calls)
and just get something that detects COP failure first.

> I certainly don't dominate the IAR toolset.

:-)

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by yuldu25 ●February 21, 20072007-02-21
Hi and thanks again,
Well, I'm not using a monitor, I can't do a memory dump and the
program is :
28 298 bytes of CODE memory (not enough place for a monitor)
1 165 bytes of DATA memory
I think the best way is to make a simpler program, I will do that in
my free time.
I certainly don't dominate the IAR toolset.

Regards
Julien

--- In m..., Mike McCarty wrote:
>
> yuldu25 wrote:
> > Hi Mike and Ian,
> > For the endless loop, here is a part of my main:
>
> Ok, so this is a test program for experimentation.
> I'd cut out Check_Comms() for testing.
>
> > ******************************************************
> > iForcres=0; /*This variable is used to generate timeout and illegal
> > opcode; it's a EEPROM variable. I could change it's value with serial
> > command */
> > for(;;)
> > {
> > COPRST=0x55;
> > COPRST=0xaa; /*Reset WD timer*/
> > Check_Comms();
> > if(iForcres==1) //Generate a timeout for WD
> > {
> > for(;;)
> > {
> > }
> > }
> > if(iForcres==2) //Generate illegal OPCODE (only for test)
> > {
> > _opc(0x42);
> > }
> > }
> > ******************************************************
> > I'm "tickling" the COP, but perhaps as you say: I made some changes
> > and the COP timing is perhaps slightly longer. I'm verifying it. Wait
> > and see....
>
> How much time can Check_Comms() take? You can figure the worst
> case and see whether it exceeds the COP timeout.
>
> >>>If I don't write the interrupt routine for the COP, for the CME...it
> >>>resets automatically !
> >>
> >>I'm afraid I'm having trouble understanding exactly what this
> >>means.
>
> [snip]
>
> > If I write and compile the project with or without the previous
> > NOCOP_interrupt() it has the same effect: there is a reset when I
> > generate a timeout with iForcres=1.
>
> I see. So, when you force a COP timeout you don't see the bit
> being set. This is a bit of a mystery. Have you tried dumping
> memory content after programming? Since the laws of physics
> have not been overturned, and we presume that your uC is operating
> properly, there is a limited number of possibilities
>
> (1) You didn't use your toolset properly, or it failed somehow,
> and the image generated is faulty somehow.
>
> (2) You didn't use your file transfer protocol properly, or
> it failed somehow, and the chip is misprogrammed somehow.
>
> (3) The chip is programmed properly, but memory is being corrupted
> while the program is running.
>
> (4) The reset is not being caused by COP.
>
> (5) Something else I haven't thought of.
>
> I'd start checking step-by-step what is going on. I'd also try to
> disentangle things. I'd remove Check_Comms() to make a very simple
> program which forces a COP failure and get that working first. If
> putting Check_Comms() back in causes resets without running the COP
> interrupt code, then I'd try resetting, and dumping memory around the
> actual COP ISR and the vectors.
>
> > Here is the Stop routine:
>
> [STOP mode entered]
>
> >>You are turning on the same indicator bit. (PortG 2)
> >
> > You're right but as you see in my main: I can choose which interrupt I
> > want to generate. Hope you understand better.
>
> Yep.
>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I can explain it for you, but I can't understand it for you.
> I speak only for myself, and I am unanimous in that!
>
Reply by Mike McCarty ●February 20, 20072007-02-20
yuldu25 wrote:
> Hi Mike and Ian,
> For the endless loop, here is a part of my main:

Ok, so this is a test program for experimentation.
I'd cut out Check_Comms() for testing.

> ******************************************************
> iForcres=0; /*This variable is used to generate timeout and illegal
> opcode; it's a EEPROM variable. I could change it's value with serial
> command */
> for(;;)
> {
> COPRST=0x55;
> COPRST=0xaa; /*Reset WD timer*/
> Check_Comms();
> if(iForcres==1) //Generate a timeout for WD
> {
> for(;;)
> {
> }
> }
> if(iForcres==2) //Generate illegal OPCODE (only for test)
> {
> _opc(0x42);
> }
> }
> ******************************************************
> I'm "tickling" the COP, but perhaps as you say: I made some changes
> and the COP timing is perhaps slightly longer. I'm verifying it. Wait
> and see....

How much time can Check_Comms() take? You can figure the worst
case and see whether it exceeds the COP timeout.

>>>If I don't write the interrupt routine for the COP, for the CME...it
>>>resets automatically !
>>
>>I'm afraid I'm having trouble understanding exactly what this
>>means.

[snip]

> If I write and compile the project with or without the previous
> NOCOP_interrupt() it has the same effect: there is a reset when I
> generate a timeout with iForcres=1.

I see. So, when you force a COP timeout you don't see the bit
being set. This is a bit of a mystery. Have you tried dumping
memory content after programming? Since the laws of physics
have not been overturned, and we presume that your uC is operating
properly, there is a limited number of possibilities

(1) You didn't use your toolset properly, or it failed somehow,
and the image generated is faulty somehow.

(2) You didn't use your file transfer protocol properly, or
it failed somehow, and the chip is misprogrammed somehow.

(3) The chip is programmed properly, but memory is being corrupted
while the program is running.

(4) The reset is not being caused by COP.

(5) Something else I haven't thought of.

I'd start checking step-by-step what is going on. I'd also try to
disentangle things. I'd remove Check_Comms() to make a very simple
program which forces a COP failure and get that working first. If
putting Check_Comms() back in causes resets without running the COP
interrupt code, then I'd try resetting, and dumping memory around the
actual COP ISR and the vectors.

> Here is the Stop routine:

[STOP mode entered]

>>You are turning on the same indicator bit. (PortG 2)
>
> You're right but as you see in my main: I can choose which interrupt I
> want to generate. Hope you understand better.

Yep.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by yuldu25 ●February 20, 20072007-02-20
Hi Mike and Ian,
For the endless loop, here is a part of my main:
******************************************************
iForcres=0; /*This variable is used to generate timeout and illegal
opcode; it's a EEPROM variable. I could change it's value with serial
command */
for(;;)
{
COPRST=0x55;
COPRST=0xaa; /*Reset WD timer*/
Check_Comms();
if(iForcres==1) //Generate a timeout for WD
{
for(;;)
{
}
}
if(iForcres==2) //Generate illegal OPCODE (only for test)
{
_opc(0x42);
}
}
******************************************************
I'm "tickling" the COP, but perhaps as you say: I made some changes
and the COP timing is perhaps slightly longer. I'm verifying it. Wait
and see....

>> If I don't write the interrupt routine for the COP, for the CME...it
>> resets automatically !
>I'm afraid I'm having trouble understanding exactly what this
>means.
In my interrupt routine:
interrupt void
NOCOP_interrupt(void) /*watchdog Trap: NOT WORKING*/
{
PORTG|=BIT2;
Stop();
}

If I write and compile the project with or without the previous
NOCOP_interrupt() it has the same effect: there is a reset when I
generate a timeout with iForcres=1.

Here is the Stop routine:
void Stop(void)
{
di(); /* disable interrupt*/
OPTION|=CME; /* clock monitor on */
_opc(0x07); /* TPA : transfer CCR to A, CCR: condition code register
(flag overflow...)*/
_opc(0x84); /* ANDA # */
_opc(0x7f); /* 0x7f STOP is possible*/
_opc(0x01); /* NOP */
_opc(0x06); /* TAP: Transfer ACCU to CCR*/
stop_CPU(); /* STOP instruction*/
}

>You are turning on the same indicator bit. (PortG 2)
You're right but as you see in my main: I can choose which interrupt I
want to generate. Hope you understand better.

Thanks,
Regards,
Julien
Reply by Ian Rumble ●February 19, 20072007-02-19
>>> y...@yahoo.fr 19/02/2007 7:17:12 pm >>>

Hi Julien,
It sounds like the original system COP reset was sufficient to just maintain the COP reset near the end of its timing period. When you made the changes, this put the COP timing longer slightly which accumulates over the period of a week, thus giving the COP reset.
As a trial to see if my diagnosis is correct (maybe doubtful), place a few more COP resets in the code you entered and/or in the old code and see if it fixes the problem.
Unfortunately you will need to wait the week or so for the result.
Regards
Ian

Hi Mike and thanks for your help,
I generate an endless loop in the program (intentionally), when the
COP is disabled there is no reset. But when the COP is enabled there
is a reset.
Effectively I'm trying to trap this COP interrupt thanks to the
vectors table. But it doesnt'work !
I'm sure the reset is due to the COP in this case. But I'm not able to
catch it in a trap. Perhaps it's not possible for this interrupt ?
If I don't write the interrupt routine for the COP, for the CME...it
resets automatically !

Recent Activity
2New Members
Visit Your Group
SPONSORED LINKS
Technical support
Fast track degree
Microprocessor architecture
Microcontrollers
Freescale semiconductor inc
Yahoo! News
Fashion News
What's the word on
fashion and style?
Sitebuilder
Free Download
Build your web
site in minutes.
Y! GeoCities
Share Interests
Connect with
others on the web..

========================================================================The information in this e-mail is intended for the addressee only.
Unauthorised use, copying, disclosure or distribution by anyone else
is prohibited. Please let us know immediately if you receive this
e-mail in error. Thank you.
========================================================================
Reply by Mike McCarty ●February 19, 20072007-02-19
yuldu25 wrote:
> Hi Mike and thanks for your help,
> I generate an endless loop in the program (intentionally), when the

Well, that's normal for most embedded programs. Is this a
special program for testing?

> COP is disabled there is no reset. But when the COP is enabled there
> is a reset.

Ok. If you aren't "tickling" the COP, then you should get one.

> Effectively I'm trying to trap this COP interrupt thanks to the
> vectors table. But it doesnt'work !

Hmm. I see.

> I'm sure the reset is due to the COP in this case. But I'm not able to
> catch it in a trap. Perhaps it's not possible for this interrupt ?

It is possible.

> If I don't write the interrupt routine for the COP, for the CME...it
> resets automatically !

I'm afraid I'm having trouble understanding exactly what this
means.

> As I say I'm using the IAR Compiler and I program in C.

Sorry, I'm not an expert in the IAR Compiler. Maybe there
is a resource for the IAR Compiler where you could get more
help. I'll do what I can.

> ********************************************************
> With IAR I declare the start of the Interrupt Vector FFC0 in a .xcl file.
> ...
> -! The interrupt vectors are assumed to start at 0xFFC0, see also
> cstartup.s07 and int6811.h. -!
> -Z(CODE)INTVECC0-FFFF

If you say so.

[snip]

> /* Illegal Opcode Trap */
> interrupt [INTVEC_START + 0x38] void IOT_interrupt(void);

This looks correct.

> /* COP Failure */
> interrupt [INTVEC_START + 0x3a] void NOCOP_interrupt(void);

So does this.

> /* COP Monitor Failure */
> interrupt [INTVEC_START + 0x3c] void CME_interrupt(void);

This is correct, but the comment is not. The CME is not
COP Monitor Failure, it is Clock Monitor Failure.

> ********************************************************
> In the project: the trap is done like this:
> #include
> interrupt void
> IOT_interrupt(void) /* Illegal Opcode Trap : WORKING*/
> {
> PORTG|=BIT2;
> Stop();
> }

I suppose Stop() is a routine which simply does an
infinite loop.

> interrupt void
> NOCOP_interrupt(void) /*watchdog Trap: NOT WORKING*/
> {
> PORTG|=BIT2;
> Stop();
> }

But, how can you tell? You are turning on the same indicator
bit. Why are you not turning on a different indicator?

> ********************************************************
> Here is a part of my cstartup.s07 module (specific to IAR) in which I
> declare the size of the block:
> *---------------------------*
> * Interrupt vectors must be inserted by the user. Here we only *
> * make room for them and insert the reset vector at 0xFFFE. *
> *---------------------------*
> COMMON INTVEC
> RMB $3E ; Assuming start address = 0xFFC0 for 68HC11

The size of the interrupt vector is independent of where
it may be placed.

> FDB init_C
> ENDMOD init_C ; 'init_C' is program entry address
> ********************************************************
>
> When I try to generate a bad opcode interupt : my OPCODE trap is working.

What I don't understand is how you know your COP trap
code isn't working, when it sets the same bit.

> Hope it helps

Yes, HTH.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by yuldu25 ●February 19, 20072007-02-19
Hi Mike and thanks for your help,
I generate an endless loop in the program (intentionally), when the
COP is disabled there is no reset. But when the COP is enabled there
is a reset.
Effectively I'm trying to trap this COP interrupt thanks to the
vectors table. But it doesnt'work !
I'm sure the reset is due to the COP in this case. But I'm not able to
catch it in a trap. Perhaps it's not possible for this interrupt ?
If I don't write the interrupt routine for the COP, for the CME...it
resets automatically !

As I say I'm using the IAR Compiler and I program in C.
********************************************************
With IAR I declare the start of the Interrupt Vector FFC0 in a .xcl file.
...
-! The interrupt vectors are assumed to start at 0xFFC0, see also
cstartup.s07 and int6811.h. -!
-Z(CODE)INTVECC0-FFFF
...
********************************************************
With IAR the vector's table is defined like this (file: int6811.h)
#ifndef _INT6811_H_
#define _INT6811_H_

#pragma language=extended

#ifndef INTVEC_START
#define INTVEC_START 0 /* Baseoffset from start of */
#endif
...
/* Illegal Opcode Trap */
interrupt [INTVEC_START + 0x38] void IOT_interrupt(void);

/* COP Failure */
interrupt [INTVEC_START + 0x3a] void NOCOP_interrupt(void);

/* COP Monitor Failure */
interrupt [INTVEC_START + 0x3c] void CME_interrupt(void);
********************************************************
In the project: the trap is done like this:
#include
interrupt void
IOT_interrupt(void) /* Illegal Opcode Trap : WORKING*/
{
PORTG|=BIT2;
Stop();
}

interrupt void
NOCOP_interrupt(void) /*watchdog Trap: NOT WORKING*/
{
PORTG|=BIT2;
Stop();
}
********************************************************
Here is a part of my cstartup.s07 module (specific to IAR) in which I
declare the size of the block:
*---------------------------*
* Interrupt vectors must be inserted by the user. Here we only *
* make room for them and insert the reset vector at 0xFFFE. *
*---------------------------*
COMMON INTVEC
RMB $3E ; Assuming start address = 0xFFC0 for 68HC11
FDB init_C
ENDMOD init_C ; 'init_C' is program entry address
********************************************************

When I try to generate a bad opcode interupt : my OPCODE trap is working.

Hope it helps
Julien
--- In m..., Mike McCarty wrote:
>
> yuldu25 wrote:
> > I could disabled the COP and the CME and to wait having a reset but I
> > can't wait one week to see that ! I prefer to make a trap for these
> > interrupt or read a flag after the reset (but which flag ?)
>
> As I pointed out earlier, the vectors can send the COP and CME
> to different locations.
>
> > I have an interrupt function in which I trap for the illegal opcode.
> > When I got this interrupt I write on the G Port to light up a LEd.
> > This routine is working
> > Then I reset.
> >
> > I have another interrupt function in which I trap for the NOCOP
> > interrupt. When I got this interrupt I write on the G port. But it's
> > not working !
> > It resets automatically !
>
> That simply means (I think) that you are not getting a COP reset.
>
> > I have not found how to trap the COP interrupt: my vector's table
> > seems to be good.
>
> Then you aren't getting that interrupt. It could be POR, you know,
> Power On Reset. You may have noise on your power supply, or on
> your RESET line.
>
> Mike
> --
> p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> Oppose globalization and One World Governments like the UN.
> This message made from 100% recycled bits.
> You have found the bank of Larn.
> I can explain it for you, but I can't understand it for you.
> I speak only for myself, and I am unanimous in that!
>
Reply by Mike McCarty ●February 19, 20072007-02-19
yuldu25 wrote:
> I could disabled the COP and the CME and to wait having a reset but I
> can't wait one week to see that ! I prefer to make a trap for these
> interrupt or read a flag after the reset (but which flag ?)

As I pointed out earlier, the vectors can send the COP and CME
to different locations.

> I have an interrupt function in which I trap for the illegal opcode.
> When I got this interrupt I write on the G Port to light up a LEd.
> This routine is working
> Then I reset.
>
> I have another interrupt function in which I trap for the NOCOP
> interrupt. When I got this interrupt I write on the G port. But it's
> not working !
> It resets automatically !

That simply means (I think) that you are not getting a COP reset.

> I have not found how to trap the COP interrupt: my vector's table
> seems to be good.

Then you aren't getting that interrupt. It could be POR, you know,
Power On Reset. You may have noise on your power supply, or on
your RESET line.

Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
Reply by yuldu25 ●February 19, 20072007-02-19
Hi all,
I just made a firmware update on an old project with 68HC11F1.

I have seen there is sometimes a reset (1 a week).

The COP, the CME are enabled.
I use a DS1233 for the reset (supervisor).

I don't know if the reset is due to the COP or to the CME or to the
supervisor.

I could disabled the COP and the CME and to wait having a reset but I
can't wait one week to see that ! I prefer to make a trap for these
interrupt or read a flag after the reset (but which flag ?)

I have an interrupt function in which I trap for the illegal opcode.
When I got this interrupt I write on the G Port to light up a LEd.
This routine is working
Then I reset.

I have another interrupt function in which I trap for the NOCOP
interrupt. When I got this interrupt I write on the G port. But it's
not working !
It resets automatically !

I have not found how to trap the COP interrupt: my vector's table
seems to be good.

I'm using IAR and the soft is in C.

Regards,
Julien