In the network management test, the outgoing time of the first frame of network management packets, that is, the network startup time, is tested. General requirements will specify the threshold time (TPowerWakeUp) for the first frame of network management packets, for example: 150ms, with a tolerance of 10%, that is, a maximum of 165ms.1ECU startup process
Let's first clarify where the 150ms will be spent. The ECU will go through the stages of hardware startup->Boot startup->Boot operation->App startup->App operation from being powered on to the stable operation of the program, as shown below:
HW Startup: This stage is completely determined by hardware characteristics, and there is no room for optimization at the software level. This stage includes VCC power supply (for example: KL15 is powered on), and then the 5V, 3.3V and 1.25V power management modules corresponding to the ECU are powered on. 5V is generally used for IO, 3.3V is generally used for Flash, and 1.25V is generally used for CPU core.
Bootloader Startup: This stage is generally the initialization of the Bootloader using peripheral resources, such as the initialization of IO, System Timer, CAN and other modules.
Bootloader running: At this stage, it will be judged whether the program needs to be updated. If there is no program to be updated, the Boot program will stay for a period of time, for example: 20ms, which is what we talked about earlier
Stay In Boot
function, which can be reviewed
UDS flashing: Do you really know how Application and Bootloader communicate?
Stay In Boot
Time consuming is unavoidable.
HW,OS,Application Startup: This stage includes the initialization of peripheral resources required by the application, the initialization of the OS, and the initialization of each software module.
hint: If the Boot program is security boot, it may take longer. Of course, the requirement will also specify the startup time of security boot.
TPowerWakeUp test steps
Turn off network emulation (the host computer does not simulate the sending of network management messages), and turn off the power supply;
Turn on the power supply (generally refers to the KL15 power-on), and trigger the DUT to communicate on the network segment (hard-wire wake-up or network wake-up). When the KL15 voltage reaches 6V as the starting time, the MCU is usually powered by 5V, and this moment is marked as T1;
Wait for the DUT to send the first frame message on this network segment, and record this moment as T2;
Check if (T2-T1) <>
Share an example of an engineering bug here: When testing TPowerWakeUp, in the absence of security boot, TPowerWakeUp is as high as 200ms, which is much greater than 150ms. The actual test TPowerWakeUp<165ms is enough, and 10% deviation should be considered.
problem solving entry point：
1. Delay caused by improper use of SPI rate
The transceiver corresponding to the CAN module uses the NXP TJA1145, which needs to control its mode switching through SPI. The baud rate used before the problem occurred was 100Kbps, by increasing the communication rate,Optimized for >30ms time. The rate of NXPTJA1145 is increased to 4Mbps. According to its user manual, it can be seen that the clock period of NXPTJA1145 in Normal/Standby mode can be configured as 4Mbps (1/250ns = 4000000Hz). If you consider Sleep Mode, at least 1Mbps can also be configured, which can also increase the communication rate by 10 times.
2. Modification of PORT Pin configuration parameters
Generally speaking, from the moment when the ECU is powered, that is, the VCC (12V) power supply, the VCC will be pulled to a stable state in an instant, which takes almost no time. And 5V, 3.3V, 1.25V generally at the same time, the voltage begins to climb, the time spent is not much different, generally in the order of several ms, that is, T1 time, such as about 3ms. The time spent by these voltages is a physical characteristic, and there is no room for optimization. However, the voltage value of PowerOnPin may be determined by the configuration, and the power supply time of the Pin can be modified by modifying the peripheral power supply chip. I did encounter such a design in the actual project. By configuring the peripheral chip configuration, the power supply time of PowerOnPin was reduced from a dozen ms to about 3ms, and the startup time of nearly 10ms was optimized, that is, the T2 time was optimized.
In summary, the points to think about are:
For peripheral devices that use SPI, first determine the maximum supported communication rate, and compare them horizontally to see if the communication rate can be improved where UART is used;
Device-specific configuration is design-time configuration.
Finally, let's talk about how these times are measured. This article inverts the IO level state at the target code position and uses an oscilloscope to measure it, so that you can know the time consumption of the code and function, and then optimize it in a targeted manner.
Reviewing Editor: Liu Qing