Debug & Programming

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Debug & Programming

Andrew Lohmann
Hi,


I have been pursuing the same or similar problems for a number of years
with programming HCS12Dx.

We have a few parallel Multilink P&E BDM interfaces and a USB Multilink.
We also have a Compod12. The Compod12 programs any HCS12 reliably but
the Multilink only programs HCS12E reliably and HCS12D's for a limited
period of time. After that the only the Compod12 will program HCS12D's
that can not be programmed with the Multilink. I find the USB Multilink
more reliable, and I use it with Cosmic Zap. The problem is that Zap
reports target speed can not be found, but P&E Unsecure connects fine
and of cause reports that the device is already unsecured.

Cosmic did suggest that I check the RAM base address setting in Zap but
it is fine.


I would appreciate your suggestions?
--
Andrew Lohmann AMIIE
Design Engineer

Bellingham + Stanley Ltd.
Longfield Road
Tunbridge Wells Kent,
TN2 3EY
United Kingdom

General Contact Details:
Phone: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115

General E-Mail: [hidden email]
Web: www.bellinghamandstanley.com

Personal Contact Details: Direct Dial: +44 (0) 1892 500426


-----------------------------Disclaimer-----------------------------

This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail.

Bellingham + Stanley Ltd., Longfield Road, Tunbridge Wells, Kent, TN2 3EY. U.K. Registered No. 140250 England. Registered Office.

This message has been scanned for viruses by Viatel MailControl, a service from Viatel.

-----------------------------Disclaimer-----------------------------
Reply | Threaded
Open this post in threaded view
|

Re: Debug & Programming

Edward Karpicz
Andrew,

I don't know much about Compod12, but I'm sure Multilink doesn't program
parts. Multilink is just an interface between PC and your target and I
believe that it doesn't know how to program all the variety of HC12s, S12s
and S08s. Debugger (ZAP in your case) must be what measures your oscilator
frequency and sets correctly the most important thing - FCLKDIV register. I
don't know how this scan for osc. freq. is really done and if it's reliable
or not. But bad things can happen to your chip if this scan for frequency is
not reliable. The question is what, Multilink or ZAP detects your board
frequency. Is it possible to disable scan for frequency and specify it in
ZAP? Maybe try NoICE +Multilink + S12D that doesn't work in ZAP?

No wonder Unsecure12 always works. Unsecure12 asks and doesn't guess
oscilator frequency.

Edward


Andrew Lohmann wrote:

> Hi,
>
>
> I have been pursuing the same or similar problems for a number of years
> with programming HCS12Dx.
>
> We have a few parallel Multilink P&E BDM interfaces and a USB Multilink.
> We also have a Compod12. The Compod12 programs any HCS12 reliably but
> the Multilink only programs HCS12E reliably and HCS12D's for a limited
> period of time. After that the only the Compod12 will program HCS12D's
> that can not be programmed with the Multilink. I find the USB Multilink
> more reliable, and I use it with Cosmic Zap. The problem is that Zap
> reports target speed can not be found, but P&E Unsecure connects fine
> and of cause reports that the device is already unsecured.
>
> Cosmic did suggest that I check the RAM base address setting in Zap but
> it is fine.
>
>
> I would appreciate your suggestions?
> --
> Andrew Lohmann AMIIE
> Design Engineer
>
> Bellingham + Stanley Ltd.
> Longfield Road
> Tunbridge Wells Kent,
> TN2 3EY
> United Kingdom
>
> General Contact Details:
> Phone: +44 (0) 1892 500400
> Fax: +44 (0) 1892 543115
>
> General E-Mail: [hidden email]
> Web: www.bellinghamandstanley.com
>
> Personal Contact Details: Direct Dial: +44 (0) 1892 500426
>
>
> -----------------------------Disclaimer-----------------------------
>
> This communication contains information which is confidential and may also
> be privileged. It is for the exclusive use of the addressee. If you are
> not the addressee please note that any distribution, reproduction,
> copying, publication or use of this communication or the information is
> prohibited. If you have received this communication in error, please
> contact us immediately and also delete the communication from your
> computer. We accept no liability for any loss or damage suffered by any
> person arising from use of this e-mail.
>
> Bellingham + Stanley Ltd., Longfield Road, Tunbridge Wells, Kent, TN2 3EY.
> U.K. Registered No. 140250 England. Registered Office.
>
> This message has been scanned for viruses by Viatel MailControl, a service
> from Viatel.
>
> -----------------------------Disclaimer-----------------------------
>
>
>
> Yahoo! Groups Links
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Debug & Programming

Andrew Lohmann
Thanks Edward,


I can fix the two clock frequency's, and that is how I run Zap.
Strangely also using ComPod12 on a HCS12D target also makes it unusable
by Zap although P&E's unsecure is fine.
Maybe I should try NoICE.


Andrew Lohmann AMIIE
Design Engineer

Bellingham + Stanley Ltd.


Edward Karpicz wrote:

>
> Andrew,
>
> I don't know much about Compod12, but I'm sure Multilink doesn't program
> parts. Multilink is just an interface between PC and your target and I
> believe that it doesn't know how to program all the variety of HC12s,
> S12s
> and S08s. Debugger (ZAP in your case) must be what measures your
> oscilator
> frequency and sets correctly the most important thing - FCLKDIV
> register. I
> don't know how this scan for osc. freq. is really done and if it's
> reliable
> or not. But bad things can happen to your chip if this scan for
> frequency is
> not reliable. The question is what, Multilink or ZAP detects your board
> frequency. Is it possible to disable scan for frequency and specify it in
> ZAP? Maybe try NoICE +Multilink + S12D that doesn't work in ZAP?
>
> No wonder Unsecure12 always works. Unsecure12 asks and doesn't guess
> oscilator frequency.
>
> Edward
>
> Andrew Lohmann wrote:
>
> > Hi,
> >
> >
> > I have been pursuing the same or similar problems for a number of years
> > with programming HCS12Dx.
> >
> > We have a few parallel Multilink P&E BDM interfaces and a USB Multilink.
> > We also have a Compod12. The Compod12 programs any HCS12 reliably but
> > the Multilink only programs HCS12E reliably and HCS12D's for a limited
> > period of time. After that the only the Compod12 will program HCS12D's
> > that can not be programmed with the Multilink. I find the USB Multilink
> > more reliable, and I use it with Cosmic Zap. The problem is that Zap
> > reports target speed can not be found, but P&E Unsecure connects fine
> > and of cause reports that the device is already unsecured.
> >
> > Cosmic did suggest that I check the RAM base address setting in Zap but
> > it is fine.
> >
> >
> > I would appreciate your suggestions?
> > --
> > Andrew Lohmann AMIIE
> > Design Engineer
> >
> > Bellingham + Stanley Ltd.
> > Longfield Road
> > Tunbridge Wells Kent,
> > TN2 3EY
> > United Kingdom
> >
> > General Contact Details:
> > Phone: +44 (0) 1892 500400
> > Fax: +44 (0) 1892 543115
> >
> > General E-Mail: [hidden email]
> <mailto:sales%40bellinghamandstanley.co.uk>
> > Web: www.bellinghamandstanley.com
> >
> > Personal Contact Details: Direct Dial: +44 (0) 1892 500426
> >
> >
> > -----------------------------Disclaimer-----------------------------
> >
> > This communication contains information which is confidential and
> may also
> > be privileged. It is for the exclusive use of the addressee. If you are
> > not the addressee please note that any distribution, reproduction,
> > copying, publication or use of this communication or the information is
> > prohibited. If you have received this communication in error, please
> > contact us immediately and also delete the communication from your
> > computer. We accept no liability for any loss or damage suffered by any
> > person arising from use of this e-mail.
> >
> > Bellingham + Stanley Ltd., Longfield Road, Tunbridge Wells, Kent,
> TN2 3EY.
> > U.K. Registered No. 140250 England. Registered Office.
> >
> > This message has been scanned for viruses by Viatel MailControl, a
> service
> > from Viatel.
> >
> > -----------------------------Disclaimer-----------------------------
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
>
>  
Reply | Threaded
Open this post in threaded view
|

XGate programming and XDP512 memory scheme

jpdi
In reply to this post by Edward Karpicz
Hello !

Until now, I was using mc9s12dp256 with ICC12 V6 professionnal, paged
programm, and all was ok.

Now, using mc9s12xdp512cal, with ICC12 professionnal V6, I need to use XGate
processor (communication SCI between 2 MCU). Without XGate, the main S12 CPU
would be overload !

I read the Freescale datasheets, specially the chapters about :
- XGate,
- Memory Mapping Control
- Interrupt
- and some Application Notes about XGate

It seems to be difficult to know how to program that XGate processor. I
looked for some samples without any success !
The samples I can analyse (Cosmic and CodeWarrior) give a little bit of
informations (just one sample program), but are not very clear at all,
specially memory access, memory mapping...

If I understood, for XGate point of view :
- 2K registers are under address 0x0000..0x07ff
- 30k flash for XGate from xgate address 0x0800..0x7fff
- 32K RAM of the XDP512 are under address 0x8000..0xffff,

I understand all the RAM available on XDP512 can be access with XGate, and
the pagination system (RPAGE) to access RAM under S12 CPU.

I don't completely understand the memory scheme of XDP512.
I know there are 512K flash, but I don't see anything about the different
pages. DP256 had internal pages from 0x30..0x3f, with window 0x8000..0xc000,
but XDP512 ? It seems to be pages 0xe0..0xfd, same window ? Correct ?

Any help ?
All samples about XGate wil be welcome !

With all my thanks
Best regards

Joel Petrique



Reply | Threaded
Open this post in threaded view
|

Re: XGate programming and XDP512 memory scheme

Edward Karpicz
Hi Joel,


> Hello !
>
> Until now, I was using mc9s12dp256 with ICC12 V6 professionnal, paged
> programm, and all was ok.
>
> Now, using mc9s12xdp512cal, with ICC12 professionnal V6, I need to use
> XGate
> processor (communication SCI between 2 MCU). Without XGate, the main S12
> CPU
> would be overload !
>
> I read the Freescale datasheets, specially the chapters about :
> - XGate,
> - Memory Mapping Control
> - Interrupt
> - and some Application Notes about XGate
>
> It seems to be difficult to know how to program that XGate processor. I
> looked for some samples without any success !

Are you trying to code XGATE in C with ICC12? Unfortunately ICC12 doesn't
support XGATE at C level. ICC12 V7 does have some support for XGATE asm, but
not C :-(.


> The samples I can analyse (Cosmic and CodeWarrior) give a little bit of
> informations (just one sample program), but are not very clear at all,
> specially memory access, memory mapping...

S12X with XGATE is quite a difficult thing, a lot of reading until you see
the whole picture.. You write S12X and XGATE interrupt handlers, make S12X
interrupt vector table, XGATE vector table, setup XGATE, interrupt
controller and interrupt routing.

>
> If I understood, for XGate point of view :
> - 2K registers are under address 0x0000..0x07ff
> - 30k flash for XGate from xgate address 0x0800..0x7fff
> - 32K RAM of the XDP512 are under address 0x8000..0xffff,

^^ That's right. XGATE has 16bits address space and XGATE sees registers,
ram and flash at addresses you wrote above. What S12X sees as RAM @ $3FFF,
XGATE sees as RAM @ $FFFF. What XGATE sees as flash @ $7FFF, S12X sees @
PPAGE $E1, $BFFF :-).


>
> I understand all the RAM available on XDP512 can be access with XGate, and
> the pagination system (RPAGE) to access RAM under S12 CPU.

That's right. Also there's a new global addressing mode. S12X is able to see
all the onchip 32k RAM in GPAGE = $F, offset $8000-$FFFF.

>
> I don't completely understand the memory scheme of XDP512.
> I know there are 512K flash, but I don't see anything about the different
> pages. DP256 had internal pages from 0x30..0x3f, with window
> 0x8000..0xc000,
> but XDP512 ? It seems to be pages 0xe0..0xfd, same window ? Correct ?

Correct. PPAGEs $E0-$FF, page window $8000-$BFFF. Note one more small
difference between S12 and S12X. Fixed page 4000-7fff was mapped to
PPAGE=the_top_most_ppage-1=$3E on S12. Now 4000-7fff is mapped to
PPAGE=the_top_most_ppage-2=$FD on S12X.

>
> Any help ?
> All samples about XGate wil be welcome !

Do you wish XGATE assembler examples? ICC12 doesn't have C compiler for
XGATE, unfortunately.


Best Regards
Edward

>
> With all my thanks
> Best regards
>
> Joel Petrique
>
>


Reply | Threaded
Open this post in threaded view
|

RE: XGate programming and XDP512 memory scheme

jpdi
Hi, Edward !

Thank you for your answer.
I know ICC12 V6 doesn't suppor XGate asm.
I tried with demo version of V7, but without any documentation...

I'd like to have some XGATE assembler examples (under ICC12 would be better)
! If you have it, it would be great !

I tried Cosmic compiler, which support XGATE C compiler, and CodeWarrior,
but both are very very expensive for me !
With these tools, I begin to understand XGate, but some details missed me,
and seems to be important if I don't use "heavy" compilers ! Your answer
lights me now.

I think interrupt thread I've to write aren't so long... Simply
receive/transmit on one SCI chanel...

By the way, it seems there are mistake with ICC12 V7 under target "XDP512" :
OK Program memory 0x4000.0x7FFF:0xC000.0xFFFF
Bad ? Data memory 0x0800 (I suppose 0x1000, it's OK with
that)
OK stack 0x4000

A question about Expanded Memory : 0xf0000.0xfffff ?
Are this datas correct for ICC12 V7 ?I don't understand this parameter, and
help files don't explain that..

Thank you,
And all the best for you for the new year !
Best regards

Joel


> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]] De la part de
> Edward Karpicz
> Envoyé : mercredi 26 décembre 2007 21:38
> À : [hidden email]
> Objet : Re: [68HC12] XGate programming and XDP512 memory scheme
>
> Hi Joel,
>
>
> > Hello !
> >
> > Until now, I was using mc9s12dp256 with ICC12 V6 professionnal, paged
> > programm, and all was ok.
> >
> > Now, using mc9s12xdp512cal, with ICC12 professionnal V6, I need to use
> > XGate
> > processor (communication SCI between 2 MCU). Without XGate, the main S12
> > CPU
> > would be overload !
> >
> > I read the Freescale datasheets, specially the chapters about :
> > - XGate,
> > - Memory Mapping Control
> > - Interrupt
> > - and some Application Notes about XGate
> >
> > It seems to be difficult to know how to program that XGate processor. I
> > looked for some samples without any success !
>
> Are you trying to code XGATE in C with ICC12? Unfortunately ICC12 doesn't
> support XGATE at C level. ICC12 V7 does have some support for XGATE asm,
> but
> not C :-(.
>
>
> > The samples I can analyse (Cosmic and CodeWarrior) give a little bit of
> > informations (just one sample program), but are not very clear at all,
> > specially memory access, memory mapping...
>
> S12X with XGATE is quite a difficult thing, a lot of reading until you see
> the whole picture.. You write S12X and XGATE interrupt handlers, make S12X
> interrupt vector table, XGATE vector table, setup XGATE, interrupt
> controller and interrupt routing.
>
> >
> > If I understood, for XGate point of view :
> > - 2K registers are under address 0x0000..0x07ff
> > - 30k flash for XGate from xgate address 0x0800..0x7fff
> > - 32K RAM of the XDP512 are under address 0x8000..0xffff,
>
> ^^ That's right. XGATE has 16bits address space and XGATE sees registers,
> ram and flash at addresses you wrote above. What S12X sees as RAM @ $3FFF,
> XGATE sees as RAM @ $FFFF. What XGATE sees as flash @ $7FFF, S12X sees @
> PPAGE $E1, $BFFF :-).
>
>
> >
> > I understand all the RAM available on XDP512 can be access with XGate,
> and
> > the pagination system (RPAGE) to access RAM under S12 CPU.
>
> That's right. Also there's a new global addressing mode. S12X is able to
> see
> all the onchip 32k RAM in GPAGE = $F, offset $8000-$FFFF.
>
> >
> > I don't completely understand the memory scheme of XDP512.
> > I know there are 512K flash, but I don't see anything about the
> different
> > pages. DP256 had internal pages from 0x30..0x3f, with window
> > 0x8000..0xc000,
> > but XDP512 ? It seems to be pages 0xe0..0xfd, same window ? Correct ?
>
> Correct. PPAGEs $E0-$FF, page window $8000-$BFFF. Note one more small
> difference between S12 and S12X. Fixed page 4000-7fff was mapped to
> PPAGE=the_top_most_ppage-1=$3E on S12. Now 4000-7fff is mapped to
> PPAGE=the_top_most_ppage-2=$FD on S12X.
>
> >
> > Any help ?
> > All samples about XGate wil be welcome !
>
> Do you wish XGATE assembler examples? ICC12 doesn't have C compiler for
> XGATE, unfortunately.
>
>
> Best Regards
> Edward
>
> >
> > With all my thanks
> > Best regards
> >
> > Joel Petrique
> >
> >
>
>
>
>
>
> Yahoo! Groups Links
>
>
>



Reply | Threaded
Open this post in threaded view
|

XGate thread using SCI running under simulator, not on the target

jpdi
In reply to this post by Edward Karpicz
Hello,

 

I'm trying to do some thread for XGate.

The first thread I wrote, using RTI, is now OK, so I can see it running
under simulator AND on my target processor.

 

The second, using SCI1,

- runs under simulator : I can see interrupt, immediately when I put a
character in SCI1DRL then generate xmit interrupt, and XGate thread executed

- but not on the target : thread never executed

 

Before trying with XGate, I used S12 interrupts, and my soft was OK.

Now, because of these difficulties to startup XGate, I dramatically simplify
the program :

 

Into main function :

void main (void)

{    unsigned char c;

     // some initialisations, used in an other program

     

     c = 'A';

     for (;;)

     {    SCI1DRL = c;              // send char

          SCI1CR2 |= 0x88;               // enable SCI xmit and interrupts

          c++;

     }

}

 

Now, the thread SCI1, with the pointer to the original datas (not use now)

interrupt void XGATE_SCI1_thread (TSci1Datas *ptr)

{    unsigned char status, tempo;

 

     status = SCI1SR1;              // read SCI1 status

     tempo = SCI1BDL;                     // dummy read (usefull ?)

     

     if (status & 0x80)             // if xmit buffer empty

     {    SCI1CR2 &= 0x3f;               // inhibe xmit interrupts

     }

}

 

Anybody can help me ?

Thanks !

 

Best regards.

Joel



[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: XGate thread using SCI running under simulator, not on the target

Edward Karpicz
Joel,

I don't know why code working in simulator doesn't work in target, but you
oversimplified your minimal program. XGATE setup is missing, interrupt
controller setup is missing, XGATE interrupt vector table is missing.

BTW XGATE V2 threads are uninterruptable. No new XGATE thread can be started
until XGATE becomes idle. Make sure you exit from your other threads and
clear corresponding interrupt flags or interrupt masks. For example if you
have just RTI thread, then verify that it doesn't loop forever, else your
SCI thread won't ever start.

Edward

----- Original Message -----
From: "jpdi" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, March 04, 2008 9:39 PM
Subject: [68HC12] XGate thread using SCI running under simulator, not on the
target


> Hello,
>
>
>
> I'm trying to do some thread for XGate.
>
> The first thread I wrote, using RTI, is now OK, so I can see it running
> under simulator AND on my target processor.
>
>
>
> The second, using SCI1,
>
> - runs under simulator : I can see interrupt, immediately when I put a
> character in SCI1DRL then generate xmit interrupt, and XGate thread
> executed
>
> - but not on the target : thread never executed
>
>
>
> Before trying with XGate, I used S12 interrupts, and my soft was OK.
>
> Now, because of these difficulties to startup XGate, I dramatically
> simplify
> the program :
>
>
>
> Into main function :
>
> void main (void)
>
> {    unsigned char c;
>
>     // some initialisations, used in an other program
>
>
>
>     c = 'A';
>
>     for (;;)
>
>     {    SCI1DRL = c;              // send char
>
>          SCI1CR2 |= 0x88;               // enable SCI xmit and interrupts
>
>          c++;
>
>     }
>
> }
>
>
>
> Now, the thread SCI1, with the pointer to the original datas (not use now)
>
> interrupt void XGATE_SCI1_thread (TSci1Datas *ptr)
>
> {    unsigned char status, tempo;
>
>
>
>     status = SCI1SR1;              // read SCI1 status
>
>     tempo = SCI1BDL;                     // dummy read (usefull ?)
>
>
>
>     if (status & 0x80)             // if xmit buffer empty
>
>     {    SCI1CR2 &= 0x3f;               // inhibe xmit interrupts
>
>     }
>
> }
>
>
>
> Anybody can help me ?
>
> Thanks !
>
>
>
> Best regards.
>
> Joel
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: XGate thread using SCI running under simulator, not on the target

jpdi
Sure, Edward, I oversimplified !!! In order to avoid too big mail on the
mailing list.

 

For the moment, under CodeWarrior, after running successful XGate with RTI,
I cancelled RTI thread, replacing it with SCI thread... So, I think
SetupXGATE is ok ?

Below the code I use, less simplified !

For the moment, I don’t understand why program run under CodeWarrior’s
Simulator and not on the target…

I analysed macro ROUTE_INTERRUPT…

 

With all my thanks.

 

Joel

 

 

//*******************************************************************

// Define size of xmit and receive buffers

#define SCI1_TAILLE_BUFFER_EMISSION       256

#define SCI1_TAILLE_BUFFER_RECEPTION      256

 

typedef struct TSci1_Emission             // offset for access to the
structure’s member

{    Byte *wr, *rd;                      // 0, 2   write and read pointers

     Word dispo;                         // 4      nbre of bytes available
in the buffer

}    TSci1_Emission;

 

 

typedef struct TSci1_Reception

{    Byte *wr, *rd;                      // 6, 8   write and read pointers

     Word nb_octets;                     // 10      nbre of bytes received
in the buffer

     Byte ovf;                           // 12     overflow

     Byte pour_parite;                   // 13      for parity of the
structure's size

}    TSci1_Reception;

 

 

typedef struct TSci1Datas      // structure organized to facilitate later
assembly

{    TSci1_Emission       emission;

     TSci1_Reception      reception;

     Byte                xmit_buffer[SCI1_TAILLE_BUFFER_EMISSION];

     Byte                rec_buffer[SCI1_TAILLE_BUFFER_RECEPTION];

}    TSci1Datas;

 

 

//*******************************************************************

// In “main” file

#define ROUTE_INTERRUPT(vec_adr,cfdata)                  \

     INT_CFADDR = (vec_adr) & 0xF0;                      \

     INT_CFDATA_ARR[((vec_adr) & 0x0F) >> 1]= (cfdata)

 

 

#define S12_SCI1_VECTOR   0xD4                // S12 vector for SCI1 :
0xffd4

 

void main(void)

{    int perdu, cptr;

     char s[40];

     

     SCI1_Init (38400, 6);

     DDRA = 0xff;                              // port A en sortie

     PORTA = 0x80;                             // valide sortie RS-485

     SetupXGATE();

     cptr = 0;

     for (;;)

     {    cptr++;

          perdu = sprintf (s, "%6d", cptr);

          SCI1_puts (s);

          // Some delay of about 1 sec, using simply loop

     }

}

 

void SetupXGATE (void)

{    // Init XGATE vector block and set the XGVBR register to start address

     XGVBR= (unsigned int)(void*__far)(XGATE_VectorTable -
XGATE_VECTOR_OFFSET);

 

// Détourne interruptions pour XGATE

     ROUTE_INTERRUPT (S12_SCI1_VECTOR, 0x81);

     

// Valide XGATE mode et interruptions

XGMCTL= 0x8181;

}

 

void SCI1_Init (Word baud, Byte sysclk)

{    // …/…                               // calculation for Baudrate

     // Some inits

     SCI1CR1 = 0x00;

     SCI1SR2 = 0x80;                      // alternative register set

     SCI1ASR1 = 0x83;                     // clear alternative status

     SCI1ACR1 = 0x00;                     // disable interrupts on active
edge, bit error, break

     SCI1ACR2 = 0x00;                     //

     SCI1SR2 = 0x00;                      // normal register set

     (void) SCI1SR1;                      // reset interrupt request flags

 

     SCI1CR2 = 0x00;

     SCI1BDH = diviseur.c[0];             // baudrate

     SCI1BDL = diviseur.c[1];

 

     SCI1CR2 = 0x2c;                      // TE | RE | RIE ==> enable
xmit/receive, interrupt on receive only

}

 

 

//*******************************************************************

// In “XGate” file

// SCI1 management with XGate

interrupt void XGATE_SCI1_thread (TSci1Datas *ptr)

{    Byte status;

status = SCI1SR1;                                   // read status...

     if (status & 0x0f)                                  // errors ?

     {    // …/…    

     }

     

// Interrupt on xmit empty

if (status & 0x80)                                  // TDRE : 0x80 ;
Transmit Data Register Empty

{    if (ptr->emission.rd != ptr->emission.wr)

{    SCI1DRL = *ptr->emission.rd;             // send current char

ptr->emission.rd++;                       // prepare next char

if (ptr->emission.rd >= &ptr->xmit_buffer[SCI1_TAILLE_BUFFER_EMISSION])

     ptr->emission.rd = &ptr->xmit_buffer[0];

          }

          else                                           // nothing to xmit

          {    SCI1CR2 &= 0x3f;                         // stop interrupt

          }

   }

 

     // Interrupt on receive full

     if (status & 0x20)                                  // RDRF 0x20 :
Receive data register full

     {    // …/…

     }

}

 

interrupt void XGATE_ErrorHandler_thread (int dataptr)

{    dataptr++;                // in order to avoid warning by compiler

     asm BRK;

}

 

// A part of Threads Table, only SCI1 thread is set

#pragma CONST_SEG XGATE_VECTORS

const XGATE_TableEntry XGATE_VectorTable[] = {

     // Channel # = Vector address / 2

     // channel 0..8 are not used, first used must match macro
XGATE_VECTOR_OFFSET in xgate.h

     {XGATE_ErrorHandler_thread, 0x09},                  // Channel 09 -
Reserved

     // …/…

     {XGATE_ErrorHandler_thread, 0x69},                  // Channel 69 -
ATD0                            

 

     //{XGATE_ErrorHandler_thread, 0x6A},                // Channel 6A -
SCI1                            

     {(XGATE_PtrFunction) XGATE_SCI1_thread, (int)&_sci1_datas},  // Channel
6A - SCI1

     {XGATE_ErrorHandler_thread, 0x6B},                  // Channel 6B -
SCI0                            

 

     // …/…  

     {XGATE_ErrorHandler_thread, 0x78},                  // Channel 78 -
Real Time Interrupt

     {XGATE_ErrorHandler_thread, 0x79},                  // Channel 79 - IRQ

};

 

 

 

> -----Message d'origine-----

> De : [hidden email] [mailto:[hidden email]] De la part de

> Edward Karpicz

> Envoyé : mercredi 5 mars 2008 07:52

> À : [hidden email]

> Objet : Re: [68HC12] XGate thread using SCI running under simulator, not

> on the target

>

> Joel,

>

> I don't know why code working in simulator doesn't work in target, but you

> oversimplified your minimal program. XGATE setup is missing, interrupt

> controller setup is missing, XGATE interrupt vector table is missing.

>

> BTW XGATE V2 threads are uninterruptable. No new XGATE thread can be

> started

> until XGATE becomes idle. Make sure you exit from your other threads and

> clear corresponding interrupt flags or interrupt masks. For example if you

> have just RTI thread, then verify that it doesn't loop forever, else your

> SCI thread won't ever start.

>

> Edward

>

 



[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: XGate thread using SCI running under simulator, not on the target

Edward Karpicz
Joel,

Maybe it's another simplification, but in your SCI init routine you are
enabling RIE interrupt and in your SCI handler I see only transmitters code.
RDRF flag isn't handled, it's read but isn't cleared by reading SCI1DRL.
Anyway I just tried it as is, except that I enabled TDRE interrupt. XGATE
SCI1 ISR got triggered. So problem must be somewhere else.

Also

1) You init SCI1 first and enable RIE interrupt, then you route interrupts
to XGATE. SCI char shouldn't arrive in the time between when you enable RIE
and when you route SCI1 interrupts to XGATE. But I wonder what would happen
if RIE would get pending at this time? I'm not sure if it is OK to switch
routing of specific interrupt while it is pending and unmasked. I'd better
swap in main() SetupXGATE() and SCI1Init(), so that routing is done before
interrupt is enabled.

2) XGMCTL= 0x8181; //You enable XGATE interrupt here (XGIE). It sounds
confusing, but it's a S12X interrupt :-). Imagine for a moment that XGATE
can't run any code and it's something simple like key wakeup pin peripheral
module. It has its own interrupt XGIE and you handle this interrupt using
S12X.
In fact XGATE has a lot of XGIF flags. There's a special XGATE instruction
SIF, that is used to set XGIF flags. XGATE code executes SIF (set interrupt
flags), XGIF flag gets set and XGIE interrupt becoms pending. So do you have
S12X handler for this interrupt? If not then you shouldn't set XGIE, I
guess.


Regards,

Edward

----- Original Message -----
From: "jpdi" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, March 05, 2008 3:36 PM
Subject: RE: [68HC12] XGate thread using SCI running under simulator, not on
the target


> Sure, Edward, I oversimplified !!! In order to avoid too big mail on the
> mailing list.
>
>
>
> For the moment, under CodeWarrior, after running successful XGate with
> RTI,
> I cancelled RTI thread, replacing it with SCI thread... So, I think
> SetupXGATE is ok ?
>
> Below the code I use, less simplified !
>
> For the moment, I don't understand why program run under CodeWarrior's
> Simulator and not on the target.
>
> I analysed macro ROUTE_INTERRUPT.
>
>
>
> With all my thanks.
>
>
>
> Joel
>
>
>
>
>
> //*******************************************************************
>
> // Define size of xmit and receive buffers
>
> #define SCI1_TAILLE_BUFFER_EMISSION       256
>
> #define SCI1_TAILLE_BUFFER_RECEPTION      256
>
>
>
> typedef struct TSci1_Emission             // offset for access to the
> structure's member
>
> {    Byte *wr, *rd;                      // 0, 2   write and read pointers
>
>     Word dispo;                         // 4      nbre of bytes available
> in the buffer
>
> }    TSci1_Emission;
>
>
>
>
>
> typedef struct TSci1_Reception
>
> {    Byte *wr, *rd;                      // 6, 8   write and read pointers
>
>     Word nb_octets;                     // 10      nbre of bytes received
> in the buffer
>
>     Byte ovf;                           // 12     overflow
>
>     Byte pour_parite;                   // 13      for parity of the
> structure's size
>
> }    TSci1_Reception;
>
>
>
>
>
> typedef struct TSci1Datas      // structure organized to facilitate later
> assembly
>
> {    TSci1_Emission       emission;
>
>     TSci1_Reception      reception;
>
>     Byte                xmit_buffer[SCI1_TAILLE_BUFFER_EMISSION];
>
>     Byte                rec_buffer[SCI1_TAILLE_BUFFER_RECEPTION];
>
> }    TSci1Datas;
>
>
>
>
>
> //*******************************************************************
>
> // In "main" file
>
> #define ROUTE_INTERRUPT(vec_adr,cfdata)                  \
>
>     INT_CFADDR = (vec_adr) & 0xF0;                      \
>
>     INT_CFDATA_ARR[((vec_adr) & 0x0F) >> 1]= (cfdata)
>
>
>
>
>
> #define S12_SCI1_VECTOR   0xD4                // S12 vector for SCI1 :
> 0xffd4
>
>
>
> void main(void)
>
> {    int perdu, cptr;
>
>     char s[40];
>
>
>
>     SCI1_Init (38400, 6);
>
>     DDRA = 0xff;                              // port A en sortie
>
>     PORTA = 0x80;                             // valide sortie RS-485
>
>     SetupXGATE();
>
>     cptr = 0;
>
>     for (;;)
>
>     {    cptr++;
>
>          perdu = sprintf (s, "%6d", cptr);
>
>          SCI1_puts (s);
>
>          // Some delay of about 1 sec, using simply loop
>
>     }
>
> }
>
>
>
> void SetupXGATE (void)
>
> {    // Init XGATE vector block and set the XGVBR register to start
> address
>
>     XGVBR= (unsigned int)(void*__far)(XGATE_VectorTable -
> XGATE_VECTOR_OFFSET);
>
>
>
> // Détourne interruptions pour XGATE
>
>     ROUTE_INTERRUPT (S12_SCI1_VECTOR, 0x81);
>
>
>
> // Valide XGATE mode et interruptions
>
> XGMCTL= 0x8181;
>
> }
>
>
>
> void SCI1_Init (Word baud, Byte sysclk)
>
> {    // ./.                               // calculation for Baudrate
>
>     // Some inits
>
>     SCI1CR1 = 0x00;
>
>     SCI1SR2 = 0x80;                      // alternative register set
>
>     SCI1ASR1 = 0x83;                     // clear alternative status
>
>     SCI1ACR1 = 0x00;                     // disable interrupts on active
> edge, bit error, break
>
>     SCI1ACR2 = 0x00;                     //
>
>     SCI1SR2 = 0x00;                      // normal register set
>
>     (void) SCI1SR1;                      // reset interrupt request flags
>
>
>
>     SCI1CR2 = 0x00;
>
>     SCI1BDH = diviseur.c[0];             // baudrate
>
>     SCI1BDL = diviseur.c[1];
>
>
>
>     SCI1CR2 = 0x2c;                      // TE | RE | RIE ==> enable
> xmit/receive, interrupt on receive only
>
> }
>
>
>
>
>
> //*******************************************************************
>
> // In "XGate" file
>
> // SCI1 management with XGate
>
> interrupt void XGATE_SCI1_thread (TSci1Datas *ptr)
>
> {    Byte status;
>
> status = SCI1SR1;                                   // read status...
>
>     if (status & 0x0f)                                  // errors ?
>
>     {    // ./.
>
>     }
>
>
>
> // Interrupt on xmit empty
>
> if (status & 0x80)                                  // TDRE : 0x80 ;
> Transmit Data Register Empty
>
> {    if (ptr->emission.rd != ptr->emission.wr)
>
> {    SCI1DRL = *ptr->emission.rd;             // send current char
>
> ptr->emission.rd++;                       // prepare next char
>
> if (ptr->emission.rd >= &ptr->xmit_buffer[SCI1_TAILLE_BUFFER_EMISSION])
>
>     ptr->emission.rd = &ptr->xmit_buffer[0];
>
>          }
>
>          else                                           // nothing to xmit
>
>          {    SCI1CR2 &= 0x3f;                         // stop interrupt
>
>          }
>
>   }
>
>
>
>     // Interrupt on receive full
>
>     if (status & 0x20)                                  // RDRF 0x20 :
> Receive data register full
>
>     {    // ./.
>
>     }
>
> }
>
>
>
> interrupt void XGATE_ErrorHandler_thread (int dataptr)
>
> {    dataptr++;                // in order to avoid warning by compiler
>
>     asm BRK;
>
> }
>
>
>
> // A part of Threads Table, only SCI1 thread is set
>
> #pragma CONST_SEG XGATE_VECTORS
>
> const XGATE_TableEntry XGATE_VectorTable[] = {
>
>     // Channel # = Vector address / 2
>
>     // channel 0..8 are not used, first used must match macro
> XGATE_VECTOR_OFFSET in xgate.h
>
>     {XGATE_ErrorHandler_thread, 0x09},                  // Channel 09 -
> Reserved
>
>     // ./.
>
>     {XGATE_ErrorHandler_thread, 0x69},                  // Channel 69 -
> ATD0
>
>
>
>     //{XGATE_ErrorHandler_thread, 0x6A},                // Channel 6A -
> SCI1
>
>     {(XGATE_PtrFunction) XGATE_SCI1_thread, (int)&_sci1_datas},  //
> Channel
> 6A - SCI1
>
>     {XGATE_ErrorHandler_thread, 0x6B},                  // Channel 6B -
> SCI0
>
>
>
>     // ./.
>
>     {XGATE_ErrorHandler_thread, 0x78},                  // Channel 78 -
> Real Time Interrupt
>
>     {XGATE_ErrorHandler_thread, 0x79},                  // Channel 79 -
> IRQ
>
> };
>
>
>
>
>
>
>
>> -----Message d'origine-----
>
>> De : [hidden email] [mailto:[hidden email]] De la part de
>
>> Edward Karpicz
>
>> Envoyé : mercredi 5 mars 2008 07:52
>
>> À : [hidden email]
>
>> Objet : Re: [68HC12] XGate thread using SCI running under simulator, not
>
>> on the target
>
>>
>
>> Joel,
>
>>
>
>> I don't know why code working in simulator doesn't work in target, but
>> you
>
>> oversimplified your minimal program. XGATE setup is missing, interrupt
>
>> controller setup is missing, XGATE interrupt vector table is missing.
>
>>
>
>> BTW XGATE V2 threads are uninterruptable. No new XGATE thread can be
>
>> started
>
>> until XGATE becomes idle. Make sure you exit from your other threads and
>
>> clear corresponding interrupt flags or interrupt masks. For example if
>> you
>
>> have just RTI thread, then verify that it doesn't loop forever, else your
>
>> SCI thread won't ever start.
>
>>
>
>> Edward
>
>>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

RE: XGate thread using SCI running under simulator, not on the target

jpdi
Thank you, Edward, for your tracks.
I'll work on them in a couple of days.
I found too sample program on Freescale site (Application Note 3144), just
about SCI and XGate.
Now, I've some food to eat !

Best regards.
Joel


> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]] De la part de
> Edward Karpicz
> Envoyé : mercredi 5 mars 2008 22:22
> À : [hidden email]
> Objet : Re: [68HC12] XGate thread using SCI running under simulator, not
> on the target
>
> Joel,
>
> Maybe it's another simplification, but in your SCI init routine you are
> enabling RIE interrupt and in your SCI handler I see only transmitters
> code.
> RDRF flag isn't handled, it's read but isn't cleared by reading SCI1DRL.
> Anyway I just tried it as is, except that I enabled TDRE interrupt. XGATE
> SCI1 ISR got triggered. So problem must be somewhere else.
>
> Also
>
> 1) You init SCI1 first and enable RIE interrupt, then you route interrupts
> to XGATE. SCI char shouldn't arrive in the time between when you enable
> RIE
> and when you route SCI1 interrupts to XGATE. But I wonder what would
> happen
> if RIE would get pending at this time? I'm not sure if it is OK to switch
> routing of specific interrupt while it is pending and unmasked. I'd better
> swap in main() SetupXGATE() and SCI1Init(), so that routing is done before
> interrupt is enabled.
>
> 2) XGMCTL= 0x8181; //You enable XGATE interrupt here (XGIE). It sounds
> confusing, but it's a S12X interrupt :-). Imagine for a moment that XGATE
> can't run any code and it's something simple like key wakeup pin
> peripheral
> module. It has its own interrupt XGIE and you handle this interrupt using
> S12X.
> In fact XGATE has a lot of XGIF flags. There's a special XGATE instruction
> SIF, that is used to set XGIF flags. XGATE code executes SIF (set
> interrupt
> flags), XGIF flag gets set and XGIE interrupt becoms pending. So do you
> have
> S12X handler for this interrupt? If not then you shouldn't set XGIE, I
> guess.
>
>
> Regards,
>
> Edward
>


Reply | Threaded
Open this post in threaded view
|

Unable to flash 9s12 !

jpdi
In reply to this post by Edward Karpicz
Hi all !

It's a lot of time I didn't program with S12.
Now, I've some soft release to do, and the cpu I try to modify soft refuses
to be programmed.
NoIce reports me
        "Verify fail at add... wanted xx, got yy
        (if this is protection byte, NoIce may prevent you from locking
yourself out)
        .../..."

I never-never protected the CPUs I use.

I tried with 3 other boards I've, wich refused to be programmed (same CPU).
Just 1 another is OK... It's the same CPU, but not the good board !

Config :
        ICC12
        NoIce version 9.4
        CPU MC9s12xdp512cal
        P&E BDM

Note :
        1) The USB P&E BDM I usually use is not recognize by my computer
now.
        So I used an old BDM on parallel port. I tried to reinstall P&E
driver, without any success.
        May be a conflict between 2 systems (Microchip ICD3 and P&E BDM ?)
       
        2) NoIce 9.4 is up to date.

What happend ?

Thanks a lot for you help.

Joel


Reply | Threaded
Open this post in threaded view
|

Re: Unable to flash 9s12 !

Alex Bratovic

Hi Joel
I had to update the BDM firmware of my Blue P&E USB hcs08/hcs12 rev B
multilink before it would work properly after updating Codewarrior to 5.1
The latest P&E drivers removed support for parallel port BDM. Uninstall
and download Version 9.

cheers
Alex


[hidden email] wrote:

> There is 1 message in this issue.
>
> Topics in this digest:
>
> 1a. Unable to flash 9s12 !    
>     From: jpdi
>
>
> Message
> ________________________________________________________________________
> 1a. Unable to flash 9s12 !
>     Posted by: "jpdi" [hidden email] dieseinfo
>     Date: Fri Mar 4, 2011 1:15 am ((PST))
>
> Hi all !
>
> It's a lot of time I didn't program with S12.
> Now, I've some soft release to do, and the cpu I try to modify soft refuses
> to be programmed.
> NoIce reports me
> "Verify fail at add... wanted xx, got yy
> (if this is protection byte, NoIce may prevent you from locking
> yourself out)
> .../..."
>
> I never-never protected the CPUs I use.
>
> I tried with 3 other boards I've, wich refused to be programmed (same CPU).
> Just 1 another is OK... It's the same CPU, but not the good board !
>
> Config :
> ICC12
> NoIce version 9.4
> CPU MC9s12xdp512cal
> P&E BDM
>
> Note :
> 1) The USB P&E BDM I usually use is not recognize by my computer
> now.
> So I used an old BDM on parallel port. I tried to reinstall P&E
> driver, without any success.
> May be a conflict between 2 systems (Microchip ICD3 and P&E BDM ?)
>
> 2) NoIce 9.4 is up to date.
>
> What happend ?
>
> Thanks a lot for you help.
>
> Joel
>
>
>
>  
Reply | Threaded
Open this post in threaded view
|

RE: Unable to flash 9s12 !

jpdi
In reply to this post by jpdi
Sorry !

Desinstall P&E driver, then re-install it, and it's OK now.

 

> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]]
> De la part de jpdi
> Envoyé : vendredi 4 mars 2011 10:16
> À : [hidden email]
> Objet : [68HC12] Unable to flash 9s12 !
>
> Hi all !
>
> It's a lot of time I didn't program with S12.
> Now, I've some soft release to do, and the cpu I try to
> modify soft refuses to be programmed.
> NoIce reports me
> "Verify fail at add... wanted xx, got yy
> (if this is protection byte, NoIce may prevent you from
> locking yourself out)
> .../..."
>
> I never-never protected the CPUs I use.
>
> I tried with 3 other boards I've, wich refused to be
> programmed (same CPU).
> Just 1 another is OK... It's the same CPU, but not the good board !
>
> Config :
> ICC12
> NoIce version 9.4
> CPU MC9s12xdp512cal
> P&E BDM
>
> Note :
> 1) The USB P&E BDM I usually use is not recognize by my
> computer now.
> So I used an old BDM on parallel port. I tried to
> reinstall P&E driver, without any success.
> May be a conflict between 2 systems (Microchip ICD3 and
> P&E BDM ?)
>
> 2) NoIce 9.4 is up to date.
>
> What happend ?
>
> Thanks a lot for you help.
>
> Joel
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Unable to flash 9s12 !

Rob Milne
Hi Joel,

The following is from the "Flash Burning" section of the NoICE documentation (bold type)...

"The HCS12 family has a security feature controlled by the contents of the Flash word at address 0xFF0E/0xFF0F. The NoICE Flash burner forces this word to the value 0xFFFE. This disables security. The alternative would be to let you program the bits, and then have BDM be disabled the next time you reset the chip. NoICE is a debugger, not a production Flash burner, so we assume that you want to use BDM to debug your program."

I wasted a fair bit of time trying to experiment with security before I found this information.  I understand the intent of the software, however it does creates a development blind-spot.  In the end I was forced to purchase an expensive programmer.
 
-rob


--- In [hidden email], "jpdi" <jpdi@...> wrote:

>
> Sorry !
>
> Desinstall P&E driver, then re-install it, and it's OK now.
>
>  
>
> > -----Message d'origine-----
> > De : [hidden email] [mailto:[hidden email]]
> > De la part de jpdi
> > Envoyé : vendredi 4 mars 2011 10:16
> > À : [hidden email]
> > Objet : [68HC12] Unable to flash 9s12 !
> >
> > Hi all !
> >
> > It's a lot of time I didn't program with S12.
> > Now, I've some soft release to do, and the cpu I try to
> > modify soft refuses to be programmed.
> > NoIce reports me
> > "Verify fail at add... wanted xx, got yy
> > (if this is protection byte, NoIce may prevent you from
> > locking yourself out)
> > .../..."
> >
> > I never-never protected the CPUs I use.
> >
> > I tried with 3 other boards I've, wich refused to be
> > programmed (same CPU).
> > Just 1 another is OK... It's the same CPU, but not the good board !
> >
> > Config :
> > ICC12
> > NoIce version 9.4
> > CPU MC9s12xdp512cal
> > P&E BDM
> >
> > Note :
> > 1) The USB P&E BDM I usually use is not recognize by my
> > computer now.
> > So I used an old BDM on parallel port. I tried to
> > reinstall P&E driver, without any success.
> > May be a conflict between 2 systems (Microchip ICD3 and
> > P&E BDM ?)
> >
> > 2) NoIce 9.4 is up to date.
> >
> > What happend ?
> >
> > Thanks a lot for you help.
> >
> > Joel
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>


Reply | Threaded
Open this post in threaded view
|

RE: Re: Unable to flash 9s12 !

jpdi
Thank you, Rob.
 
I knew the possibility to secure code, but never use it. Bu It don't know
NoIce forces that security disabled.

After some time searching about P&E drivers, a full uninstall then install
again P&E driver, then reboot solved the problem.
The strange thing was this problem appears on my 2 computers... where I
installed MpLab from Microchip too.
I suppose some problem here.

So, it's OK now.
Thank a lot
Best regard

Joel


> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]]
> De la part de Rob
> Envoyé : vendredi 4 mars 2011 14:18
> À : [hidden email]
> Objet : [68HC12] Re: Unable to flash 9s12 !
>
> Hi Joel,
>
> The following is from the "Flash Burning" section of the
> NoICE documentation (bold type)...
>
> "The HCS12 family has a security feature controlled by the
> contents of the Flash word at address 0xFF0E/0xFF0F. The
> NoICE Flash burner forces this word to the value 0xFFFE. This
> disables security. The alternative would be to let you
> program the bits, and then have BDM be disabled the next time
> you reset the chip. NoICE is a debugger, not a production
> Flash burner, so we assume that you want to use BDM to debug
> your program."
>
> I wasted a fair bit of time trying to experiment with
> security before I found this information.  I understand the
> intent of the software, however it does creates a development
> blind-spot.  In the end I was forced to purchase an expensive
> programmer.
>  
> -rob
>
>
> --- In [hidden email], "jpdi" <jpdi@...> wrote:
> >
> > Sorry !
> >
> > Desinstall P&E driver, then re-install it, and it's OK now.
> >
> >  
> >
> > > -----Message d'origine-----
> > > De : [hidden email] [mailto:[hidden email]] De la
> > > part de jpdi Envoyé : vendredi 4 mars 2011 10:16 À :
> > > [hidden email] Objet : [68HC12] Unable to flash 9s12 !
> > >
> > > Hi all !
> > >
> > > It's a lot of time I didn't program with S12.
> > > Now, I've some soft release to do, and the cpu I try to
> modify soft
> > > refuses to be programmed.
> > > NoIce reports me
> > > "Verify fail at add... wanted xx, got yy
> > > (if this is protection byte, NoIce may prevent you from locking
> > > yourself out)
> > > .../..."
> > >
> > > I never-never protected the CPUs I use.
> > >
> > > I tried with 3 other boards I've, wich refused to be programmed
> > > (same CPU).
> > > Just 1 another is OK... It's the same CPU, but not the
> good board !
> > >
> > > Config :
> > > ICC12
> > > NoIce version 9.4
> > > CPU MC9s12xdp512cal
> > > P&E BDM
> > >
> > > Note :
> > > 1) The USB P&E BDM I usually use is not recognize by my
> computer
> > > now.
> > > So I used an old BDM on parallel port. I tried to reinstall P&E
> > > driver, without any success.
> > > May be a conflict between 2 systems (Microchip ICD3 and
> P&E BDM ?)
> > >
> > > 2) NoIce 9.4 is up to date.
> > >
> > > What happend ?
> > >
> > > Thanks a lot for you help.
> > >
> > > Joel
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>