Functions at a glance
- Limited emulation RAM - Support of Renesas RH850 overlay RAM
- 64-bit Integer support (limited to 32-bit value range)
- COM-API – Support of bus monitoring
- AUTOSAR – Support of multiplexed I-PDU monitoring for CAN/CAN FD
- AUTOSAR – End-to-end communication protection for CAN/CAN FD monitoring
- Show and edit alias names in hardware configuration
- Check database for overlapping parameters
- PRoF XCP flashing – New XCP_SET_TIMEOUT command
- Search in "Add hardware device" dialog
Limited emulation RAM - Support of Renesas RH850 overlay RAM
The Renesas RH850 microcontroller family supports multiple flash memory clusters. For calibration each cluster needs a specific handling of the assigned overlay RAM.
INCA supports the RH850 memory overlay mechanism to allow calibration for all flash clusters. INCA optimizes the usage of global and cluster specific overlay RAM.
64-bit Integer support (limited to 32-bit value range)
The new generations of ECU controllers support 64-bit registers. To allow high-performance data access, the 64-bit registers need to be read with one access. Normally data is less than 64 bits in size, so multiple data is stored in one 64-bit data package.
INCA now supports 64-bit Integer access to read/write it with one access. To separate the different information, bit masks with up to 32 active bits must be used. The implementation of a complete 64-bit support is planned for future Service Packs.
COM-API – Support of bus monitoring
For some bus monitoring applications it is useful to exchange the bus description file. INCA supports to add the bus description file to the INCA database using its API commands.
The following commands were introduced for reading a bus description:
The following commands were introduced for assigning a bus description to a monitoring device:
The following bus monitoring descriptions are supported:
- CAN DB for CAN, CAN FD, J1939
- AUTOSAR V4.1, 4.2, 4.3 for CAN, CAN FD, FlexRay
- Fibex V3.0,3.1 for FlexRay
- LDF V1.3, 2.3 for LIN
AUTOSAR – Support of multiplexed I-PDU monitoring for CAN/CAN FD
Signals defined in the static and dynamic segments of a multiplexed I-PDU can be measured in INCA using CAN/CAN FD monitoring. Multiplexed I-PDU is used at customer ECU communication in order to use the available bandwidth efficiently.
Note: This feature is not supported by ES590, ES591, ES690 and ES1222.
AUTOSAR – End-to-end communication protection for CAN/CAN FD monitoring
One of the several enhancements of AUTOSAR 4.x is the addition of end-to-end (E2E) communication protection. There are several defined E2E profiles, each of it implements a combination of E2E protection mechanisms, such as sequence counters, data IDs and cyclic redundancy checks (CRC).
INCA reads and interprets the values from the PDU part only. The following requirements are considered:
- INCA manages user data and PDU data for selected measurement signals
- all measurement signals of the E2E protection are visible in VSD and available for measurement and recording
- the "CRC", "Counter" and "Length" fields are shown as measurement signals in INCA to monitor the values of the E2E header.
Show and edit alias names in the hardware configuration
When working with a car in which more than one device of the same type is in use (for example, two ETAS XETKs), it is necessary to uniquely assign/identify hardware. In the described case, the serial number is of hardly any use as it does not indicate the function of the device. In order to easier identify the hardware devices, alias names can now be stored in the devices. The alias name can be used to match devices built into a car with devices in an INCA hardware configuration.
INCA displays the alias names in the:
- "Search for hardware" dialog
- "Hardware mapping" dialog
- "Hardware configuration" window
- "Assign project" dialog
For automatic hardware mapping, the INCA device name and the alias name must be identical. Users can achieve this by using a new "Use Alias as name" context menu entry.
Check database for overlapping parameters
If two parameters share the same memory, a calibration of one parameter influences the other. This is not always intended. Parameters often need multiple bytes to store the values. A simple check of different start addresses does not detect all overlaps.
INCA now supports a check that respects the address and the size of the parameter. The check can be started manually for INCA projects (A2L files). Overlapping parameters with different bitmasks are detected as well.
PRoF XCP flashing – New XCP_SET_TIMEOUT command
For XCP flashing, PRoF uses the XCP connection that has been established based on the XCP parameters of the A2L file. These parameters are optimized for the XCP measurement and calibration use cases but not for flashing.
During flashing, some actions have to be performed that take a long time to process, for example, erasing the ECU memory or checksum verification. If using the optimized low XCP timeouts t1 – t7 from the A2L file, the XCP communication could run into timeouts during flashing.
It is now possible to use different XCP timeout parameters for flashing using the new XCP_SET_TIMEOUT PRoF command. This new command allows to change the individual t1 – t7 timeouts during flashing and thus avoids to run into timeouts during flashing.
The new command is documented in the PRoF documentation.
Allow search in "Add hardware device" dialog
INCA offers a wide range of hardware devices. To easily find hardware the "Add hardware device" dialog offers a search functionality.