Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
Discussion Groups | 68HC12 | D60A bootloading
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Problems with RealTimeInterrupts using ICC12 - Stefan Brandt - Apr 19 3:49:00 2003
|
hello! today i am first time here and hope someone will help me ;-) it is even the first time using interrupthandlers, so i am still unexperienced ;-( i tryed to edit a small program, which flashes a LED in defined cycles, but the ICC12 compiler does not translate the code to a *.S19 file. the problemlien is marked by many: !!!!!!!!!!!!! what is wrong in my program? Thanx!!! Stefan here the program: #define RTICTL _P(0x14) #define RTIFREG _P(0x15) #include <HC12.H> int x; int counter; void delay(x)//x=1 entspricht ca. 0.0016ms { while (x!=0) { x--; } } #pragma interrupt_handler RTIhandler void RTIhandler (void) { int a; RTIFREG = 0x80; //reset RTI-flag if (counter < 10) { counter++; } else { counter=0; a=10; while(a!=0)//led flashes 10 times { PORTT|=0x08; delay(32000); //f=10Hz PORTT&=~0x08; delay(32000); a--; } } } //vectoraddress for RTIhandler #pragma abs_address: 0xfff0 void (*RTI_vector[])()={RTIhandler};//in this line the compiler says:!!!!!!!!!!!!!!!!!!!!!!!!!!!!! //'declaring a function without prototype may cause errors' !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! #pragma end_abs_address void main(void) { DDRT=0xFF; asm("CLI \n"); RTICTL=0x07; //Adresse 0014 / t=134.072ms @ 4MHz counter=0; } /********* vectors.c ***********************/ /* As is, all interrupts except reset jumps to 0xffff, which is most * likely not going to useful. To replace an entry, declare your function, * and then change the corresponding entry in the table. For example, * if you have a SCI handler (which must be defined with * #pragma interrupt_handler ...) then in this file: * add * extern void SCIHandler(); * before th table. * In the SCI entry, change: * DUMMY_ENTRY, * to * SCIHandler, */ #if defined(_HC12) /* add any interruot vectors in here too for HC12 paged compilation */ #pragma nonpaged_function _start #endif extern void _start(void); /* entry point in crt??.s */ #define DUMMY_ENTRY (void (*)(void))0xFFFF #pragma abs_address:0xffd0 /* change the above address if your vector starts elsewhere */ void (*interrupt_vectors[])(void) = { /* to cast a constant, say 0xb600, use (void (*)())0xb600 */ /* 812A4 vectors starts at 0xff80, but most entries are not used if you use Key Wakeup H, change the start address to 0xffCE and add one entry to the beginning */ DUMMY_ENTRY, /* BDLC */ /* Key Wakeup J */ DUMMY_ENTRY, /* ATD */ /* ATD */ DUMMY_ENTRY, /* RESERVED */ /* SCI 1 */ DUMMY_ENTRY, /* SCI */ DUMMY_ENTRY, /* SPI */ DUMMY_ENTRY, /* PAIE */ DUMMY_ENTRY, /* PAO */ DUMMY_ENTRY, /* TOF */ DUMMY_ENTRY, /* HC12 TC7 */ DUMMY_ENTRY, /* TC6 */ DUMMY_ENTRY, /* TC5 */ DUMMY_ENTRY, /* TC4 */ DUMMY_ENTRY, /* TC3 */ DUMMY_ENTRY, /* TC2 */ DUMMY_ENTRY, /* TC1 */ DUMMY_ENTRY, /* TC0 */ RTIhandler, /* RTI */ DUMMY_ENTRY, /* IRQ */ DUMMY_ENTRY, /* XIRQ */ DUMMY_ENTRY, /* SWI */ DUMMY_ENTRY, /* ILLOP */ DUMMY_ENTRY, /* COP */ DUMMY_ENTRY, /* CLM */ _start /* RESET */ }; #pragma end_abs_address /**********Ende vectors.c*****************************/ |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
// - Steve Russell - Apr 20 14:34:00 2003
|
Hi Stefan, You were wise to try a small program. It is a good beginning. I had no trouble reading it and understanding most of what you are trying to do. I have tried to act like a compiler on the line which causes complaints, below. I have also given a suggestion about how to give the compiler the information it needs. I have put some more recommendations in the code. These are what I would do, but of course you may have reasons for doing otherwise. I have tried to explain why I would choose to do things differently. I have not tested the code that does the LED flashing in main(), but it is close to working. I have some further comments: Initializing the Vector for resets, traps and interrupts -------------------------------------------------------- There are many possible causes of unexpected interrupts and resets. Having all unexpected interrupts go to 0xFFFF is one of the least helpful things you can do. A better method costs a little editing once, but then pays off every time an unexpected interrupt occurs. I recommend filling all the possible interrupt vector locations form 0xFF80 to 0xFFFF with the addresses of unique functions that loop forever. This prevents any further loss of data, and if you can stop the target, it becomes perfectly clear what the problem is. Enabling Interrupts before Initialization of Interrupt Sources is Completed. ---------------------------------------------------------------------------- In main, you have the asm("CLI \n"); before the last RTI parameter and counter, used in the interrupt routine have been set up. Even though you think that the RTI interrupt will not happen for a while, you will get unexpected results if the interrupt should happen as soon as interrupts are enabled. Making a habit of completing the initialization of the interrupt source and the interrupt code before turning on interrupts will cost you noting, and prevent some surprising results. Real Time Programming Style --------------------------- While your interrupt function will probably work, more or less, it is not a good idea to spend any more time than necessary inside an interrupt service routine. Waiting in a loop in the interrupt service routine for the LED to blink may cause other interrupts to be lost in a practical system. A better method is put an infinite loop in main that tests flags and causes things that are not millisecond time critical, such as blinking the LED, to happen. In your RTI code just set a boolean saying blink, and in the infinite loop in main do the blinking. Style of Calculating Times -------------------------- You set the RTI parameters to hex constants and then give a comment with the calculation of the times. Using #define you can define formulas as well as values. With a little more typing, you can calculate the RTI settings and the counts in terms of your desired output rate or delay. If the values in the #define formula are all constants and all defined before the formula is evaluated, the compiler will usually recognize that the expression can evaluated at compile time. This makes the reason for the particular values clear, and if you ever need to change the values, you do not need to recalculate the numbers yourself. Hope you find this discussion understandable and useful. Please let me know if you have further questions. Good luck! Steve At 01:49 AM 4/19/2003, Stefan Brandt wrote: >hello! > >today i am first time here and hope someone will help me ;-) > >it is even the first time using interrupthandlers, so i am still >unexperienced ;-( >i tryed to edit a small program, which flashes a LED in defined cycles, but >the ICC12 compiler does not translate the code to a *.S19 file. > >the problemlien is marked by many: !!!!!!!!!!!!! > >what is wrong in my program? > >Thanx!!! > >Stefan >here the program: > >#define RTICTL _P(0x14) >#define RTIFREG _P(0x15) >#include <HC12.H> >int x; >int counter; Recommendation for making LED flashing happen in main, not in interrupt service routine. unsinged int StartLEDFlashing = 0 ; // times ISR activated flashing. unsinged int LastStartLEDFlashing = 0 ; // Last number of times ISR activated flashing. unsigned long IdleCount = 0 ; // Number of times through idle loop. You do not declare the type of the x parameter of delay, leaving it up to the compiler. better style is: #define DELAY_MS( milliseconds )( ( int )( milliseconds / 16 ) ) void delay( int x ) // x=1 entspricht ca. 0.0016ms >void delay(x)//x=1 entspricht ca. 0.0016ms >{ > > while (x!=0) > { > x--; > } >} > >#pragma interrupt_handler RTIhandler >void RTIhandler (void) >{ >int a; > >RTIFREG = 0x80; //reset RTI-flag > >if (counter < 10) > { > counter++; > } >else > { > counter=0; > a=10; > while(a!=0)//led flashes 10 times > { > PORTT|=0x08; > delay(32000); //f=10Hz > PORTT&=~0x08; > delay(32000); Using the above delay suggestion this becomes: PORTT|=0x08; delay( DELAY_MS( 50 ) ) ; //f=10Hz PORTT&=~0x08; delay( DELAY_MS( 50 ) ) ; but, code that calls delay should not be in an interrupt service routine at all. > a--; Instead do something like StartLEDFlashing++ ; > } > } >} > >//vectoraddress for RTIhandler >#pragma abs_address: 0xfff0 >void (*RTI_vector[])()={RTIhandler};//in this line the compiler Defining a vector of pointers to a function with no parameters, initialized to 1 item which is RTIhandler. There is no prototype for the elements of the vector, and the compiler is not allowed by the C specification to guess that its the type of RTIhandler. Try something like: typedef void ( * P_RTI_HANDLER )( void ) ; // pointer to RTIhandler type #pragma interrupt_handler RTIhandler void RTIhandler (void) { ... } //vectoraddress for RTIhandler #pragma abs_address: 0xfff0 P_RTI_HANDLER RTI_vector[] = { RTIhandler }; >says:!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >//'declaring a function without prototype may cause errors' >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >#pragma end_abs_address > > >void main(void) >{ >DDRT=0xFF; >asm("CLI \n"); The interrupts are now enabled, but the RTICTL setup is not finished! The value of counter is not yet initialized! What would happen if you got an RTI interrupt RIGHT HERE! >RTICTL=0x07; //Adresse 0014 / t=134.072ms @ 4MHz >counter=0; You will exit main at this point. Instead I recommend something like: while ( TRUE ) { // note careful use of unsigned arithmetic so that counting around // through the highest unsigned number to 0 does not cause problems if ( ( StartLEDFlashing - LastStartLEDFlashing ) > 0 ) { if ( StartLEDFlashing - LastStartLEDFlashing ) > 1 ) { // have missed a start flashing event ... } LastStartLEDFlashing = StartLEDFlashing ; PORTT|=0x08; delay( DELAY_MS( 50 ) ) ; //f=10Hz PORTT&=~0x08; delay( DELAY_MS( 50 ) ) ; } IdleCount++ ; } > >} >/********* vectors.c ***********************/ > >/* As is, all interrupts except reset jumps to 0xffff, which is most >* likely not going to useful. To replace an entry, declare your function, >* and then change the corresponding entry in the table. For example, >* if you have a SCI handler (which must be defined with >* #pragma interrupt_handler ...) then in this file: >* add >* extern void SCIHandler(); >* before th table. >* In the SCI entry, change: >* DUMMY_ENTRY, >* to >* SCIHandler, >*/ >#if defined(_HC12) >/* add any interruot vectors in here too for HC12 paged compilation >*/ >#pragma nonpaged_function _start >#endif >extern void _start(void); /* entry point in crt??.s */ > >#define DUMMY_ENTRY (void (*)(void))0xFFFF > >#pragma abs_address:0xffd0 > >/* change the above address if your vector starts elsewhere >*/ >void (*interrupt_vectors[])(void) = > { > /* to cast a constant, say 0xb600, use > (void (*)())0xb600 > */ > /* 812A4 vectors starts at 0xff80, but most entries are not used > if you use Key Wakeup H, change the start address to 0xffCE and > add one entry to the beginning */ > DUMMY_ENTRY, /* BDLC */ /* Key Wakeup J */ > DUMMY_ENTRY, /* ATD */ /* ATD */ > DUMMY_ENTRY, /* RESERVED */ /* SCI 1 */ > DUMMY_ENTRY, /* SCI */ > DUMMY_ENTRY, /* SPI */ > DUMMY_ENTRY, /* PAIE */ > DUMMY_ENTRY, /* PAO */ > DUMMY_ENTRY, /* TOF */ > DUMMY_ENTRY, /* HC12 TC7 */ > DUMMY_ENTRY, /* TC6 */ > DUMMY_ENTRY, /* TC5 */ > DUMMY_ENTRY, /* TC4 */ > DUMMY_ENTRY, /* TC3 */ > DUMMY_ENTRY, /* TC2 */ > DUMMY_ENTRY, /* TC1 */ > DUMMY_ENTRY, /* TC0 */ > RTIhandler, /* RTI */ > DUMMY_ENTRY, /* IRQ */ > DUMMY_ENTRY, /* XIRQ */ > DUMMY_ENTRY, /* SWI */ > DUMMY_ENTRY, /* ILLOP */ > DUMMY_ENTRY, /* COP */ > DUMMY_ENTRY, /* CLM */ > _start /* RESET */ > }; >#pragma end_abs_address > >/**********Ende vectors.c*****************************/ > > >Yahoo! Groups Sponsor ><http://rd.yahoo.com/M=249982.3179269.4495679.1728375/D=egroupweb/S=1706554205:HM/A=1524963/R=0/*http://hits.411web.com/cgi-bin/autoredir?camp=556&lineid=3179269&prop=egroupweb&pos=HM>68f588.jpg > >68f5ed.jpg > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit ><http://www.motorola.com/mcu>http://www.motorola.com/mcu >>Yahoo! Terms of Service. ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* [Non-text portions of this message have been removed] |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
D60A bootloading - Gary Olmstead - Apr 21 11:28:00 2003
|
I'm having a problem writing a bootloader for the D60A. I followed the directions in the Technical Reference, v.2. It works, sometimes, but not always. When it works, it works perfectly. When it doesn't, it doesn't work at all, not a single byte will be programmed with anything, not even garbage. I know that the chip is good, because I can erase and program it with the COSMIC BDM. Has anyone else used a homegrown bootloader for the D60A? Gary Olmstead Toucan Technology Ventura CA |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - James M. Knox - Apr 21 11:49:00 2003
|
At 09:28 AM 4/21/2003 -0700, you wrote: >I'm having a problem writing a bootloader for the D60A. I followed the >directions in the Technical Reference, v.2. It works, sometimes, but not >always. When it works, it works perfectly. When it doesn't, it doesn't >work at all, not a single byte will be programmed with anything, not even >garbage. > >Has anyone else used a homegrown bootloader for the D60A? We've been using a heavily modified version of what started as one that Gordon (Motorola) supplied. We are only programming to Flash at this time, but it all works just fine... no problems. jmk ----------------------------------------------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------------------------------------------- |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - Gary Olmstead - Apr 21 12:20:00 2003
|
At 11:49 AM 4/21/03 -0500, you wrote: > >We've been using a heavily modified version of what started as one that >Gordon (Motorola) supplied. We are only programming to Flash at this time, >but it all works just fine... no problems. > > jmk "Heavily modified"... in what way? Fixed, or just added features? Gary |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - James M. Knox - Apr 21 12:42:00 2003
|
At 10:20 AM 4/21/2003 -0700, you wrote: >At 11:49 AM 4/21/03 -0500, you wrote: > > > >We've been using a heavily modified version of what started as one that > >Gordon (Motorola) supplied. We are only programming to Flash at this time, > >but it all works just fine... no problems. > >"Heavily modified"... in what way? Fixed, or just added features? Changed to do lots of error checking for valid code source, run within a protected block of Flash. That sort of stuff. I do not *recall* that we found any problems with the algorithms or code itself. jmk ----------------------------------------------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------------------------------------------- |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Problems with RealTimeInterrupts using ICC12 - Steve Russell - Apr 21 12:58:00 2003
|
Hi Stefan, You were wise to try a small program. It is a good beginning. I had no trouble reading it and understanding most of what you are trying to do. I have tried to act like a compiler on the line which causes complaints, below. I have also given a suggestion about how to give the compiler the information it needs. I have put some more recommendations in the code. These are what I would do, but of course you may have reasons for doing otherwise. I have tried to explain why I would choose to do things differently. I have not tested the code that does the LED flashing in main(), but it is close to working. I have some further comments: Initializing the Vector for resets, traps and interrupts -------------------------------------------------------- There are many possible causes of unexpected interrupts and resets. Having all unexpected interrupts go to 0xFFFF is one of the least helpful things you can do. A better method costs a little editing once, but then pays off every time an unexpected interrupt occurs. I recommend filling all the possible interrupt vector locations form 0xFF80 to 0xFFFF with the addresses of unique functions that loop forever. This prevents any further loss of data, and if you can stop the target, it becomes perfectly clear what the problem is. Enabling Interrupts before Initialization of Interrupt Sources is Completed. ---------------------------------------------------------------------------- In main, you have the asm("CLI \n"); before the last RTI parameter and counter, used in the interrupt routine have been set up. Even though you think that the RTI interrupt will not happen for a while, you will get unexpected results if the interrupt should happen as soon as interrupts are enabled. Making a habit of completing the initialization of the interrupt source and the interrupt code before turning on interrupts will cost you noting, and prevent some surprising results. Real Time Programming Style --------------------------- While your interrupt function will probably work, more or less, it is not a good idea to spend any more time than necessary inside an interrupt service routine. Waiting in a loop in the interrupt service routine for the LED to blink may cause other interrupts to be lost in a practical system. A better method is put an infinite loop in main that tests flags and causes things that are not millisecond time critical, such as blinking the LED, to happen. In your RTI code just set a boolean or a counter to indicate the "start blink" event, and in the infinite loop in main do the blinking. Style of Calculating Times -------------------------- You set the RTI parameters to hex constants and then give a comment with the calculation of the times. Using #define you can define formulas as well as values. With a little more typing, you can calculate the RTI settings and the counts in terms of your desired output rate or delay. If the values in the #define formula are all constants and all defined before the formula is evaluated, the compiler will usually recognize that the expression can evaluated at compile time. This makes the reason for the particular values clear, and when you need to change the values, you do not need to recalculate the numbers again. Hope you find this discussion understandable and useful. Please let me know if you have further questions. Good luck! Steve At 01:49 AM 4/19/2003, Stefan Brandt wrote: >hello! > >today i am first time here and hope someone will help me ;-) > >it is even the first time using interrupthandlers, so i am still >unexperienced ;-( >i tryed to edit a small program, which flashes a LED in defined cycles, but >the ICC12 compiler does not translate the code to a *.S19 file. > >the problemlien is marked by many: !!!!!!!!!!!!! > >what is wrong in my program? > >Thanx!!! > >Stefan >here the program: > >#define RTICTL _P(0x14) >#define RTIFREG _P(0x15) >#include <HC12.H> >int x; >int counter; // Recommendation for making LED flashing happen in main, not in interrupt // service routine. // Number of ISR flashing events. unsinged int StartLEDFlashing = 0 ; // Last number ISR flashing event handled by main(). unsinged int LastStartLEDFlashing = 0 ; unsigned long IdleCount = 0 ; // Number of times through main() idle loop. //=========================================================================== // You do not declare the type of the x parameter of delay, // leaving it up to the compiler. better style is: #define DELAY_MS( milliseconds )( ( int )( milliseconds / 16 ) ) void delay( int x ) // x=1 entspricht ca. 0.0016ms >void delay(x)//x=1 entspricht ca. 0.0016ms >{ > > while (x!=0) > { > x--; > } >} > >#pragma interrupt_handler RTIhandler >void RTIhandler (void) >{ >int a; > >RTIFREG = 0x80; //reset RTI-flag > >if (counter < 10) > { > counter++; > } >else > { > counter=0; > a=10; > while(a!=0)//led flashes 10 times > { > PORTT|=0x08; > delay(32000); //f=10Hz > PORTT&=~0x08; > delay(32000); // Using the above delay suggestion this becomes: PORTT|=0x08; delay( DELAY_MS( 50 ) ) ; //f=10Hz PORTT&=~0x08; delay( DELAY_MS( 50 ) ) ; > a--; > // but, code that calls delay should not be in an interrupt service routine // at all. // Instead do something like StartLEDFlashing++ ; // Signal Start flashing event > } > } >} > >//vectoraddress for RTIhandler >#pragma abs_address: 0xfff0 >void (*RTI_vector[])()={RTIhandler}; //in this line the compiler The compiler thinks that you are defining a vector of pointers to a function with no parameters, initialized to 1 item which is RTIhandler. There is no prototype for the elements of the vector, and the compiler is not allowed by the C specification to guess that it is the type of RTIhandler. Try something like: typedef void ( * P_RTI_HANDLER )( void ) ; // pointer to RTIhandler type #pragma interrupt_handler RTIhandler void RTIhandler (void) { ... } >says:!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >//'declaring a function without prototype may cause errors' >!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! > >#pragma end_abs_address > >void main(void) >{ >DDRT=0xFF; >asm("CLI \n"); // The interrupts are now enabled, but the RTICTL setup is not finished! // The value of counter is not yet initialized! // What would happen if you got an RTI interrupt RIGHT HERE! >RTICTL=0x07; //Adresse 0014 / t=134.072ms @ 4MHz >counter=0; // You will exit main at this point. // Instead I recommend something like: while ( TRUE ) { // note careful use of unsigned arithmetic so that counting around // through the highest unsigned number to 0 does not cause problems if ( ( StartLEDFlashing - LastStartLEDFlashing ) > 0 ) { if ( StartLEDFlashing - LastStartLEDFlashing ) > 1 ) { // have missed a start flashing event ... } LastStartLEDFlashing = StartLEDFlashing ; PORTT|=0x08; delay( DELAY_MS( 50 ) ) ; //f=10Hz PORTT&=~0x08; delay( DELAY_MS( 50 ) ) ; } IdleCount++ ; } >} >/********* vectors.c ***********************/ > >/* As is, all interrupts except reset jumps to 0xffff, which is most >* likely not going to useful. // Not just "not useful", but very confusing! >To replace an entry, declare your function, >* and then change the corresponding entry in the table. For example, >* if you have a SCI handler (which must be defined with >* #pragma interrupt_handler ...) then in this file: >* add >* extern void SCIHandler(); >* before th table. >* In the SCI entry, change: >* DUMMY_ENTRY, >* to >* SCIHandler, >*/ >#if defined(_HC12) >/* add any interruot vectors in here too for HC12 paged compilation >*/ >#pragma nonpaged_function _start >#endif >extern void _start(void); /* entry point in crt??.s */ > >#define DUMMY_ENTRY (void (*)(void))0xFFFF > >#pragma abs_address:0xffd0 // I recommend starting at 0xFF80 so as to cover the possibility of "Motorola Reserved" interrupts. >/* change the above address if your vector starts elsewhere >*/ >void (*interrupt_vectors[])(void) = > { > /* to cast a constant, say 0xb600, use > (void (*)())0xb600 > */ > /* 812A4 vectors starts at 0xff80, but most entries are not used > if you use Key Wakeup H, change the start address to 0xffCE and > add one entry to the beginning */ > DUMMY_ENTRY, /* BDLC */ /* Key Wakeup J */ > DUMMY_ENTRY, /* ATD */ /* ATD */ > DUMMY_ENTRY, /* RESERVED */ /* SCI 1 */ > DUMMY_ENTRY, /* SCI */ > DUMMY_ENTRY, /* SPI */ > DUMMY_ENTRY, /* PAIE */ > DUMMY_ENTRY, /* PAO */ > DUMMY_ENTRY, /* TOF */ > DUMMY_ENTRY, /* HC12 TC7 */ > DUMMY_ENTRY, /* TC6 */ > DUMMY_ENTRY, /* TC5 */ > DUMMY_ENTRY, /* TC4 */ > DUMMY_ENTRY, /* TC3 */ > DUMMY_ENTRY, /* TC2 */ > DUMMY_ENTRY, /* TC1 */ > DUMMY_ENTRY, /* TC0 */ > RTIhandler, /* RTI */ > DUMMY_ENTRY, /* IRQ */ > DUMMY_ENTRY, /* XIRQ */ > DUMMY_ENTRY, /* SWI */ > DUMMY_ENTRY, /* ILLOP */ > DUMMY_ENTRY, /* COP */ > DUMMY_ENTRY, /* CLM */ > _start /* RESET */ > }; >#pragma end_abs_address > >/**********Ende vectors.c*****************************/ ************************************************************************* Steve Russell mailto: Senior Software Design Engineer http://www.nohau.com Nohau Corporation phone: (408)866-1820 51 East Campbell Avenue fax: (408)378-7869 Campbell, CA 95008 ************************************************************************* |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: Problems with RealTimeInterrupts using ICC12 - Ritter, Alan - Apr 21 13:07:00 2003
|
Another important reason for using #defines that Steve didn't mention is that if you use a particular value (say a 100 ms timeout) in multiple places in your code, you only have to change it ONE place if your clock rate changes, but if you don't #define it, you have to go back and find every place that you used it (if you can remember...). /s/jar () http://www.mtritter.org EMAIL DISCLAIMER Please Note: The information contained in this message may be privileged and confidential, protected from disclosure, and/or intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying or other dissemination of this communication is strictly prohibited. If you received this communication in error, please immediately reply to the sender, delete the message and destroy all copies of it. Thank You |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - Gary Olmstead - Apr 21 21:27:00 2003
|
OK, well, thanks for the encouragement. I'll see if the timing is varying between program cycles. Doesn't seem reasonable, but I can't think of anything else right now. Gary At 12:42 PM 4/21/03 -0500, you wrote: > >Changed to do lots of error checking for valid code source, run within a >protected block of Flash. That sort of stuff. > >I do not *recall* that we found any problems with the algorithms or code >itself. |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
HC12B32 powerup - John Woods - Apr 22 7:50:00 2003
|
I've noticed something odd with the board i'm working on. After power is applied the HC12 TXD pin sometimes stays low. I'm not using a low-voltage reset chip, just applying VCC via a voltage regulator and two wires connected to the board. At other times TXD is high which I believe is the correct since other I/O pins have the right state and i can see a data burst on the TX pin. Is there sometime wrong with the crude power-up method I'm using that causes HC12 to remain in a stopped state? |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - Gary Olmstead - Apr 23 20:21:00 2003
|
James -- I solved most of it. I had brain fade when it came to calculating a time delay routine, and I transposed the definitions of two bits in the flash programming control register. There is still an odd problem in that sometimes the first programming attempt fails, but all subsequent ones pass. Probably a register that isn't being initialized properly. Thanks for your help. Gary At 12:42 PM 4/21/03 -0500, you wrote: >> >We've been using a heavily modified version of what started as one that >> >Gordon (Motorola) supplied. We are only programming to Flash at this time, >> >but it all works just fine... no problems. >> >>"Heavily modified"... in what way? Fixed, or just added features? > >Changed to do lots of error checking for valid code source, run within a >protected block of Flash. That sort of stuff. > >I do not *recall* that we found any problems with the algorithms or code >itself. > jmk >----------------------------------------------- >James M. Knox |
|
|
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: D60A bootloading - James M. Knox - Apr 24 8:49:00 2003
|
At 06:21 PM 4/23/2003 -0700, you wrote: >I solved most of it. I had brain fade when it came to calculating a time >delay routine, and I transposed the definitions of two bits in the flash >programming control register. There is still an odd problem in that >sometimes the first programming attempt fails, but all subsequent ones >pass. Probably a register that isn't being initialized properly. I agree, has that "feel" to the problem. Somewhat hard to troubleshoot - you may have better luck with a careful code inspection by hand. Glad you got it working. [FWIW, some years ago we had a design using the HC912B32, programming it with the P&E BDM pod. We switched the lab computer from an old slow machine to a nice new fast one. Suddenly the download time to flash for a particular project went from seconds to minutes!!! Always worked, just took forever. But at the same time, downloads to other HC912B32 projects continued to work just fine. Very strange... never did find it. <G>] jmk ----------------------------------------------- James M. Knox TriSoft ph 512-385-0316 1109-A Shady Lane fax 512-366-4331 Austin, Tx 78721 ----------------------------------------------- |
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )