This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.
Posted: Mon Feb 07, 2005 12:54 am
As the subject goes, what are the main advantages of using emulators over BDM interfaces?
From the embedded applications I have developed I found no real advantage of using an emulator ahead of BDM interfaces, BDM allowed me to do what I required (just limited to one hardware breakpoint - but that is workable)
comments?
From the embedded applications I have developed I found no real advantage of using an emulator ahead of BDM interfaces, BDM allowed me to do what I required (just limited to one hardware breakpoint - but that is workable)
comments?
Posted: Mon Feb 07, 2005 2:42 am
Personally I'd rather use a BDM. Put your chip striaght into your target eviornment and go to town.
Posted: Mon Feb 07, 2005 7:05 am
I am in the business of designing emulators for the HC12, HCS12 and S12X family, so I am biased. However: There are many important advantages for a full-emulator over a BDM.
The advantage of the full-emulator in in shortening a typical debug-cycle by months, thus returning the investment, and actually saving mony by reducing the enginneering time.
Here are a few key features where the full-emulator has advantages over a BDM to debug an HCS12 application:
1. The Trace makes debugging of many elusive bugs much easier. Many times there are bugs that manifest in the code getting to execute a certain function that you did not expect, and have no idea how it got to. Debugging how it did can take days without a trace. With the trace debugging such cases become much easier, as you have the entire execution history and data reads and writes right there in front of you on the screen - read from the trace.
2. Debugging through specific HCS12 operating conditions is not possible or is very limmitted using BDMs, but is possible extensively supported with full-emulators. These operating conditions include for example:
- Debugging through Reset or COP-Watchdog Reset
- Debugging through all variations of STOP and WAIT power-down mode.
- Debugging through many speed changes - sometimes it is essential to frequently change the clock speed to adjust power-consumption.
- Debugging through Self-Clock mode (also called Limp-Home mode).
3. Performance analysis and Code Coverage. These are two functions that become available using a trace.
- Performance Analysis is the ability of the full-emulator to analyze the execution time (and exacution power as a percentage of the entire executiuon power) the code spends in each function, or sub-function, in order to help optimize the performance of the code.
- Code coverage is needed where safety is very important. Code coverage analyzes the code as it executes (in run-time with no changes to the code), and shows what lines of code are executed, and what lines of code are not executed, and need to be validated to be sure the code is safe to use.
4. The trace is equipped with powerfull triggers and filiters.
Triggers - allow to stop the trace and possibly also execution when some some conditions become true. These conditions can be complex ones - for example when A becomes equal B and C becomes equal D.
Filter - allows to narrow-down the trace to record part of the execution history, or part of the data read and write exchange, to collect information over very large periods of time.
5. The trace has time-stamp (resolution of 10-20nSEC, timeout period of several days). The time-stamp allows timing and measuring processes from point A in code to point B in code.
6. In some applications there is a need to debug the application without stopping it - since stopping it would disturb the operation of system in a way that is harmful or is not easy to recover from. This is possible using the trace of a full-emulator. The trace can be started, stopped, and be re-programmed in the background, without stopping or slowing down the HCS12 CPU from executing at full-speed, and display the necessary information to allow debugging the application.
7. The full emulator has an unlimitted number of software and hardware breakpoints availabe - as opposed to 2 - 4 breakpoints on the BDM (2 - 4 depending on the specific silicon used).
8. The full-emulator has emulation RAM that may be substituted for the Flash. This makes the loading of new code faster, and debugging more convinient. (the internal Flash can also be used if needed)
9. The full-emulator has Shadow RAM, that can show the value of memory in run-time under all operating conditions. The clasic example where this is important is in an application where the code is in power-down mode 99% of the time, but there is a requirement to see when a cetrain variable becomes equal to some value in the small bursts of execution.
The heavy users of the HCS12 and S12X families are the automotive industry. The automotive users select almost always full-emulators to debug new development. The reason is not because they have deep pockets and want to throw away money. On the countrary, the reason is full-emulators allow to find the bugs earlier and thus shorten a typical debug cycle by months - so they quickly return their invest by saving on the engineering time.
If you like you can read more information about the Nohau HCS12 full-emulator in the following article:
http://www.nohau.com/products/hcs12_emulator_features.pdf
Hope this helps,
The advantage of the full-emulator in in shortening a typical debug-cycle by months, thus returning the investment, and actually saving mony by reducing the enginneering time.
Here are a few key features where the full-emulator has advantages over a BDM to debug an HCS12 application:
1. The Trace makes debugging of many elusive bugs much easier. Many times there are bugs that manifest in the code getting to execute a certain function that you did not expect, and have no idea how it got to. Debugging how it did can take days without a trace. With the trace debugging such cases become much easier, as you have the entire execution history and data reads and writes right there in front of you on the screen - read from the trace.
2. Debugging through specific HCS12 operating conditions is not possible or is very limmitted using BDMs, but is possible extensively supported with full-emulators. These operating conditions include for example:
- Debugging through Reset or COP-Watchdog Reset
- Debugging through all variations of STOP and WAIT power-down mode.
- Debugging through many speed changes - sometimes it is essential to frequently change the clock speed to adjust power-consumption.
- Debugging through Self-Clock mode (also called Limp-Home mode).
3. Performance analysis and Code Coverage. These are two functions that become available using a trace.
- Performance Analysis is the ability of the full-emulator to analyze the execution time (and exacution power as a percentage of the entire executiuon power) the code spends in each function, or sub-function, in order to help optimize the performance of the code.
- Code coverage is needed where safety is very important. Code coverage analyzes the code as it executes (in run-time with no changes to the code), and shows what lines of code are executed, and what lines of code are not executed, and need to be validated to be sure the code is safe to use.
4. The trace is equipped with powerfull triggers and filiters.
Triggers - allow to stop the trace and possibly also execution when some some conditions become true. These conditions can be complex ones - for example when A becomes equal B and C becomes equal D.
Filter - allows to narrow-down the trace to record part of the execution history, or part of the data read and write exchange, to collect information over very large periods of time.
5. The trace has time-stamp (resolution of 10-20nSEC, timeout period of several days). The time-stamp allows timing and measuring processes from point A in code to point B in code.
6. In some applications there is a need to debug the application without stopping it - since stopping it would disturb the operation of system in a way that is harmful or is not easy to recover from. This is possible using the trace of a full-emulator. The trace can be started, stopped, and be re-programmed in the background, without stopping or slowing down the HCS12 CPU from executing at full-speed, and display the necessary information to allow debugging the application.
7. The full emulator has an unlimitted number of software and hardware breakpoints availabe - as opposed to 2 - 4 breakpoints on the BDM (2 - 4 depending on the specific silicon used).
8. The full-emulator has emulation RAM that may be substituted for the Flash. This makes the loading of new code faster, and debugging more convinient. (the internal Flash can also be used if needed)
9. The full-emulator has Shadow RAM, that can show the value of memory in run-time under all operating conditions. The clasic example where this is important is in an application where the code is in power-down mode 99% of the time, but there is a requirement to see when a cetrain variable becomes equal to some value in the small bursts of execution.
The heavy users of the HCS12 and S12X families are the automotive industry. The automotive users select almost always full-emulators to debug new development. The reason is not because they have deep pockets and want to throw away money. On the countrary, the reason is full-emulators allow to find the bugs earlier and thus shorten a typical debug cycle by months - so they quickly return their invest by saving on the engineering time.
If you like you can read more information about the Nohau HCS12 full-emulator in the following article:
http://www.nohau.com/products/hcs12_emulator_features.pdf
Hope this helps,
Posted: Mon Feb 07, 2005 1:28 pm
I agree with Doron, I would always go for the full ICE if I had the choice. As he said it does shorten the debug cycle, however they are of course much more expensive, and sometimes its difficult to quantify the potential time saving they will bring.
Doron, how do you cope with different revisions of silicon in your ICE.
Doron, how do you cope with different revisions of silicon in your ICE.
Posted: Mon Feb 07, 2005 1:32 pm
Another consideration of course is that some devices don't have any ICE support, the HCS08 has been designed without and external bus/test interface which means an ICE can not be implemented. I saw this as a barrier for the S08 in the Automotive market, however I have now seen that this is being changed for the future S08s.
Posted: Mon Feb 07, 2005 2:16 pm
[how do you cope with different revisions of silicon in your ICE.]
I think we cope with different silicons and different revisions very well. We take these issues very seriously:
First, we currently offer 13 different CPU-Modules only to cover the HCS12 family (S12X family is not included in this number). For every different flavour of the HCS12 family, we have the full-emulator CPU-Module that is populated with the exact silicon that would be used in the application. This allows maximum compatibility between the full-emulator and the final traget. For example for the MC9S12D family we offer 6 different CPU-Modules - for the MC9S12- DP512, DT256 (Barracuda4), DP256, DT128, DJ64 and D32.
Second. we try to use the latest silicon mask-set with the minimum errata in our production. Every several months we have a big process with Freescale of getting the latest available mask-sets for the production during the following next few months. We have just completed such a round two weeks ago.
Furthermore, if a customer asks us to install a specific mask-set (differet from the most recent), and can supply us the specific HCS12 silicon, we are happy to install it on our Emulator system, test it, and provide the emulator with this silicon.
I think we cope with different silicons and different revisions very well. We take these issues very seriously:
First, we currently offer 13 different CPU-Modules only to cover the HCS12 family (S12X family is not included in this number). For every different flavour of the HCS12 family, we have the full-emulator CPU-Module that is populated with the exact silicon that would be used in the application. This allows maximum compatibility between the full-emulator and the final traget. For example for the MC9S12D family we offer 6 different CPU-Modules - for the MC9S12- DP512, DT256 (Barracuda4), DP256, DT128, DJ64 and D32.
Second. we try to use the latest silicon mask-set with the minimum errata in our production. Every several months we have a big process with Freescale of getting the latest available mask-sets for the production during the following next few months. We have just completed such a round two weeks ago.
Furthermore, if a customer asks us to install a specific mask-set (differet from the most recent), and can supply us the specific HCS12 silicon, we are happy to install it on our Emulator system, test it, and provide the emulator with this silicon.
Posted: Mon Feb 07, 2005 11:42 pm
thanks for the responses people,
main reason I asked is I have inherited a isystem emulator for the hc12b32 chip and BDM debugger. Whilst developing projects based on the older b32 I tried both the ICE and BDM and did not notice any real advantages.
I guess there were no major bugs to be found!.
Have not used the trace function of the ICE before, I will look into it for next time.
The main problem I am faced with is the fact the isystem 2000 bdm module is not compatible with the modern ics and the ice is ic specific.
So essentially it is more important for me to have a more universal bdm then ic specific ice.
thanks again for your comments.
main reason I asked is I have inherited a isystem emulator for the hc12b32 chip and BDM debugger. Whilst developing projects based on the older b32 I tried both the ICE and BDM and did not notice any real advantages.
I guess there were no major bugs to be found!.
Have not used the trace function of the ICE before, I will look into it for next time.
The main problem I am faced with is the fact the isystem 2000 bdm module is not compatible with the modern ics and the ice is ic specific.
So essentially it is more important for me to have a more universal bdm then ic specific ice.
thanks again for your comments.
Posted: Wed Feb 09, 2005 7:04 pm
Of course one big advantage of BDM is the extermely low price and reletavely high functionality.
Posted: Wed Feb 09, 2005 7:28 pm
I agree with you. Personally I am doing microcontrollers mainly as a hobby interest. There is no way I can afford to buy an ICE in my wildest dreams. As much as I woudlnt mind having an ICE I think I can manage without one. Assuming you program in assembly the P&E debugger works great though it gets a little flakey at higher clock speeds from what I have heard. I have played around with the PsoC (from cypress microsystems) quite a bit with there little $65 dev board, programmer and assembler (and C compiler i got a free license at one of there seminar things when they were giving the invention boards away) and don't see ever needing more than what I recieved in that kit to do any future development with them. Instead of spending the $600 on there full sweet I'd buy a bunch of other components 
Just my POV as one of the little guys in the microcontroller world.
Just my POV as one of the little guys in the microcontroller world.