Enclosed below are a list of the questions that were asked during the webinar. If you have additional questions, please send an email to [email protected].
1) Is there any special requirement on having all the tools connected together? ETAS, and Lauterbach, Frequency Limitations?
Yes, there are special requirements to connect multiple tools. This is not covered by the Nexus 5001 standard, but is implemented as an extension to the Nexus 5001 standard.
2) I assume the ETAS board has to be designed to the mother board CPU. How about the reusability of ETAS board inside the development modular?
This is somewhat tool and MCU dependent. Freescale has developed a methodology to allow some reuse of the tools from both Etas and dSpace. This specific implementation was standardized to handle an external SRAM and the Nexus signals on boards that connect with the MCU in the MCU footprint of the ECU.
Furthermore, both the ETKS3 (for Gen 2) and the XETKV2 (for Gen 3) work across multiple microcontrollers. GM used ETKS3s with ECUs containing the MPC5554, MPC5565, and MPC5566 MCUs. XETKV2s are also being used with several different micros (MPC5644A, MPC5674F, and MPC5676R). We have processes in place to share XETKV2s (board inside Gen 3 ECUs) within a specific controller program, but not across controller programs, which is different than Gen 2. However, there is still significant reuse with a given controller program. Typical quantity of development controllers can be measured in the 100’s in a single program. The Tier-1 supplier plays a major role in reusing the internal boards because they remove and install the boards into the development controllers.
3) Can the nexus interface be used to extract the core/ system performance, which can be then used for optimizing the application?
Nexus allows data to be captured on the execution of software on a microcontroller. From this information, performance and optimization information can be analyzed by a tool.
4) Are the message time stamps always absolute; can we have relative time stamps and save b/w on aux port?
The Nexus standard allows the timestamp to be either relative or absolute, however, it is up to the MCU vendor to define what is supported by a particular MCU.
5) How to save the graphical analysis data to a file which is captured by runtime analysis-chart display?
This could be tool dependent.
6) How do I get more information about the RP tools? specifically dual core Freescale MCUs?
Information about Rapid Prototyping tools should be obtained for the specific tool vendor. Please contact dSPACE or ETAS for more information.
7) Is the working page on the PC or the target?
The GM implementation for calibration requires additional RAM to be available either in the target system or residing as part of the tool interface for the wording page. The exact implementation may be MCU or tool specific. Additionally, the architecture that GM is using has the working page on the target (i.e. part of the development controller). This typically is a separate development RAM because there usually is not enough system RAM that can be allocated for development purposes.
8) Are there any impacts of delayed-lockstep on jtag and nexus operation of the processors?
On Freescale microcontrollers that support a lock-step processor, there is no impact to JTAG or Nexus operations. In the Freescale implementation, the lock-step core performs the exact same operations as the primary core that it is associated with. Both cores execute the same JTAG commands and the operations of both cores are compared. There is access only to the one JTAG output and trace output from the primary core. However, since the operations of both cores are being compared and monitored, any difference between the primary and lock-step core will be signaled.
9) What is the meaning of port replacement feature in class 2 nexus.
Port replacement is a mechanism that replaces the physical pins that are required for the debug port (Nexus pins, JTAG pins, etc.) with a mechanism for the tool to regenerate the signals that are lost because the debug port is being used. This does require an additional connection to the tool and the tool must be capable of decoding the port replacement messages to generate the signals that were lost for the debug interface. This typically requires that the signals be low-speed in nature.