Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
|
I have a client that is having problems with their HC12A4 controlled machines latching up while running. One suspect is EMI generating pulses on the reset line that are too short to generate a full reset, and a capacitor to ground on that line helped somewhat. A consultant they hired remembers an old errata for HC11's warning that IO inputs can be switched to outputs by EMI, and suggests resetting IO direction registers regularly. Is this still a concern with current HC12's? All the unused interrupts point to RTI instructions, and I have filled unused memory with NOP's with a pointer at the end back to legitimate code. Any other suggestions to help make the code more resistant to EMI while the consultant works on reducing the EMI? Thanks, David Graham |
|
|
|
If indeed the I/O is being switched due to EMI, then there is almost no way you would know unless you actively read the control registers...maybe not even then. I us the 912B32 in a high voltage control PCBA and made sure the chip was properly decoupled and use good partitioning tehcniques for power isolation and distribution to avoid resets. In addition, rather than use the internal COP, I use an external DS1232 and strobe it in the interrupts. An ounce of prevention etc.... Armand -----Original Message----- From: dm1graham [mailto:] Sent: Friday, June 14, 2002 8:59 AM To: Subject: [68HC12] HC12 Lockup I have a client that is having problems with their HC12A4 controlled machines latching up while running. One suspect is EMI generating pulses on the reset line that are too short to generate a full reset, and a capacitor to ground on that line helped somewhat. A consultant they hired remembers an old errata for HC11's warning that IO inputs can be switched to outputs by EMI, and suggests resetting IO direction registers regularly. Is this still a concern with current HC12's? All the unused interrupts point to RTI instructions, and I have filled unused memory with NOP's with a pointer at the end back to legitimate code. Any other suggestions to help make the code more resistant to EMI while the consultant works on reducing the EMI? Thanks, David Graham -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
|
Hi Armand, What are the partitioning techniques to avoid resets, I'm experiencing the same problem with PICs and 912B32 every time a motor gets involved in the system. As a solution, I don't power the controller and the motors from the same power supply, not practical but it works fine. Anybody has another suggestions. Thanks, Hossam >>> 06/14/02 12:56PM >>> If indeed the I/O is being switched due to EMI, then there is almost no way you would know unless you actively read the control registers...maybe not even then. I us the 912B32 in a high voltage control PCBA and made sure the chip was properly decoupled and use good partitioning tehcniques for power isolation and distribution to avoid resets. In addition, rather than use the internal COP, I use an external DS1232 and strobe it in the interrupts. An ounce of prevention etc.... Armand -----Original Message----- From: dm1graham [mailto:] Sent: Friday, June 14, 2002 8:59 AM To: Subject: [68HC12] HC12 Lockup I have a client that is having problems with their HC12A4 controlled machines latching up while running. One suspect is EMI generating pulses on the reset line that are too short to generate a full reset, and a capacitor to ground on that line helped somewhat. A consultant they hired remembers an old errata for HC11's warning that IO inputs can be switched to outputs by EMI, and suggests resetting IO direction registers regularly. Is this still a concern with current HC12's? All the unused interrupts point to RTI instructions, and I have filled unused memory with NOP's with a pointer at the end back to legitimate code. Any other suggestions to help make the code more resistant to EMI while the consultant works on reducing the EMI? Thanks, David Graham -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
|
I run +-28VDC, +-48VDC, & 100VDC systems using MCU's. We isolate the high power supply and RETURN from the PCBA supply/return at the PCBA and single point connect them at the PS source. We run rather long cables so this works well. You didn't mention what kind of motors and drives you are using... PWM or DC or stepper? The idea is to keep the analog sections isolated from the digital sections. I found that MCU's (especially CMOS types) are very easily disturbed by spikes on ANY pin. We do everything possible to decouple spikes and noise from any digital component...this includes isolated analog and digital ground planes on the PCBA etc. Armand -----Original Message----- From: Hossam Almasri [mailto:] Sent: Friday, June 14, 2002 10:22 AM To: Subject: RE: [68HC12] HC12 Lockup Hi Armand, What are the partitioning techniques to avoid resets, I'm experiencing the same problem with PICs and 912B32 every time a motor gets involved in the system. As a solution, I don't power the controller and the motors from the same power supply, not practical but it works fine. Anybody has another suggestions. Thanks, Hossam >>> 06/14/02 12:56PM >>> If indeed the I/O is being switched due to EMI, then there is almost no way you would know unless you actively read the control registers...maybe not even then. I us the 912B32 in a high voltage control PCBA and made sure the chip was properly decoupled and use good partitioning tehcniques for power isolation and distribution to avoid resets. In addition, rather than use the internal COP, I use an external DS1232 and strobe it in the interrupts. An ounce of prevention etc.... Armand -----Original Message----- From: dm1graham [mailto:] Sent: Friday, June 14, 2002 8:59 AM To: Subject: [68HC12] HC12 Lockup I have a client that is having problems with their HC12A4 controlled machines latching up while running. One suspect is EMI generating pulses on the reset line that are too short to generate a full reset, and a capacitor to ground on that line helped somewhat. A consultant they hired remembers an old errata for HC11's warning that IO inputs can be switched to outputs by EMI, and suggests resetting IO direction registers regularly. Is this still a concern with current HC12's? All the unused interrupts point to RTI instructions, and I have filled unused memory with NOP's with a pointer at the end back to legitimate code. Any other suggestions to help make the code more resistant to EMI while the consultant works on reducing the EMI? Thanks, David Graham -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu -------------------------------------------------------- To unsubscribe from this group, send an email to: To learn more about Motorola Microcontrollers, please visit http://www.motorola.com/mcu |
|
In my experiences, software solution to EMI problems are poor solutions, if solutions at all. I think that using the various watchdog timers effectively is your best bet. If your ram is not being corrupted by these events, you could have flags to indicate the state of various processes, which could be used to decide how to restart. If memory is getting trashed, you may need a hard reset every time. We use A4's with motors all the time. We have one product that consists of an A4 piggybacked to a servo amp which is wired to a brushless DC motor only inches away. This package becomes a smart motor on our buss. Four to twelve smart motors may be connected on this buss. We run high power and high current, and have had no problem with EMI. We use four layer circuit boards which allow us to have large ground and power planes, which seems to help a lot. There are some very good articles on the internet about designing for HMI tolerance, including one at Motorola, if memory serves. On our console side, we also use an A4 monitoring a keyboard, display, encoder inputs, analog inputs, digital inputs and mastering the buss (it's a busy little guy, but still has headroom to add a feature here or there). Here we DO have problems with HMI resets. I have a variable in Non-Volatile RAM to try to help figure out if I'm just waking up from the first time, if I've already been running a while, or if this was a partial reset. I then resynchronize with the system and we keep going. Since this is the user interface, and it only happens when the user has walked away, slid his rubber-soled shoes over a shag carpet and then sent a 50,000V arc to the metal case, there is usually tolerance for the momentary re-synchronization. We keep all important data in NVRam, so we have yet to lose any data due to this problem. We're still working on how to eliminate it altogether, but that won't be a software solution. BTW, in violation of the principle, "If it ain't broke, don't fix it," we are replacing all of the boards with A4's on them to new designs using the 912DT128A. The immediate gain is board size and chip count -- we need far fewer peripheral devices. The second gain is CAN buss for the communications. The long-term gain is the ability to upgrade to the 9s12 series when that becomes stable. Regards, Paul > -----Original Message----- > From: dm1graham [mailto:] > Sent: Friday, June 14, 2002 8:59 AM > To: > Subject: [68HC12] HC12 Lockup > I have a client that is having problems with their HC12A4 controlled > machines latching up while running. One suspect is EMI generating > pulses on the reset line that are too short to generate a full reset, > and a capacitor to ground on that line helped somewhat. A consultant > they hired remembers an old errata for HC11's warning that IO inputs > can be switched to outputs by EMI, and suggests resetting IO > direction registers regularly. Is this still a concern with current > HC12's? All the unused interrupts point to RTI instructions, and I > have filled unused memory with NOP's with a pointer at the end back > to legitimate code. Any other suggestions to help make the code more > resistant to EMI while the consultant works on reducing the EMI? > > Thanks, > David Graham > > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu |
|
-----Original Message----- From: Paul Johnson [mailto:] Sent: Saturday, June 15, 2002 9:03 AM To: Subject: RE: [68HC12] HC12 Lockup >In my experiences, software solution to EMI problems are poor solutions, if >solutions at all. I agree. >We use A4's with motors all the time. We have one product that consists of >an A4 piggybacked to a servo amp which is wired to a brushless DC motor only >inches away. What kind of motor controller chipset (or whatever) do you use? ( PWM? Uni/Bipolar analog? ) I love this stuff...very interested in other techniques. 8-) Armand |
|
|
|
> >We use A4's with motors all the time. We have one product that > consists of > >an A4 piggybacked to a servo amp which is wired to a brushless DC motor > only > >inches away. > What kind of motor controller chipset (or whatever) do you use? ( PWM? > Uni/Bipolar analog? ) > > I love this stuff...very interested in other techniques. We have an LM629 on our A4 board to provide the PWM signals to an AMC power amp. We are replacing these boards, however, with our new version which also uses the 629, but controlled by a 912DT128A and sending PWM to our own, proprietary, motor drive. This makes our package MUCH smaller, less expensive to manufacture, easier to mount, and provides built-in msCAN. We're quite happy with the new package, now that we have the msCAN working. Best regards, Paul |