STMicroelectronics STEVAL-PDUBV1 User Manual

UM3594
User manual
Getting started with the STEVAL-PDUBV1 26-channel power distribution ECU
based on SPC58NG84E7 Chorus 6M MCU and STi2fuse devices
Introduction
In recent years, the power distribution unit (PDU) market has undergone significant transformations due to the increasing
adoption of electric vehicles (EVs). The number of supply rails in vehicles has grown, while the need to reduce vehicle
harnesses for improved battery efficiency has driven innovation in power distribution, which remains a critical function of the
electrical/electronic (E/E) architecture.
Automotive power distribution in EVs has two sections. The first one is dedicated to high-voltage power distribution, which
normally connects the main battery voltage to the traction motor, the OBC, the heather, the e-compressor, and the main DC-DC
converter. The second one is the low-voltage power distribution, which takes care of delivering the power from the output of the
main DC-DC to the various car loads through wire harnesses. In the current implementation, the low-voltage board-net is based
on a 12 V rail, but future developments call for a 48 V rail or mixed 12 V and 48 V rails.
The low-voltage board’s net topology is different depending on the architectural connection of the different ECUs inside the
vehicle: zones, domains, mixed. In a traditional approach, when replacing the “fuse box” inside the vehicle, the power
distribution is composed of a main primary board directly connected to the output of the high-voltage DC-DC via a power rail
switch board (PRS). This is the case with ST’s design of STEVAL-PDUBV1. Based on this architecture, the system is composed
of a primary distribution unit (PDU) having several channels for the different points of load in the car. To replace the physical
e‑fuses, the PDU channels have been protected with ST electronic e‑fuses able to self-regenerate and self-protect themselves.
Other architectures span from DC-DC output connected directly to the different zones, to zone connected in ring or daisy chain
and distribution in a hierarchical structure. Obviously, also mixed approaches are possible.
Having a primary PDU instead consolidates connections with loads and supplies in a single location within the vehicle.
Designed as an all-in-one unit to optimize space, it protects primary circuits (such as preheating, electric steering, and body
computers) and distributes DC-DC output power sourced from the main battery, auxiliary battery, engine, and/or regenerative
breaking.
The PDU is normally placed in non-accessible areas and it is integrated with zone control units. In software-defined vehicles
(SDVs), power distribution plays a pivotal role in ensuring continuous availability or fail-operational functionality, as outlined in
ISO26262.
Modern power distribution systems may consist of several blocks. These include the power rail switch unit (PRS), which
connects multiple power sources (such as the main battery and auxiliary battery), and the primary PDU, which directly accesses
PRS power sources and distributes power throughout the vehicle via multiple e‑fuses channels. Some channels directly supply
motors and loads, while others supply secondary or zonal power distribution units, such as the advanced driver-assistance
systems (ADAS) function distribution domain or the rear zone power distribution unit.
STEVAL-PDUBV1 is an automotive-intended power distribution system, designed for a maximum operating voltage of 28 V,
featuring the latest STi2Fuse generation of e‑fuses and P-channel companion chips for parking mode and low quiescent current
applications. All the devices on the board are automotive grade, including connectors and discrete parts. The board features two
independent power rails with separate inputs. Each rail consists of 13 output channels with different current carrying capabilities,
from 5 A to 200 A, utilizing STi2Fuse devices and F8 MOSFET technology.
The board also features the powerful ASIL-D SPC58NG84E7 Chorus 6M MCU, with 6 MB Flash memory, which can host large
applications and configuration parameters. The available communication interfaces are a CAN-FD channel, a 100BASET
automotive Ethernet channel, and a UART communication port to be used with an external UART to USB converter. The board
comes with basic operating firmware implementing a CAN message responder coupled with ISO14229 (UDS) standard used for
diagnostic purposes. Ethernet communication is available at hardware level, but reserved for future use at software level. Future
software extensions might include a complete GUI based on the UART port available on board.
UM3594 - Rev 1 - March 2026
For further information, contact your local STMicroelectronics sales office.
www.st.com
UM3594
Figure 1. Example of a vehicle power distribution system
Loads
ECU
Cooling fan
Secondary
power
distribution
unit
PDU
EPS
(Steering)
(STEVAL-PDUBV1)
Braking
HPC
ZCU
ECU
Secondary
power
distribution
unit
ECU
ZCU
ZCU
PRS
ZCU
Loads
ECU
Secondary
power
distribution
unit
Loads
Central
Computer(s)
Secondary
power
distribution
unit
Loads
Note:
The evaluation board described in this user manual is designed for R&D laboratory use only. It is not intended
for field use in vehicles. Moreover, it is not a reference design. Its purpose is evaluation and not production, as
stated in ours Terms of use.
Notice:
For dedicated assistance, submit a request through our online support portal at AutoDevKit Community.
UM3594 - Rev 1
page 2/98
UM3594
Safety information and on board protections
1
Safety information and on board protections
This evaluation board is designed for demonstration purposes only and shall not be used for any commercial
purpose without prior written authorization from ST. The evaluation board is designated for professionals only and
has to be used solely for research and development facilities for such purposes.
The technical data, as well as information concerning power supply conditions, must be taken from this user
manual and strictly observed. Careful handling is recommended.
The board should be installed, operated, serviced, and maintained only by qualified personnel, able to detect
possible hazards that may arise from parameterization, modifying parameter values and generally from
mechanical, electrical, or electronic equipment.
No responsibility is assumed by ST for any damage or malfunction of the board or user equipment when using
this board.
1.1
Reverse polarity
The board is protected against reverse polarity. However, we recommend connecting the VCCA and VCCB power
supply rails with care to avoid potential reverse polarity damage.
1.2
Short-to-ground
No known issues.
1.3
ISO pulses
The devices on STEVAL-PDUBV1 are protected against ISO pulses. However, ISO pulses have not been fully
tested. If you intend on performing any ISO pulse testing, we recommend consulting ST’s technical specialists.
1.4
ESD
The board is equipped with measures against ESD pulses. Communication lines are protected through
specialized ESD devices. However, normal ESD handling procedures are recommended.
1.5
STi2Fuse protection behind onboard high-side drivers
The STi2Fuse protection (ST’s proprietary I²t functionality) features an intelligent circuit breaking aimed at
protecting PCB traces, connectors and wire harness from overheating, with no impact on load transients like
inrush currents and capacitance charging. The I2t curve parameters can be individually set per each channel and
self-computed by the STi2Fuse devices without the need of MCU intervention.
The dissipated power can be limited to a safe level up to thermal shutdown intervention. That is configurable in
both latched-off mode or programmable time-limited auto-restart. The output current limitation protects the device
in case of overload. The device enters a fail-safe mode in case of communication loss with the microcontroller,
reset of digital memory, or watchdog monitoring time-out event. In fail-safe mode, the output can be directly
controlled by dedicated, assignable direct input pins. The channel high-side drivers are activated only by explicit
request coming from the MCU via the SPI bus (that is “STANDBY_NOT” control signal).
UM3594 - Rev 1
page 3/98
UM3594
Market availability
2
Market availability
2.1
STEVAL-PDUBV1 board hardware availability
The STEVAL-PDUBV1 board has a dedicated folder page on www.st.com. Browsing the tabs of the product folder
page, it is possible to download the data brief, this user manual, the bill of material (BOM), the schematics, and a
zip containing the Gerber files.
The board cannot be purchased from the ST online store, and it is not available through our online distributor
partners. If you are interested in ordering one or more copies of it, please contact our closest sales
representative.
The board has been produced using a customized process and stack-up able to accommodate the total
deliverable current and stable thermal behavior. The access of detailed information on the stack-up of the board
or the design files is limited. Should you be interested, please verify with our closest sales representative if you
qualify for it.
2.2
STEVAL-PDUBV1 software availability
The software is pre-burned on the STEVAL-PDUBV1 board, and the same flash memory image can be
downloaded from the product folder page of STSW-PDUB-UDS. The latest version of the software is always
available for download as all intermediate versions are overwritten with the newest one. In the same zip file, we
include the DBC file for the CAN messages.
The software source code access is limited. Should you be interested in receiving it, please verify with our closest
sales representative if you qualify for it.
Future software implementation is deployed, creating new dedicated software part numbers to discriminate
among the different implemented features, for example, for a GUI based version we might create a new part
number like STSW-PDUB-GUI.
UM3594 - Rev 1
page 4/98
UM3594
PDU-B application basic working modes
3
PDU-B application basic working modes
3.1
STEVAL-PDUBV1 input stage
As briefly mentioned in the introduction, STEVAL-PDUBV1 has two different input rails, namely VCCA and VCCB.
These rails are connected via a power rail switch board (PRS) to the 12 V output coming from the high-voltage
DC-DC connected with the battery pack and 12 V auxiliary power rail coming from the low-voltage battery.
In the normal operation of the vehicle, the main supply should come from the rail connected to the main battery
pack. The second rail is added for safety purposes. In case the first rail fails or generates overvoltage or
undervoltage conditions (ADCWT), the main rail (rail A in our case) is switched off and power is drawn from the
auxiliary battery via rail B to sustain vehicle operation to reach a safe stop state. Clearly, the energy availability
from the auxiliary battery is limited, therefore it can be only used for short-time maneuvers to properly halt the
vehicle.
The switch of the rail and the activation/deactivation of the related channels is not automatic in the board, but it is
an explicit operation carried out by the implemented software assuming that the loads are effectively connected to
both rails managed channels. To be fully ISO26262 complaint, it would be better if the rail switch were managed
by hardware and not by the software cyclic check.
At software level, the real-time operating system schedules a dedicated input monitoring process to detect failure
conditions and to record them in non-volatile memory (NVM) according to UDS diagnostic standards as an active
diagnostic trouble code (DTC). As long as supply is maintained via at least one of the rails, the DTC can be
enquired and cleared via the UDS protocol.
3.2
STEVAL-PDUBV1 Assembly mode
Assembly mode is a special STEVAL-PDUBV1 operating mode employed in the vehicle production line by the car
maker. To keep workers safe, the board must be activated according to a predefined power sequence. There is a
hard-coded table inside the software specifying the required status for each channel (for example, ON or OFF).
The check to enter this specific operation mode is done through the VCC_Ext connector, a dedicated supply
voltage ranging from 2.5 V to 11 V given in a specific STEVAL-PDUBV1 connector.
Note:
This external supply connector provides power only to the board logic ICs (PMIC, MCU, CAN, Ethernet).
Therefore, we require additional supply on the VCCA or VCCB power input rails to supply the power channels.
There are three channel outputs to be activated in this mode, namely OUT_A6, OUT_A3, and OUT_B3. There is
a delay of 100 ms between the activation of one channel and the following one. The power-on sequence and the
time of activation of each channel can be modified by customizing the internal hard-coded table in the software.
Once the channel turn-on process is completed, the fault LED blinks and there is an automatic feedback message
sent via CAN with the status ASSEMBLY DONE. In case of failure, the UDS becomes active for diagnostics. If the
result is successful, the system goes in Normal mode, and the VCC_Ext supply is disconnected.
3.3
STEVAL-PDUBV1 Normal mode
STEVAL-PDUBV1 Normal mode can be reached after terminating the Assembly mode or by directly powering up
at least one of the two rails.
When Normal mode is reached just after Assembly mode, the previous three activated channels remain ON.
Again, from the hard-coded table, the system retrieves and performs the configuration for the other channels on
the board, including, for example, the I2t point for each channel. The system now enables the CAN responder
where it is possible to send configuration or activation commands for the channels. In the meantime, the real-time
operating system activates the UDS manager process to respond to diagnostic requests via CAN.
A dedicated 10 ms scheduler process ensures that the CAN responder, the UDS responder, and the input rail
voltage monitor processes are properly interleaved in the core with the watchdog manager process.
This task provides cyclic feedback to the PMIC, to the standby companion chip (L99SP08), and to the e‑fuse ICs
to ensure that the on-board communication channel managed by the SPI protocol is active and that connection
with the MCU is still valid. If this feedback, that is, SPI message from the MCU, is missing or is not delivered in
the time-window defined in each datasheet, the hardware IC records a fault and transitions into a safe state
according to the IC internal state machine, for example switching off the channels.
UM3594 - Rev 1
page 5/98
UM3594
PDU-B application basic working modes
3.4
STEVAL-PDUBV1 Parking mode
There are several standby levels achievable with the device contained in STEVAL-PDUBV1.
We call Parking mode the status of the vehicle coming to a stop after Running mode (that is, driving). In modern
EVs, Parking mode shall have several sub-statuses where different loads are completely disconnected or reduced
to Standby mode. In our implementation, the signal of the key turn is simulated via a dedicated CAN message,
and the internal table defines the channels to switch off, the companion channels to switch on, and the auxiliary
channels that remain active all the time (for example, door latch control via remote key or LTE communication for
car data access via dedicated app).
To achieve advanced standby performances in our Parking mode implementation, the MCU is switched off after
all Parking mode settings are completed according to the internal table.
When the MCU is switched off, there shall be no more watchdog provided to the devices on board. Therefore, the
e‑fuse devices transition in Failsafe mode, but they continue to protect the wire harness and the connected loads
based on the i2t thresholds previously programmed.
It is important to notice that before entering Parking mode and switching itself off, the MCU has to perform
accurate checks on each channel current drain to verify that it is below the reactivation threshold (for all VNFx
devices) and VDS bypass saturation equal to zero (for the VNF1248F) to avoid entering in an unwanted loop of
continuous going in and out of Parking mode. If the MCU performed checks on the various channels do not lead
to a clear and unequivocal result, entering Parking mode shall be refused and the system shall remain in Normal
mode. This is to avoid potentially unstable system states.
Once Parking mode is entered, the main output channels are switched off through the STANDBYNOT pin) while
the coupled L99SP08 P-channels are turned on. The VNF1248F devices are not switched off, but set to Standby
mode as they have advanced standby capability.
As soon as the power demand is greater than the programmable threshold, the process is inverted. That means
rhat the eight (for each L99SP08 device) main output channels are turned on while the P-channels are switched
off. This behavior is applicable to any of the eight channels independently from the others. All high-side drivers
have an integrated smart fuse with a current threshold configurable via SPI to block the channel current drain at a
given level.
The total conditions to exit Parking mode are:
•
•
Current request increase on one of the channels sustained by L99SP08 P-channels.
Wake up event due to bus activity on CAN or Ethernet controller (not implemented in the current software).
•
Fault condition detected by one of the STi2Fuse devices and signaled with the activation of the
corresponding DIAG line. Typical fault conditions include, but are not limited to, shortcut, overcurrent, and
overtemperature.
External wake up input (activated through the CAN connector to implement the KL pin conditions).
•
3.5
Simple STEVAL-PDUBV1 usage
The board comes with pre-loaded firmware. Excluding the assembly mode as a special condition, once the input
power is provided on one of the two rails, the system starts. After boot-up, the system activates CAN
communication or signal an eventual fault by turning on the dedicated LED.
STEVAL-PDUBV1 features two supply rails, VCCA and VCCB. Their nominal operating values (without loads
connected) are 14 V at 0.3 A for both rails. For test purposes, both rails can be connected to the same power
supply, as shown in Figure 2.
UM3594 - Rev 1
page 6/98
UM3594
PDU-B application basic working modes
Figure 2. Basic STEVAL-PDUBV1 power-up
UM3594 - Rev 1
page 7/98
UM3594
PDU-B application basic working modes
3.5.1
LEDs available on STEVAL-PDUBV1
There are several LEDs on STEVAL-PDUBV1 which provide information about voltages and functions on the
board. Figure 3 shows the LED positions on the board, while Table 1 explains their functions.
Figure 3. LED positions on the board
Table 1. LED functions
UM3594 - Rev 1
LED #
Function
Color
LED 1
Fault
Red
When lit, it indicates a faulty software condition
LED 2
Test0
Orange
Used by the firmware to signal certain conditions
LED 3
VCCA
Green
When lit, it shows the presence of VCCA supply voltage
LED 4
VCCB
Green
When lit, it shows the presence of VCCB supply voltage
LED 5
+5 V
Green
When lit, it shows the presence of an internal PMIC 5 V
supply
LED 6
+3.3 V
Green
When lit, it shows the presence of an internal PMIC 3.3 V
supply
LED 7
3.3V_STB
Green
When lit, it shows the presence of an internal 3.3 V standby
supply
LED 8
UART Tx
Orange
Activity on UART Tx line, only when using the GUI
LED 9
UART Rx
Orange
Activity on UART Rx line, only when using the GUI
LED 10
Reset
Orange
Lit when the Reset signal is activated
Description
page 8/98
UM3594
PDU-B application basic working modes
In case of correct power-up with the previous configuration shown, the LEDs status should be as follows:
Table 2. LED status at startup
LED #
Function
Color
Description
LED 3
VCCA
Green
Supply voltage on VCCA
LED 4
VCCB
Green
Supply voltage on VCCB
LED 5
+5 V
Green
PMIC 5 V supply available
LED 6
+3.3 V
Green
PMIC 3.3 V supply available
LED 7
3.3V_STB
Green
Internal 3.3 V standby supply available
Figure 4. LEDs at board power-up
Obviously, the red Fault LEDs should remain off.
Once the system boot is completed, all operating system processes are active and the system completes the
channel configurations according to the internal hard-coded table.
The next step is to enter Listening mode on the CAN bus to receive CAN commands or UDS diagnostic enquiries.
Normally, we suggest connecting the STEVAL-PDUBV1 CAN port to the PC via one of the commercially available
dongles to be able to send CAN command sequences based on the available CAN DBC database file.
UM3594 - Rev 1
page 9/98
UM3594
PDU-B application basic working modes
3.5.2
STEVAL-PDUBV1 operating range
The nominal operating voltage of the STEVAL-PDUBV1 board is 14.0 V. According to the operating voltages for
STi2Fuse devices, the maximum operating voltage is 28 V.
Figure 5. STEVAL-PDUBV1 possible lab usage
UM3594 - Rev 1
page 10/98
UM3594
Hardwareoverview
4
Hardware overview
4.1
STEVAL-PDUBV1 conceptual functional block
The block diagram below shows the basic available channels of the STEVAL-PDUBV1 board. Each board
functionality has been highlighted by identifying the major blocks and connections.
Figure 6. STEVAL-PDUBV1 conceptual block diagram
UM3594 - Rev 1
page 11/98
UM3594
Hardwareoverview
4.2
STEVAL-PDUBV1 main hosted devices
The real STEVAL-PDUBV1 board appears as follows. The key supported devices and their respective location on
the board are highlighted in Figure 7.
Figure 7. STEVAL-PDUBV1 - main hosted devices
1. VNF1248F: high-side switch controller with intelligent fuse protection for 12 V, 24 V, and 48 V automotive
applications.
2. VNF9D1M5Q: 2-channel high-side driver with STi2Fuse protection for automotive power distribution
applications, featuring 27 A per channel.
3. VNF9Q20SF: 4 channel high-side driver with STi2Fuse protection for automotive power distribution
applications, featuring 5 A per channel.
4. VNF9D5SF: 2 channel high-side driver with STi2Fuse protection for automotive power distribution
applications, featuring 13 A per channel.
5. L99SP08: smart octal P-channel for ultralow current consumption in automotive systems, featuring 400 mA
per channel, able to interact with the high-side drivers with STi2Fuse. It is controlled by the MCU via SPI.
6. STL325N4LF8AG: automotive N-channel logic level 40 V, 0.75 mΩ max., 373 A STripFET F8 Power
MOSFET.
7. SPSB081: automotive power management IC with LIN and CAN-FD, which manages the wake-up for the
MCU, for example, following a parking mode to running mode application state transition.
8. SPSA068: PMIC with buck and precise voltage reference for MCU applications.
9. LDL40: 200 mA low dropout LDO.
UM3594 - Rev 1
page 12/98
UM3594
Hardwareoverview
10. SPC58NG84E7: 32-bit power architecture MCU for automotive general-purpose applications belonging to the
Chorus family, with 6 MB flash, ASIL-D.
4.3
STEVAL-PDUBV1 connector overview
STEVAL-PDUBV1 features two power input connectors for Power Rail A (VCCA) and Power Rail B (VCCB), a
GND connector, a VCC_EXT connector, five output connectors for Power Rail A, five output connectors for Power
Rail B, one low current connector for Power Rail A, and one low current connector for Power Rail B. In detail,
referring to Figure 8, the board features the following connectors:
1. Power input connector for Power Rail A (VCCA).
2. VCC_EXT connector.
3. GND connector.
4. Power input connector for Power Rail B (VCCB).
5. Output connectors for Power Rail A (from board top to bottom):
–
OUT_A1.
–
OUT_A2.
–
OUT_A3.
–
OUT_A4.
–
OUT_A5.
6. Output connectors for Power Rail B (from board top to bottom):
–
OUT_B1.
–
OUT_B2.
–
OUT_B3.
–
OUT_B4.
–
OUT_B5.
7. Low current power connector for Power Rail A.
8. Low current power connector for Power Rail B.
UM3594 - Rev 1
page 13/98
UM3594
Hardwareoverview
Figure 8. STEVAL-PDUBV1 - connector overview
1 2 3 4
8
5
4.3.1
6
7
VCCA and VCCB power input connectors
The input connectors for Power Rail A (VCCA) and Power Rail B (VCCB) are implemented with an M8 screw bolt.
4.3.2
GND connector
The GND uses an M6 screw bolt connector. This is the return path for the logic supply only.
4.3.3
VCC_EXT connector
If this connector is powered at startup, the assembly dedicated startup is triggered. For further details, please see
Section 3.2. This connector supplies the board logic only. The main supply comes from the input rails.
4.3.4
Power output connectors
The board outputs are split into two separate power rails, Rail A and Rail B. Each rail can be used independently.
VCCA is the input for Rail A, while VCCB is the input for Rail B. All output connectors use M6 screw bolts, except
OUT_A1 and OUT_B1, which use M8 screw bolts.
The output channels for Rail A and Rail B have different current carrying capabilities, as shown in the tables
below.
Table 3. Power Rail A current capabilities
UM3594 - Rev 1
Channel
Max. current
Device
OUT_A1
200 A
VNF1248F + 8 MOSFETs
OUT_A2
150 A
VNF1248F + 5 MOSFETs
OUT_A3
100 A
VNF1248F + 3 MOSFETs
page 14/98
UM3594
Hardwareoverview
Channel
Max. current
Device
OUT_A4
100 A
VNF1248F + 3 MOSFETs
OUT_A5
100 A
VNF1248F + 3 MOSFETs
OUT_A6
27 A
OUT_A7
27 A
OUT_A8
27 A
OUT_A9
27 A
OUT_A10
5A
OUT_A11
5A
OUT_A12
5A
OUT_A13
5A
VNF9D1M5Q connected to L99SP08 Nr.1
VNF9D1M5Q connected to L99SP08 Nr.1
VNF9Q20SF connected to L99SP08 Nr.1
Table 4. Power Rail B current capabilities
UM3594 - Rev 1
Channel
Max. current
Device
OUT_B1
200 A
VNF1248F + 8 MOSFETs
OUT_B2
150 A
VNF1248F + 5 MOSFETs
OUT_B3
100 A
VNF1248F + 3 MOSFETs
OUT_B4
100 A
VNF1248F + 3 MOSFETs
OUT_B5
100 A
VNF1248F + 3 MOSFETs
OUT_B6
27 A
OUT_B7
27 A
OUT_B8
27 A
OUT_B9
27 A
OUT_B10
10 A
OUT_B11
10 A
OUT_B12
10 A
OUT_B13
10 A
VNF9D1M5Q connected to L99SP08 Nr.2
VNF9D1M5Q connected to L99SP08 Nr.2
VNF9Q20SF connected to L99SP08 Nr.2
page 15/98
UM3594
Hardwareoverview
4.3.5
Low current connectors for 5 A and 10 A
For 5 A and 10 A currents, two G&H 8-pin, 4.8 mm blade connectors are used, as shown in Figure 9 and
Figure 10.
Figure 9. G&H 8-pin connector (top view)
Figure 10. G&H 8-pin connector (side view)
The following figures show the detailed output connections for Power Rail A and B using these G&H 8-pin
connectors.
Figure 11. Power Rail A 8-pin connector
UM3594 - Rev 1
page 16/98
UM3594
Hardwareoverview
Figure 12. Power Rail A 8-pin connector layout
Table 5. Power Rail A 8-pin connector channel details
Channel
Pin
Current
OUT_A6
1
max. 27 A
OUT_A7
3
max. 27 A
OUT_A8
5
max. 27 A
OUT_A9
7
max. 27 A
OUT_A10
2
max. 5 A
OUT_A11
4
max. 5 A
OUT_A12
6
max. 5 A
OUT_A13
8
max. 5 A
Device
VNF9D1M5Q
VNF9D1M5Q
Supply rail
VCCA
VCCA
VCCA
VCCA
VCCA
VNF9Q20SF
VCCA
VCCA
VCCA
Figure 13. Power Rail B 8-pin connector
UM3594 - Rev 1
page 17/98
UM3594
Hardwareoverview
Figure 14. Power Rail B 8-pin connector layout
Note:
In the figures above, the
symbol indicates pin 1 marking.
Table 6. Power Rail B 8-pin connector channel details
4.3.6
Channel
Pin
Current
OUT_B6
1
max. 27 A
OUT_B7
3
max. 27 A
OUT_B8
5
max. 27 A
OUT_B9
7
max. 27 A
OUT_B10
2
max. 10 A
OUT_B11
4
max. 10 A
OUT_B12
6
max. 10 A
OUT_B13
8
max. 10A
Device
VNF9D1M5Q
VNF9D1M5Q
VNF9D5SF
VNF9D5SF
Supply rail
VCCA
VCCA
VCCA
VCCA
VCCA
VCCA
VCCA
VCCA
CAN communication connector
CAN communication is the current main interaction interface with STEVAL-PDUBV1. It is used for CAN
commands controlling the devices and channels, but also to support the UDS diagnostic protocol. In the zip file
containing the firmware image, we provide a CAN database file .dbc containing all supported CAN messages to
be used with common market available debugging tools.
The CAN physical layer is embedded in the on-board SPSB081 PMIC. This device can wake the MCU and the
entire system up when traffic is detected on the CAN bus.
STEVAL-PDUBV1 is provided with an external wake up signal directly connected to pin 4 of the CAN connector.
This wake up signal is tied to SPSB081 PMIC and can wake up both the PMIC system and the MCU by simply
applying a positive slope signal with a maximum voltage of 14 V to the pin. To generate an external wake up
signal, the VCC supply voltage is also available on this connector.
Figure 15. CAN connector (front view)
UM3594 - Rev 1
page 18/98
UM3594
Hardwareoverview
Table 7. Pin description of the CAN standard 9-pin DSUB male connector
4.3.7
Pin
Signal
1
NC
2
CAN L
3
GND
4
External wake up
5
GND
6
NC
7
CAN H
8
NC
9
VCC
Ethernet 100BASETX connector
The Ethernet connection uses a TE Connectivity 1-Port 90° MATEnet header with coding B.
Figure 16. Ethernet connector
4.3.8
UART connector
STEVAL-PDUBV1 is provided with a UART interface to be used for the interaction via a graphical user interface
(GUI) to be provided with one of the future releases of the board firmware.
Figure 17 shows the positions of communication connectors on the board.
UM3594 - Rev 1
page 19/98
UM3594
Hardwareoverview
Figure 17. Ethernet, CAN, UART communication connectors on STEVAL-PDUBV1
UM3594 - Rev 1
page 20/98
UM3594
Hardwareoverview
4.4
Main devices’ description
4.4.1
Board’s main microcontroller
The main core of STEVAL-PDUBV1 is the ASIL-D SPC58NG84E7 microcontroller, SPC58 Chorus 6M. It is a
32‑bit e200z4 triple core based on Power® architecture. Each core frequency is 180 MHz, it supports variable
length encoding (VLE) and has a floating point unit and end to end error correction. One CPU channel is in
lockstep. The MCU is provided with a very large on-chip flash memory of 6582 MB (6144 KB code flash + 256 KB
data flash) and 608 KB on-chip general-purpose SRAM, in addition to the 160 KB core local data RAM.
Additionally, 182 KB are dedicated to the hardware secure module (HSM). The MCU is very rich in terms of
communication interfaces, including 18 LINFlexD modules, 10 DSPI modules, 8 CAN-FD support, a dual-channel
FlexRay controller, and two independent Ethernet controllers up to 100 Mbps. A boot assist flash (BAF) is present
to support factory programming using a serial bootloader through the asynchronous CAN or LIN/UART.
Figure 18. Internal block diagram from SPC58NG84E7
Note:
For further information, see datasheet DS11758.
4.4.1.1
MCU usage for STEVAL-PDUBV1
Out of the rich peripheral set present in SPC58NG84E7, only a subset is actually used in STEVAL-PDUBV1. The
main role is played by the DSPI modules, which are used throughout the board to communicate with the
STi2Fuses, standby companion chips, and PMICs.
the SPI protocol uses a master-slave architecture, where one main device (master) manages communication
among peripheral devices (slaves) by driving clock and chip select (CS) signals. In our case, for a given SPI
group, we can drive different slaves connected through CSx signals from the master. The chip select is used as
an hardware address to point-out the slave unit intended for the message. Having two separate data lines, SDO
and SDI, the protocol is able to receive and transmit bit-by-bit data at the same time.
UM3594 - Rev 1
page 21/98
UM3594
Hardwareoverview
As previously mentioned, another communication port present on the STEVAL-PDUBV1 board is the UART. The
UART protocol is used for asynchronous serial communication, allowing configuration of data formats and
transmission speeds. It sends data bits one by one, from least to most significant (LSB), framed by start and stop
bits so that precise timing is handled by the communication channel. The UART protocol employs a Tx pin for
data transmission, while a Rx pin is used for data reception.
The remaining following peripherals are employed in the STEVAL-PDUBV1 board:
•
•
•
•
•
4.4.1.2
Enhanced modular input/output system (EMIOS): a microcontroller peripheral typically used to generate
pulse width modulation (PWM).
Analog-digital converter (ADC): a microcontroller peripheral for analog-to-digital signal conversion, such as
time-varying voltage.
Interrupt request (IRQ): a peripheral that enables the microcontroller to receive external interrupts from
separate units.
WAKE UP: a microcontroller peripheral that allows the MCU to wake up from a suspended or low-power
state.
General purpose input/output (GPIO): a microcontroller peripheral that allows the MCU to receive or
generate binary high and low signals (representing logic 1 and 0) to and from external devices. For
example, they control the STi2Fuse direct input, emergency pins used in severe fault conditions.
MCU power management in STEVAL-PDUBV1
The MCU power management in STEVAL-PDUBV1 is managed by three different devices: two PMICs and an
LDO. The board has a dedicated supply capacity for external 3.3 V loads. The whole system runs a 3.3 V.
Figure 19. Basic power blocks interaction in STEVAL-PDUBV1
As shown in Figure 19, the logic supply comes from two different PMICs, the first one being SPSB081. This IC is
taking the controller role because of its ability to manage wake up from several sources:
•
•
•
UM3594 - Rev 1
Internal wake up capability based on CAN bus activity due to the CAN embedded physical layer.
External wake up capability based on the Ethernet physical layer.
External wake up capability coming from the L99SP08 companion IC when the current request threshold is
overcome, or from the STi2Fuses in case of a severe failure. The STi2Fuses and the P-Channel companion
feature DIAG pins, being open drain, they are all tied together to the SPSB081 wake up pin.
page 22/98
UM3594
Hardwareoverview
Once SPSB081 starts, or restarts after a wake-up request, it wakes the second PMIC (SPSA068) up, which in
turn provides the 3.3 V supply to the microcontroller (SPC58 Chorus 6M). It is important to highlight that SPSA068
has a greater current capability due to its switching regulator, compared to the internal SPSB081 LDOs, therefore
it is able to supply the microcontroller. To properly function, SPSA068 requires OTP pre-programming before
being used on STEVAL-PDUBV1. Both mentioned PMIC devices are programmed and controlled via SPI by the
microcontroller, and the watchdog signal required for ASIL compliance is also provided by the MCU via SPI.
The third power device present on STEVAL-PDUBV1 is LDL40 LDO, a regulator able to deliver 200 mA while
offering high noise immunity. The LDO has a dedicated protection circuit against polarity reversal, that is, incorrect
connection of the 12 V main power supply. LDL40 LDO is used for the following purposes:
•
•
To feed a precise reference voltage in the case of the MCU ADCs.
To supply a dedicated circuit converting the DIAG pins (3.3 V) to a level compatible with the SPSB081
VBat.
In addition, to protect the board from a surge of inrush current from the power source to potential multiple
connected loads, two e‑fuses have been added to the STEVAL-PDUBV1 board design.
Following there is a brief description of the three above-mentioned power devices:
•
•
•
4.4.2
SPSB081: power management system IC providing power management functionality, including various
standby modes to minimize power consumption with programmable local and remote wake-up capability,
as well as LIN (only for SPSB0815-TR and SPSB0813-TR) and CAN FD physical communication layers.
The device has one low-drop voltage regulator to supply the system microcontroller and one voltage
tracker to supply external peripheral loads such as sensors. V1 is available with a fixed rail (5 V or 3.3 V)
and V1 overvoltage detection and protection solution, while V2 is a tracker voltage regulator of V1,
programmable by SPI with 5 V or 3.3 V. Moreover, the device features four high-side drivers to supply
LEDs and sensors. All outputs are short-circuit (SC) protected and implement open-load diagnosis. The ST
standard SPI interface allows control and diagnosis of the device. For further information, see DS14048.
SPSA068: buck voltage regulator with a precise voltage reference for MCU applications. All the regulators
have internal power switches. The low-power mode allows the operation under light-load conditions,
reducing the quiescent current down to 50 μA typ. An internal programmable memory allows to select the
main device parameters like output voltages and switching frequencies. An SPI interface can be used for
diagnostics, programming, monitoring, and external window watchdogs. The device offers a set of features
to support applications that need to fulfill functional safety requirements as defined by automotive safety
integrity level. The pre SMPS buck regulator is adjustable via NVM to 5.0 V, 3.3 V, 1.2 V at 0.5 A and 1.0 A
load current, 0.4 / 2.4 MHz. An external resistive divider can regulate a voltage between 5 V and 1.2 V. The
precise voltage reference (1%) is adjustable via NVM too to 5.0 V, 3.3 V, 1.2 V at 20 mA load current. For
further information, see DB5483.
LDL40: high accuracy voltage regulator designed to be directly connected to a car battery in automotive
applications. The extended input voltage up to 40 V makes the device able to support a load dump
transient, typical in automotive systems. Ultralow quiescent current at light-load increases the battery
operation lifetime in always-on-standby systems. An enable logic control function puts LDL40 in shutdown
mode, allowing a total current consumption lower than 0.3 µA. Thermal protection is also included. The
device is available in a very small footprint DFN package with wettable flanks, allowing maximum space
saving on PCB. The output voltage tolerance is ±2.5% over the full temperature range, and 0.5% at 25°C.
For further information, see DS14146.
STi2Fuse devices
The STi2Fuse series includes automotive smart high-side switch controllers, monolithic drivers, and system-inpackage devices with controllers and power MOSFETs in the same package. These resettable electronic fuses
feature a fully programmable I²t protection mechanism that ensures exceptional system flexibility and active
power management.
Designed to maintain vehicle power network stability and protect wires, traces, and connectors, STi2Fuse devices
are essential for autonomous protection, predictive maintenance, and enhanced resilience. These features
collectively contribute to a significant reduction in harness weight.
UM3594 - Rev 1
page 23/98
UM3594
Hardwareoverview
STi2Fuse are electronic fuses (e‑fuses), that is, advanced electronic protection devices designed to protect
circuits and components from overcurrent and overvoltage conditions. Unlike traditional fuses, which are onetime-use components that physically break to interrupt the circuit, e‑fuses are integrated circuits that can
electronically monitor and control the current flow, allowing reset and reuse. When an overload occurs, these
devices limit the output current to a safe value defined by the user. If the overload persists, the devices enter open
state, disconnecting the load from the power supply. The current overload limit can be programmed through an
external resistor. At power-up, e‑fuses manage the increase of the output voltage in a smooth and controlled
manner. This careful ramp-up helps prevent inrush current surges from the power source to the load, thereby
protecting the power supply from overloading.
This feature is particularly beneficial in setups where one power supply feeds multiple loads. The startup time can
be adjusted by selecting a different soft start capacitor. Devices can operate in either latch-off or auto-retry modes
following a fault. In latch-off mode, the e‑fuse permanently breaks the current flow until a manual reset is
performed. This means that, even if the fault is recovered, an external action (for example, a manual reset) is
required. In this mode, the e‑fuse can be reset through an enable pin. Instead, in auto-retry mode, the e‑fuse
temporarily interrupts the current flow and automatically attempts to restore it until the fault is recovered. e‑fuses
communicate the fault status to the system controller through a fault pin. The main advantages of e‑fuses are:
•
•
•
•
•
•
Resettable output.
No need for a replacement after a fault.
Auto-retry or latch-off modes for reset.
Reduced cable length.
Improved fuse time-current characteristics.
Less variability.
STEVAL-PDUBV1 hosts four types of high-side drivers based on ST proprietary Sti2Fuse technology:
•
•
•
•
4.4.2.1
UM3594 - Rev 1
VNF9Q20SF: it features 4 outputs, 20 mΩ per output, currents up to 5 A, and integrated MOSFETs. It is
protected against voltage transients on the VCC pin. Programming, control, and diagnostics are enabled by
the SPI bus. Digital current sense feedback for each channel is provided through an integrated 10-bit ADC.
Dedicated trimming bits allow to adjust the ADC reference current. The outputs are controllable via both
SPI and 2-OTP assignable direct inputs. Real-time diagnostics are available through the SPI bus (open
load, output short to VCC, overtemperature, power limitation, or latch off). The device detects open-load in
off-state conditions. The device enters a Fail-safe mode in case of communication loss with the
microcontroller, reset of digital memory, or watchdog monitoring time-out event. In Fail-safe mode, the
outputs are controlled by assignable direct inputs. For further information, see DS13909.
VNF9D5SF: it features 2 outputs, 5 mΩ per output, currents up to 10 A and integrated MOSFETs. It is
protected against voltage transients on the VCC pin. Programming, control, and diagnostics are enabled by
the SPI bus. Digital current sense feedback for each channel is provided through an integrated 10-bit ADC.
Dedicated trimming bits allow to adjust the ADC reference current. The outputs are controllable via both
SPI and 2-OTP assignable direct inputs. Real-time diagnostics are available through the SPI bus (open
load, output short to VCC, overtemperature, power limitation, or latch off). The device detects open-load in
off-state conditions. The device enters a Fail-safe mode in case of communication loss with the
microcontroller, reset of digital memory, or watchdog monitoring time-out event. In Fail-safe mode, the
outputs are controlled by assignable direct inputs. For further information, see DS13946 .
VNF9D1M5Q: it features 2 outputs, 1.5 mΩ per output, currents up to 27 A and integrated MOSFETs. It
operates via SPI bus.
VNF1248F: it is an advanced controller for a Power MOSFET in high-side configuration, designed for the
implementation of an intelligent high-side switch for 12 V, 24 V, and 48 V automotive applications. It is
controlled via the SPI interface and it provides protection and diagnostics to the system. It features a very
low standby current, and it is used in STEVAL-PDUBV1 for currents from 100 A to 200 A in combination
with up to eight MOSFETs belonging to ST F8 technology. The chosen part number is the
STL325N4LF8AG, an N-channel logic level 40 V STripFET F8 Power MOSFET featuring an enhanced
trench gate structure. This technology ensures very low on-state resistance while reducing internal
capacitances and gate charge for faster and more efficient switching. For further information on the device
check DS14109, while for the Power MOSFET see DS13900.
Shunt resistors employed for VNF1248F devices
The different VNF1248F managed power channels use different values of shunt resistors to limit power
dissipation. The value of the shunt resistor must be considered when calculating Inom or overcurrent values for the
device settings. Table 8 lists the shunt resistor values per channel.
page 24/98
UM3594
Hardwareoverview
Table 8. Shunt resistor value per channel
Channels
Current
Shunt resistor
Number of MOSFETs
OUT_A1,OUT_B1
200 A
100 µΩ
8 MOSFETs
OUT_A2, OUT_B2
150 A
200 µΩ
5 MOSFETs
OUT_A3, OUT_B3
100 A
200 µΩ
3 MOSFETs
OUT_A4, OUT_B4
100 A
200 µΩ
3 MOSFETs
OUT_A5, OUT_B5
100 A
200 µΩ
3 MOSFETs
The above-mentioned shunt resistors could be optimized to reduce thermal dissipation due to high current flow.
Based on the above defined shunts, we can compute the VNF1248F overcurrent threshold values. The formula to
be used is the following:
Inom A = Vtℎresℎolds * 1
Rsense
Gain
where the Gain =
1 .
1000
Table 9. Overcurrent threshold per shunt value
*Channel limit in terms of current carrying capability
UM3594 - Rev 1
VNF1248F overcurrent threshold [mV]
Inom [A] for Rshunt = 200 µΩ
Inom [A] for Rshunt = 100 µΩ
6
30
60.00
7.2
36
72.00
8.7
43.5
87.00
10.4
52
104.00
11.8
59
118.00
13
65
130.00
13.8
69
138.00
14.8
74
148.00
15.8
79
158.00
16.8
84
168.00
17.9
89.5
179.00
19.1
95.5
191.00
20.4
102
204.00*
21.8
109
218.00
23.3
116.5
233.00
24.8
124
248.00
26.5
132.5
265.00
28.2
141
282.00
30.1
150.5*
301.00
32.2
161
322.00
34.3
171.5
343.00
36.6
183
366.00
39.1
195.5
391.00
41.7
208.5
417.00
page 25/98
UM3594
Hardwareoverview
VNF1248F overcurrent threshold [mV]
Inom [A] for Rshunt = 200 µΩ
Inom [A] for Rshunt = 100 µΩ
44.5
222.5
445.00
47.5
237.5
475.00
50.6
253
506.00
54
270
540.00
61.3
306.5
613.00
69.5
347.5
695.00
78.8
394
788.00
Warning:
4.4.3
Please, strictly observe the values indicated in the tables above to prevent board damage or
any personal injury resulting from board failure.
L99SP08 standby companion chip with smart P-channels
L99SP08 is a standby companion chip with eight smart P-channels to be coupled with STi2Fuse devices to
improve standby performance. The P-channels are activated to sustain the load present in the e‑fuses output by
providing a lower current capability while the main e‑fuses are switched off in standby condition. For each
P‑channel, if L99SP08 senses a higher current request from the load, it requests the system to turn it on to
perform the swap between P-channel and e‑fuse. The DIAG pin present in the L99SP08 device can be used as a
wake up signal for the system because it is connected to the main PMIC. In turn, the PMIC wakes up the MCU
and, when the MCU wakes up, it performs the check on the channels before switching the P-channel off and the
main e‑fuse on. As all DIAG pins are connected, it is the MCU who discriminates on which channel to perform the
operations.
UM3594 - Rev 1
page 26/98
UM3594
Hardware test results
5
Hardware test results
5.1
Test setup environment
In this section, we present the general equipment and the schematic block of the test setup. The test conditions
are Vcc = 14 V and temperature = 23 ± 5 ºC.
•
Electronic loads:
•
–
Keysight 6705 power analyzer 400 W (ID: 66-006862).
–
Keysight 6705 power analyzer 400 W (ID: 66-007630).
–
EA PSB 9080-240 3U (ID: 66-006710).
–
EA PSB 9080-240 3U (ID: 66-006809).
Power supply:
•
–
EA PSB 10080-510 3U (ID: 66-007898).
Oscilloscope:
•
–
Keysight MSOX4054 (ID: 66-006878).
Current probes:
–
–
–
Keysight N2781B (ID: 66-006205).
Keysight N2781B (ID: 66-006486).
Keysight N2780B (ID: 66-007414).
Figure 20. Test setup schematic block
5.2
Test of sleep, wake up, startup time
For this test, the indicator LEDs were removed to reduce Parking mode current consumption to the minimum.
•
•
•
•
•
UM3594 - Rev 1
Parking mode with no active outputs: 945 µA.
Normal mode with no active outputs: from 230 to 250 mA.
Normal mode with all outputs active: 270 mA.
Time from wake up impulse to first edge on TEST LED: 61.6 ms.
Time from wake up impulse to 5 V regulator startup (ability to transmit over CAN): 117.5 ms.
page 27/98
UM3594
Hardware test results
5.3
Test of I2t functionality
These tests are intended to verify the functionality of the wiring harness protection function (STi2Fuse) during
normal operation of the PDU unit.
•
VN1248F, channel OUT_A2: this channel is designed for a nominal current of 150 A. This corresponds to
OVC = 30.1 mV. Two Tnom settings were used (1 s, 101 s). 200 A of load current were applied via an
electronic load.
Figure 21. VNF1248F STi2Fuse regular functionality test - tnom = 1s
Figure 22. VNF1248F STi2Fuse regular functionality test - tnom = 101 s
UM3594 - Rev 1
page 28/98
UM3594
Hardware test results
•
VNF9D1M5Q, channel OUT_A6: this channel was designed for a nominal current of 30 A. The nominal
current is set to Inom = 27 A. Two Tnom settings were used (1 s, 86 s). A load current of 40 A was applied to
the output using an electronic load.
Figure 23. VNF9D1M5Q STi2Fuse regular functionality test - tnom = 1 s
Figure 24. VNF9D1M5Q STi2Fuse regular functionality test - tnom = 86 s
UM3594 - Rev 1
page 29/98
UM3594
Hardware test results
•
VNF9D5SF, channel OUT_B13: This channel is designed for a nominal current of 10 A. The nominal
current was set to Inom = 10 A. Two Tnom settings were used (1 s, 86 s). A load current of 15 A was applied
at the output using an electronic load.
Figure 25. VNF9D5SF STi2Fuse regular functionality test - tnom = 1 s
Figure 26. VNF9D5SF STi2Fuse regular functionality test - tnom = 86 s
UM3594 - Rev 1
page 30/98
UM3594
Hardware test results
Table 10. Latch-off times
VNF1248F (OUTA2)
VNF9D1M5Q (OUTA6)
VNF9D5SF (OUTB13)
tnom= 1s
tnom= 101 s
tnom= 1 s
tnom= 86 s
tnom= 1 s
tnom= 86 s
Meas. 1
62.36 ms
6.33 s
32.62 ms
2.77 s
32.11 ms
2.75 s
Meas. 2
62.36 ms
6.33 s
32.62 ms
2.77 s
32.08 ms
2.75 s
Meas. 3
62.33 ms
6.33 s
32.60 ms
2.77 s
32.11 ms
2.75 s
Expected
62.5 ms
6.25 s
31.25 ms
2.69 s
31.25 ms
2.69 s
All measured latch-off times are within the expected ranges.
5.4
Cascaded channels test
One of the tests intended to verify the functionality of STi2Fuse products is the test in cascade configuration. One
example is reported in the following section.
5.4.1
VNF1248F → VNF1248F + VNF1248F
In this case, both the ASIL load and the QM load were supplied by channels using the VNF1248F device.
•
Upstream e‑fuse (OUTA1):
–
–
•
•
OVC = 20.4 mV (204 A).
tnom = 300 s.
–
HSC = 40 mV (400 A).
ASIL load (OUTB2):
–
–
OVC = 30.1 mV (150 A).
tnom = 300 s.
–
–
HSC = 60.6 mV (303 A).
Iload = 100 A.
QM load (OUTB3):
–
–
OVC = 50.6 mV (101 A).
tnom = 300 s.
–
–
HSC = 105.6 mV (211 A).
Iload = 75 A.
During this test, an overload is caused on the QM load (OUTB3) by increasing the load current from 75 A to
120 A. This caused overcurrent to be reported by both the upstream e‑fuse (OUTA1) and the QM e‑fuse (OUTB3).
Since the thresholds were properly configured, only the downstream e‑fuse latched off and the supply to the ASIL
load was not interrupted. A 1 m connection cable was employed.
UM3594 - Rev 1
page 31/98
UM3594
Hardware test results
Figure 27. Soft overload event on cascaded e‑fuse
(1 of 2)
Figure 28. Soft overload event on cascaded e‑fuse
(2 of 2)
In the next step, we test a short circuit in QM load. The short was realized by a mechanical switch connected in
parallel to the load. The short circuit was interrupted by the downstream e‑fuse while the current to the ASIL load
was not interrupted. The test is performed with a 1 m connection wire.
Figure 29. Hard short circuit event on cascaded
e‑fuse (1 of 2)
5.5
Figure 30. Hard short circuit event on cascaded
e‑fuse (2 of 2)
Thermal design evaluation
This test evaluates the thermal design of the PDU module under high current loads. Test results were recorded
with a thermal imaging camera. The channels were loaded with their maximum rated current one at a time. The
current was run through the outputs until the temperatures on the PDU reached equilibrium (from 10 to 15
minutes). Sufficient time was left between measurements to let the board cool down. For VNF1248F channels,
the temperature of MOSFETs was also measured with a thermocouple.
UM3594 - Rev 1
page 32/98
UM3594
Hardware test results
UM3594 - Rev 1
Figure 31. VNF1248F @ 200 A (OUTA1) thermal
image, TFET = 57.5°C (1 of 2)
Figure 32. VNF1248F @ 200 A (OUTA1) thermal
image, TFET = 57.5°C (2 of 2)
Figure 33. VNF1248F @ 150 A (OUTA2) thermal
image, TFET = 58.5°C (1 of 2)
Figure 34. VNF1248F @ 150 A (OUTA2) thermal
image, TFET = 58.5°C (2 of 2)
Figure 35. VNF1248F @ 100 A (OUTA4) thermal
image, TFET = 58°C (1 of 2)
Figure 36. VNF1248F @ 100 A (OUTA4) thermal
image, TFET = 58°C (2 of 2)
page 33/98
UM3594
Hardware test results
UM3594 - Rev 1
Figure 37. VNF9D1M5Q @ 27 A (OUTA6) thermal
image (1 of 2)
Figure 38. VNF9D1M5Q @ 27 A (OUTA6) thermal
image (2 of 2)
Figure 39. VNF9Q20SF @ 5 A (OUTA13) thermal
image (1 of 2)
Figure 40. VNF9Q20SF @ 5 A (OUTA13) thermal
image (2 of 2)
Figure 41. VNF9D5SF @ 10 A (OUTB13) thermal
image (1 of 2)
Figure 42. VNF9D5SF @ 10 A (OUTB13) thermal
image (2 of 2)
page 34/98
UM3594
Hardware test results
5.6
VNF1248F bypass switch operation test
In this test, the correct operation of the low current P-channel bypass switch integrated in VNF1248F was
evaluated. There are three different configurations of the VNF1248F present on the PDU. The test was performed
by applying a slow ramp up of the load current (from 50 mA to 2 A in 250 ms).
Figure 43. VNF1248F bypass switch test - OUTA1.
Zoomed version on the right (1 of 2)
Figure 44. VNF1248F bypass switch test - OUTA1.
Zoomed version on the right (2 of 2)
Figure 45. VNF1248F bypass switch test - OUTA1. Current step
UM3594 - Rev 1
page 35/98
UM3594
Hardware test results
5.7
P-channel companion chip test
These tests are meant to show the functionality of the L99SP08 P-channel companion chip together with the
integrated STi2Fuse devices. The output of the companion chip was activated with a constant current load of
50 mA (electronic load). Then the current load was changed to 2 A and the reaction of the companion chip and
the connected STi2Fuse device was recorded. For each test, the high-power switch was activated, and the Pchannel bypass deactivated.
Figure 46. VNF9D1M5Q: P-channel companion chip
activating hybrid STi2Fuse device
UM3594 - Rev 1
Figure 47. VNF9D5SF: P-channel companion chip
activating monolithic STi2Fuse device
page 36/98
UM3594
Software description
6
Software description
A dedicated software stack has been built to support the evaluation of STEVAL-PDUBV1. The software is at
engineering level only, dedicated to lab and bench evaluation.
Important:
The software is NOT SUITABLE for production, NOR for testing in a real running vehicle.
The firmware for the power distribution unit (PDU) is designed with a strict two-layers architecture
•
Driver layer: it is responsible for all direct hardware access and device-specific logic. It implements the
drivers for all the hardware devices used in the system, including:
–
–
–
–
•
6.1
VNF family e‑fuse devices (for example, VNF1248F, VNF9D1M5Q, VNF9D5SF, and VNF9Q20SF).
PMICs (SPSA068 and SPSB081).
L99SP08 e‑fuse companion device.
SPC58 hardware abstraction layer (HAL), that is, all MCU peripherals and protocols are
implemented, and simplified APIs, namely low-level drivers, are provided to the upper layers for
implementation. The peripherals involved include ADC, CAN, GPIO, PWM, timers (ST), EEPROM,
etc.
Service layer: it includes all tasks running on FreeRTOS real-time operating system (that is, a dedicated
version ported by ST for SPC58 microcontrollers). The application logic tasks are part of this layer,
interleaved with other service layer tasks. For implementation simplicity, there is no execution level ID
difference between service and application tasks. The other service layer tasks are diagnostics, task
management, intermodule communication, and system supervision and monitoring.
These tasks use the driver layer APIs to interact with the hardware. Therefore, they never access specific
IC registers or hardware peripherals directly. The layered software stack ensures an abstraction from lower
to upper layer. This translates in customization and porting high flexibility as far as the layer interface is
duly respected.
STEVAL-PDUBV1 firmware basic startup steps
The firmware entry point at code level is the ‘main.c’ file. We can derive the basic initial steps performed by the
firmware from this file:
•
•
•
6.2
Hardware and driver initialization: through the componentsInit() function, all peripherals and low-level
drivers (driver layer) are initialized and configured.
Interrupt enablement: the irqIsrEnable() function enables interrupt handling, which is essential for system
interactions.
Service layer initialization: the PDUB_init() function is the main entry point for the application logic and the
heart of the system scheduling strategy.
Driver layer
The driver layer is the foundation of the STEVAL-PDUBV1 firmware architecture, providing the essential
abstraction between the hardware (MCU and peripherals) and the application logic implemented in the service
layer. It encapsulates all hardware-specific details and exposes standardized APIs to the upper layers, ensuring
modularity, portability, and maintainability.
Based on the layered firmware architecture, the driver layer handles all hardware-specific operations. Therefore,
the service layer can focus on application logic and system behavior only.
The software stack structure also ensures easy maintenance: when there are updates at IC level (for example, a
new or improved e‑fuse device or MCU), only the driver layer is directly impacted, while the service layer and the
application logic remain unaffected.
Another key point is that all low-level error handling, protocol compliance checks, and timings are managed within
the drivers, ensuring reliable operation for the upper layer.
6.2.1
Driver layer implementation
The driver layer consists of a collection of drivers (that is, component driver). Each driver is dedicated to a specific
smart IC present on the STEVAL-PDUBV1 board. All the implemented drivers are designed with a three-level
abstraction stack, ensuring that the service layer can interact with the hardware in a device-independent,
maintainable, and robust way. In detail, the three-layer stack consists of:
UM3594 - Rev 1
page 37/98
UM3594
Software description
1. Manager layer (top of driver layer): it implements high-level, device-oriented functions such as channel control,
device state management, and NVM access without considering how data is physically transmitted to the
device. The manager layer simply calls a function to "set a bit" or "write a register," and expects the lower
layers to handle the details.
2. High-level driver layer: it bridges the gap between device-level operations and hardware access. In fact, this
layer manages the construction of SPI packets, GPIO pin control, and the sequencing of hardware actions
required to implement the manager layer requests. The high-level driver does not directly access MCU
registers. Instead, it uses the low-level driver APIs for all hardware-related operations.
3. Low-level driver layer (AutoDevKit generated): it provides the direct interface to the MCU hardware peripherals
(SPI, GPIO, etc.). These drivers are typically auto-generated by AutoDevKit Studio and are tightly coupled
with the specific MCU and board configuration. They are responsible for register-level access, timing, and
protocol compliance.
An example of the implemented three-layer stack for some L99SP08 features is shown below:
1. Manager layer functions:
–
L99SP08_ch_setOUTCtrl(): it sets the output state of a specific channel.
–
L99SP08_dev_FailSafe2Standby(): it moves the device from FailSafe to Standby mode.
–
L99SP08_wdg_trig(): it triggers the watchdog finite state machine (FSM).
2. High-level driver layer functions:
–
L99SP08_spi_init(), L99SP08_spi_readReg(), L99SP08_spi_writeReg(): they handle SPI initialization
and register access (read/write) for L99SP08.
–
L99SP08_gpio_set(), L99SP08_gpio_get(): they control and read device-specific GPIOs (for example,
chip select, DIAG pins).
3. Low-Level driver layer (AutoDevKit generated) functions:
–
–
spi_lld_start(), spi_lld_stop(), spi_lld_exchange(): they directly access the MCU SPI peripheral.
pal_lld_setpad(), pal_lld_clearpad(), pal_lld_readpad(): they directly access the MCU GPIOs.
Figure 48. Stack for L99SP08 in driver layer
SERVICE LAYER
e.g.
Move from Normal to Standby from
ParkChecker Task
e.g.
Turn on CHx via SPI from
eFuseCTRL task
e.g.
Trigger Watchdog from WDG task
e.g.
Read NVM content
L99SP08 managers
L99SP08 CHANNEL
L99SP08 FSM
L99SP08
L99SP08 Register Map
Attributes:
Register address
Register field
Methods:
L99SP08_ch_setOUTCtrl
L99SP08_ch_setDIENCtrl
L99SP08_ch_setIThreshold
L99SP08_ch_getTSD
…
Methods:
L99SP08_wdg_trig
e.g.
Toggle wdtb bit and
write SPI CR1 with
address 0x01
e.g.
Get SPIDriver and SPIConfig
allocated for L99SP08
Methods:
L99SP08_spi_init
L99SP08_spi_deInit
L99SP08_spi_writeReg
L99SP08_spi_readReg
L99SP08_spi_readInfo
L99SP08 High Level Driver
L99SP08 GPIO
e.g.
Toggle CSN
Methods:
L99SP08_gpio_set
L99SP08_gpio_get
e.g. SPI init driver and configuration, SPI
exchange and SPI deinit driver
SPI
Methods:
spi_lld_start
spi_lld_stop
spi_lld_exchange
Attributes:
Configuration (e.g.
INOM-TNOM)
Methods:
L99SP08_nvm_directRead
L99SP08_nvm_directWrite
…
e.g. set en bit to 0 and gostby to
1 and write CR3 with address
0x03
L99SP08 SPI
Attributes:
L99SP08 SPIDriver
L99SP08 SPIConfig
L99SP08 NVM
L99SP08
Dev Config
Methods:
L99SP08_dev_FailSafe2Standby
L99SP08_dev_FailSafe2Normal
L99SP08_dev_Standby2Normal
…
L99SP08_dev_getVccOVsts
…
e.g. set outCtrlx bit
and write CR3 with
address 0x03
L99SP08 SPI Config
MCU
L99SP08 DEVICE
e.g. Set CSN LOW, wait SPI
transmit, Set CSN HIGH
L99SP08 GPIO Config
Attributes:
L99SP08 pin map
e.g.
Get PinMap allocated
For L99SP08
GPIO
Methods:
pal_lld_setpad
pal_lld_clearpad
pal_lld_readpad
pal_lld_togglepad
SPC58 Low Level Driver
UM3594 - Rev 1
page 38/98
UM3594
Software description
Figure 49 shows a complete function-nesting call from a task running in the service layer to the activation of the
MCU peripherals. For this example, we consider the operation to turn L99SP08 channel 0 on. The result of the
operation (success or error) is returned to the service layer, which can then update system status, log the event,
or notify other modules. This interaction model shows that the service layer can control and monitor all hardware
resources in a device-independent way, while the driver layer ensures safe, robust, and efficient access to the
underlying MCU and e‑fuse devices.
Figure 49. Nested function calls from service layer to MCU peripheral for L99SP08 channel 0 activation
6.3
Service layer
The service layer consists of the following task collection running on the FreeRTOS operating system:
•
•
•
•
•
•
•
•
•
PDU_mng: it serves as the central coordinator of the service layer in the PDU firmware.
EFUSE_mng: it is responsible for configuring, controlling, and monitoring all e‑fuse channels.
PMIC_mng: it manages all onboard PMIC ICs.
COMM_mng: it manages all communication operations of STEVAL-PDUBV1.
ADCWDT_mng: it is responsible for input rails monitoring.
ASS_mng: it is responsible for the configuration of the e‑fuses while in Assembly mode.
PARK_mng: it manages the transition of the system into Parking mode.
ERR_mng: it detects, stores, and reports all errors.
UDS_mng: it implements a simplified version of the ISO14229 diagnostics standard.
Figure 50. Service layer key components
PDU
Manager
E-Fuse
Manager
PMIC
Manager
Communication
Manager
Input rails
Monitoring
Assembly Mode
Manager
Parking Mode
Manager
Error
Handler
UDS
Manager
Service Layer
UM3594 - Rev 1
page 39/98
UM3594
Software description
6.3.1
PDUB manager task PDUB_mng
The PDUB_mng module serves as the central coordinator of the service layer in the firmware. Its main
responsibilities are to initialize all application-level services, configure and start the periodic scheduling
mechanism, and provide the main entry point for the application logic after hardware and driver initialization.
As seen in the basic startup section, the PDUB_init() function is the last to be invoked. The key role is to
sequentially initialize all the service layer tasks by invoking their respective functions:
•
•
•
•
•
•
•
•
ASS_sev_initTask().
PMIC_sev_initTask().
ADCWDT_sev_initTask().
EFUSE_sev_initTask().
COMM_sev_initTask().
PARK_sev_initTask().
ERR_sev_initTask().
UDS_sev_initTask().
Each routine creates a dedicated FreeRTOS task and allocates the necessary synchronization of resources
(semaphores, queues, etc.). The periodic activation of these tasks is not managed by using the native FreeRTOS
scheduling primitives (such as vTaskDelay or vTaskDelayUntil). For this purpose, instead, the firmware leverages
a hardware timer-based dispatcher, based on a hardware timer configured to generate periodic interrupts.
Every time it is invoked (that is, every 10 msec), the interrupt handler (callback) of this timer, named
PDUB_stm10_clbk(), increments a global counter. This global counter value is in turn used to activate tasks
according to their required specific intervals (for example, every 10 ms, 40 ms, or 100 ms) by releasing
semaphores or sending notifications. Each task remains blocked, waiting for its semaphore/notification, and is
executed only when explicitly activated by the dispatcher.
This approach is among the best industrial practices in various time-critical applications like automotive, railway,
and medical fields, where safety and predictability are essential requirements. It reinforces temporal determinism
by having task activation uniquely controlled by the hardware timer, thus ensuring that periodic operations always
occur at the same time, with no jitter accumulation. It also supports proper task synchronization, particularly
during critical operations such as ADC sampling and logging. Centralized control facilitates verification, validation,
and temporal certification of the system, thus reducing risk of race conditions, deadlocks, or starvation.
While FreeRTOS native scheduling (using vTaskDelay or vTaskDelayUntil) is more flexible and easier to
implement, it does not ensure the same level of determinism and synchronization between tasks. With tasks of
different priorities or variable computing loads, delays (jitters) can accumulate, which is unacceptable in safetycritical systems.
6.3.2
eFuse manager task (eFUSE_mng)
The eFuse module is a central component of the firmware, responsible for the configuration, control, monitoring,
and diagnostics of all e‑fuse channels in the system. It provides a unified interface for managing multiple e‑fuse
devices, ensuring safe power distribution, protection against electrical faults, and support for advanced
diagnostics. They key features include:
•
•
•
•
•
UM3594 - Rev 1
Channel control: it enables or disables individual e‑fuse channels based on system logic or external
commands.
Parameter monitoring: it continuously monitors voltage, current, and temperature for each channel,
providing real-time protection and diagnostics.
Fault detection and handling: it detects overcurrent, overtemperature, undervoltage, and other fault
conditions and executes appropriate recovery and/or protection actions.
Configuration management: it initializes and configures all e‑fuse devices at startup according to
predefined parameters and safety thresholds.
Advanced diagnostics: it supports a wide range of diagnostic and status queries, including support for UDS
diagnostic services.
page 40/98
UM3594
Software description
6.3.2.1
Asynchronous queue usage in the eFuse manager task
All interactions with the eFuse module are performed using asynchronous message queues. There are two
queues: one for requests, and one for responses. Service layer modules like COMM, UDS, PARK, or diagnostic
communicate with the eFuse module by placing structured request messages into the dedicated request queue.
Each message specifies the operation to be performed (for example, enable/disable a channel, read voltage/
current/temperature, enter standby, perform diagnostics) and includes all necessary parameters. The eFuse
module extracts and processes the request queue and, after processing a request, it places the corresponding
response message into a response queue. The requesting module retrieves the result, either by waiting for the
response or by polling the queue.
The eFuse module includes a dedicated FreeRTOS task (EFUSECtrlTask) that continuously monitors the request
queue, processes incoming requests in a thread-safe manner, interacts with the appropriate hardware drivers,
and posts responses to the response queue.
This implementation ensures thread safety and decoupling between modules, enables non-blocking, responsive
operations, supports scalability and easy extension with robust error handling and diagnostics.
A typical usage pattern is shown in Figure 51. The requesting task fills out a request structure with the desired
operation and parameters. This request is added to the eFuse request queue. The eFuse control task
(EFUSECtrlTask) processes the request, interacts with the hardware drivers, and places the result in the
response queue, while the requesting task waits for response retrieval.
Figure 51. Example of channel enablement request
6.3.2.2
UM3594 - Rev 1
Channel abstraction in the eFuse manager task
Each logical e‑fuse channel is represented by an enum type (EFUSE_sev_channel_t) mapped internally to the
specific device and hardware channel. For example, EFUSE_OUTA6 might correspond to channel 0 of L99SP08,
while EFUSE_OUTA1 might correspond to VNF1248F. This mapping is handled in the implementation of
functions like EFUSE_sev_setOutput(), and EFUSE_sev_getVoltage() by using switch/case statements or
configuration tables. With this abstraction, the rest of the system can refer to channels in a device-independent
way. The eFuse module handles all the logic to determine which driver function to call for each channel.
Therefore, when adding new devices or changing hardware mappings, changes are required only within the
eFuse module, leaving the rest of the applications unchanged.
page 41/98
UM3594
Software description
6.3.2.3
eFuse module implemented functions
The main functions implemented in the eFuse module are listed below, grouped by purpose.
Figure 52. eFuse module functions
The following figure lists the functions dedicated to monitoring and diagnostics.
Figure 53. eFuse module diagnostics and monitoring functions
6.3.2.4
eFuse module interaction with other modules
The eFuse module main interactions with other modules in the service layer are the following ones:
•
•
•
•
UM3594 - Rev 1
COMM: it receives and processes commands from the communication module (for example, set output, get
status).
UDS: it provides diagnostic data and supports UDS service requests for e‑fuse channels.
PARK: it executes standby or shutdown procedures upon request.
ERR: it reports fault conditions and supports error logging and recovery.
page 42/98
UM3594
Software description
6.3.2.5
e‑fuse device configuration
The configuration of all e‑fuse devices and their channels is managed through dedicated configuration structures,
as defined in the EFUSE_sev_cfg.h file and referenced in the EFUSE_sev_mng.h file. This section explains the
meaning and usage of each parameter, and how to configure automatic/manual recovery mapping between
RAILA and RAILB channels.
Table 11. Device-dependent channel parameters
Device
Field
Type
L99SP08
L99SP08_ch_ithr0..7
L99SP08_ch_ithr_t
Description
Nominal current threshold for each
channel (0-7)
It sets the current limit for protection
L99SP08
L99SP08_ch_ccm0..7
L99SP08_ch_sts_t
Continuous current mode (CCM) status
for each channel (0-7)
Enables/disables CCM mode
VNF1248F
VNF1248F_t_nom
VNF1248F_t_nom_t
VNF1248F
VNF1248F_cs_uv_retry
VNF1248F_cs_uv_retry_t
VNF1248F
UM3594 - Rev 1
Nominal time: maximum allowed
overload time before shutdown
Undervoltage retry count: number of
retries after undervoltage detection
VNF1248F_ccm_pwm_ton_m VNF1248F_ccm_pwm_ton_m
PWM ton multiplier for CCM mode
f
f_t
VNF1248F
VNF1248F_ccm_vout_thr
VNF1248F_ccm_vout_thr_t
Output voltage threshold for CCM
mode
VNF1248F
VNF1248F_cs_uv_th
VNF1248F_cs_uv_thr_t
Undervoltage threshold: minimum
allowed voltage
VNF1248F
VNF1248F_ccm_pwm_sc_t_
nb
VNF1248F_ccm_pwm_sc_t_
nb_t
PWM short-circuit retry count
VNF1248F
VNF1248F_ccm_timeout
VNF1248F_ccm_timeout_t
CCM timeout: maximum time CCM can
be active
VNF1248F
VNF1248F_ccm_pwm_sc_t
VNF1248F_ccm_pwm_sc_t_t PWM short-circuit time
VNF1248F
VNF1248F_ccm_pwm_ton
VNF1248F_ccm_pwm_ton_t
PWM ton duration in CCM mode
VNF1248F
VNF1248F_ccm_pwm_t
VNF1248F_ccm_pwm_t_t
PWM period in CCM mode
VNF1248F
VNF1248F_vds_thr
VNF1248F_vds_thr_t
Drain-source voltage threshold
(MOSFET protection)
VNF1248F
VNF1248F_ovc_thr
VNF1248F_ovc_thr_t
Overcurrent threshold: maximum
allowed current
VNF1248F
VNF1248F_hsht_thr
VNF1248F_hsht_thr_t
High-side temperature threshold
(thermal protection)
VNF1248F
VNF1248F_ntc_thr
VNF1248F_ntc_thr_t
NTC threshold: for thermal protection
using the NTC sensor
VNF1248F
VNF1248F_bypass_sts
VNF1248F_bypass_sts_t
Bypass status: enables/disables
bypass mode
VNF1248F
VNF1248F_ccm_sts
VNF1248F_ccm_sts_t
CCM status: enables/disables CCM
mode
VNF1248F
EFUSE_sev_cfg_sts
EFUSE_sev_cfg_sts_t
Configuration status: indicates if the
configuration is valid
VNF1248F
VNF1248F_iLimOff
Float
LCC current threshold: below this
value, the channel is considered off
VNF9D1M5Q
VNF9D1M5Q_inom0_level
VNF9D1M5Q_inom_level_t
Nominal current for channel 0
VNF9D1M5Q
VNF9D1M5Q_inom1_level
VNF9D1M5Q_inom_level_t
Nominal current for channel 1
VNF9D1M5Q
VNF9D1M5Q_ipeak0_level
VNF9D1M5Q_ipeak_level_t
Peak current for channel 0
page 43/98
UM3594
Software description
Device
Field
Type
Description
VNF9D1M5Q
VNF9D1M5Q_ipeak1_level
VNF9D1M5Q_ipeak_level_t
Peak current for channel 1
VNF9D1M5Q
VNF9D1M5Q_tnom0_level
VNF9D1M5Q_tnom_level_t
Nominal time for channel 0
VNF9D1M5Q
VNF9D1M5Q_tnom1_level
VNF9D1M5Q_tnom_level_t
Nominal time for channel 1
VNF9D1M5Q
VNF9D1M5Q_dev_tempTh
VNF9D1M5Q_dev_tempTh_t
Device temperature threshold
VNF9D1M5Q
EFUSE_sev_cfg_sts
EFUSE_sev_cfg_sts_t
VNF9D1M5Q
VNF9D1M5Q_iLimOff0
Float
LCC current threshold for channel 0
VNF9D1M5Q
VNF9D1M5Q_iLimOff1
Float
LCC current threshold for channel 1
VNF9D5SF
VNF9D5SF_ch_inom0
VNF9D5SF_ch_inom_t
Nominal current for channel 0
VNF9D5SF
VNF9D5SF_ch_inom1
VNF9D5SF_ch_inom_t
Nominal current for channel 1
VNF9D5SF
VNF9D5SF_ch_tnom0
VNF9D5SF_ch_tnom_t
Nominal time for channel 0
VNF9D5SF
VNF9D5SF_ch_tnom1
VNF9D5SF_ch_tnom_t
Nominal time for channel 1
VNF9D5SF
EFUSE_sev_cfg_sts
EFUSE_sev_cfg_sts_t
Configuration status
VNF9D5SF
VNF9D5SF_iLimOff0
Float
LCC current threshold for channel 0
VNF9D5SF
VNF9D5SF_iLimOff1
Float
LCC current threshold for channel 1
VNF9D5SF
VNF9D5SF_ch_ishutoff0
Shut-off time for channel 0: time after
VNF9D5SF_ch_ishutOffThr_t which the channel is turned off in case
of fault
VNF9D5SF
VNF9D5SF_ch_ishutoff1
VNF9D5SF_ch_ishutOffThr_t Shut-off time for channel 1
VNF9D5SF
VNF9D5SF_ch_imlLatch0
VNF9D5SF_ch_imlLatch_t
Auto-restart for channel 0: enables/
disables automatic restart after fault
VNF9D5SF
VNF9D5SF_ch_imlLatch1
VNF9D5SF_ch_imlLatch_t
Auto-restart for channel 1
VNF9Q20SF
VNF9Q20SF_ch_inom0..3
VNF9Q20SF_ch_inom_t
Nominal current for each channel (0-3)
VNF9Q20SF
VNF9Q20SF_ch_tnom0..3
VNF9Q20SF_ch_tnom_t
Nominal time for each channel (0-3)
VNF9Q20SF
EFUSE_sev_cfg_sts
EFUSE_sev_cfg_sts_t
Configuration status
VNF9Q20SF
VNF9Q20SF_iLimOff0..3
Float
VNF9Q20SF
VNF9D5SF_ch_ishutoff0..3
VNF9Q20SF_ch_ishutOffThr_
Shutoff time for each channel (0-3)
t
VNF9Q20SF
VNF9Q20SF_ch_imlLatch0..3
VNF9Q20SF_ch_imlLatch_t
Configuration status
LCC current threshold for each channel
(0-3)
Auto-restart for each channel (0-3)
On top of all above specific parameters, there are two global parameters:
•
•
6.3.2.6
EFUSE_CURRENT_TH: It is of type float. It represents the current threshold (in Amperes) below which a
channel is considered off (used for standby and safety checks).
EFUSE_VOLTAGE_TH: It is of type float. It represents the voltage threshold (in Volts) for standby and
protection of logic.
Rail A to Rail B channel mapping for recovery
The mapping between Rail A and Rail B channels for recovery purposes is managed by the structure:
typedef struct{
EFUSE_sev_channel_t EFUSE_sev_channelRAILA;
EFUSE_sev_channel_t EFUSE_sev_channelRAILB;
} EFUSE_RecoveryRail_conf_t;
EFUSE_sev_channelRAILA represents the logic channels on Rail A (for example, EFUSE_OUTA6), while
EFUSE_sev_channelRAILB are the corresponding channels on Rail B to be used for recovery (for example,
EFUSE_OUTB6). If the channel value is set to EFUSE_OUT_NOTMAPPED, no automatic recovery is performed
for that channel.
UM3594 - Rev 1
page 44/98
UM3594
Software description
Regarding configuration, to enable automatic recovery (switched recovery), map each Rail A channel to a RAILB
channel in the configuration array, while for manual recovery, set the Rail B mapping to
EFUSE_OUT_NOTMAPPED.
During execution, if a voltage fault is detected on Rail A (for example, by ADCWDT), the firmware can
automatically disable the affected Rail A channel and enable the mapped Rail B channel (if configured). If no
mapping is present, the user or an external system must manually command the activation of Rail B channels.
e‑fuse channel transition from Active to Standby mode
6.3.2.7
The following steps show how to safely transition all e‑fuse devices and channels into Standby mode, ensuring
the system is in a safe, low-power state before shutdown or during parking.
Step 1.
Checks for active loads and faults. It iterates over all relevant channels (for example, EFUSE_OUTA6
to EFUSE_OUTA13 for Rail A, EFUSE_OUTB6 to EFUSE_OUTB13 for Rail B). For each channel, it
checks if the channel is enabled (DIENSR) and, if so, reads the current. If any channel has a current
above a defined threshold (EFUSE_CURRENT_TH), the function returns an error, preventing unsafe
standby.
Step 2.
Checks for device faults. For each L99SP08 device and channel, it checks for VDSMAX or TSD
(thermal shutdown) faults. If any such fault is present, it returns an error.
Step 3.
Handling VNF1248F devices. For each VNF1248F device, if the output is active, it sets the bypass
control as configured. It checks if the bypass is active and, if so, verifies the bypass' saturation status. If
any bypass saturation is detected, it returns an error.
Step 4.
Device transitions to standby. For L99SP08 devices, it calls L99SP08_dev_Normal2Standby() to enter
standby mode. For VNF1248F devices, it calls VNF1248F_dev_Unlocked2Standby() to enter standby
mode. Finally, it calls EFUSE_sev_disable() to set the standby pins for the system.
Step 5.
Return: If all checks pass and all devices are transitioned successfully, it returns EFUSE_OK.
Note:
6.3.3
This function is comprehensive and defensive: it does not allow Standby mode if any unsafe condition
is detected on any of the available devices (L99SP08, VNF1248F, etc.). This behavior is fundamental
to avoid entering standby in a potentially critical condition.
PMIC_mng of the service layer
The PMIC module is a key component of the PDU firmware, responsible for the configuration, control, monitoring,
and diagnostics of all power management ICs (PMICs) in the system. It provides a unified interface for managing
multiple PMIC devices (such as SPSA068 and SPSB081), ensuring safe power sequencing, voltage regulation,
and support for advanced diagnostics and low-power modes. The key implemented functions include:
•
•
•
•
Power mode control: it commands each PMIC device to enter standby, low-power, or active modes,
supporting safe shutdown, wake up, and energy management.
Diagnostic queries: it retrieves status and error flags (overvoltage, undervoltage, watchdog, BIST,
power‑up, ground loss, thermal warning, etc.) from each PMIC.
Configuration management: it initializes and configures all PMIC devices at startup according to predefined
parameters and safety thresholds (for example, voltage regulator settings and wake up sources).
Advanced diagnostics: it supports a wide range of diagnostic and status queries, including support for UDS
diagnostic services and error logging.
All interactions with the PMIC module are performed using asynchronous message queues:
•
•
Request queue: other service layer modules, such as PARK, UDS, COMM, or diagnostics, communicate
with the PMIC module by placing structured request messages into a dedicated request queue. Each
message specifies the operation to be performed (for example, enter standby, get overvoltage status,
configure wake up sources) and includes all necessary parameters.
Response queue: after processing a request, the PMIC module places the corresponding response
message into a response queue. The requesting module retrieves the result, either by waiting for the
response or by polling the queue.
The PMIC module includes a dedicated FreeRTOS task (PMICCtrlTask) that continuously monitors the request
queue, processes incoming requests in a thread-safe manner, interacts with the appropriate hardware drivers,
and posts responses to the response queue. This ensures thread safety and decoupling between modules; it
enables non-blocking responsive operations and remains open for scalability and easy extension. The following
code snippet shows an example:
UM3594 - Rev 1
page 45/98
UM3594
Software description
Figure 54. Example of communication with PMIC module
In the code shown in the previous figure, the requesting task fills out a request structure with the desired
operation and parameters. The request is added to the PMIC request queue. The PMIC control task
(PMICCtrlTask) processes the request, interacts with the hardware drivers, and places the result in the response
queue where the requesting task waits for and retrieves the response.
Each supported PMIC device (for example, SPSA068, SPSB081) is abstracted behind a unified API. Operations
are identified by an enum (PMIC_sev_id_t), and the control task uses the switch/case logic to call the appropriate
driver function for the selected device and operation. The key benefit is that the rest of the system can request
power management or diagnostics without knowing which PMIC device is present. This also facilitates support for
new PMICs or new operations.
Typical interactions with the PMIC include:
•
•
•
•
PARK: it requests standby or shutdown operations for safe system power-down.
UDS: it requests diagnostic information for UDS services.
COMM: it sends and receives PMIC-related messages over CAN or UART.
ERR: it may be queried for error status or to support error logging and recovery.
The following figure lists the functions implemented for the PMIC module.
Figure 55. PMIC module functions
The detailed code behavior below shows the series of operations required to transition all PMIC devices into
standby or low-power mode, ensuring the system is in a safe, low-power state before shutdown or during parking:
UM3594 - Rev 1
page 46/98
UM3594
Software description
1. Receives a standby request: the control task receives a request (for example,
PMIC_SEV_VBATSTANDBY_SPSB081) from the request queue.
2. Calls the device driver: it invokes the appropriate driver function, such as
AEK_POW_SPSB081_Force_VBAT_StandBy(SPSB081_DEV0), to command the PMIC to enter standby
mode.
3. Handles device state: it might update the internal state or perform additional configuration to ensure that the
device is in the correct mode.
4. Operation result: Places a response in the response queue, indicating success or failure.
As shown, the function is comprehensive and defensive: it does not allow standby if any unsafe condition is
detected.
6.3.4
COMM_mng of the service layer
The COMM module is a fundamental component of the PDU firmware, responsible for managing all
communication between STEVAL-PDUBV1 and the external devices or systems. It acts as the communication
gateway, ensuring reliable message exchange, command dispatching, and support for diagnostics and control.
While the current implementation supports the CAN protocol, the module is designed with a high level of
abstraction, making it straightforward to extend support to other communication protocols such as UART or
Ethernet in the future.
The key implemented functions include:
•
•
•
•
•
•
External communication gateway: it manages all inbound and outbound communications between the
board and external devices (for example, vehicle ECUs, diagnostic tools, or other controllers).
Message transmission and reception: it handles the message sending and receiving over all supported
communication protocols (currently CAN, in future support for UART and Ethernet).
Command dispatching: it decodes incoming messages and dispatches commands or requests to the
appropriate service layer modules (for example, eFuse, PMIC, PARK, and UDS).
Asynchronous communication: it uses queues and FreeRTOS tasks to manage asynchronous, nonblocking message handling.
Protocol abstraction: it provides a device and protocol-agnostic interface for higher-level modules,
abstracting the details of CAN, UART, and Ethernet communication.
Diagnostics and status reporting: it supports the transmission of diagnostic information, status updates, and
error notifications to external systems.
All interactions with the COMM module are performed using asynchronous message queues:
•
•
Transmit queue (Tx): service layer modules (such as eFuse, PMIC, UDS, or diagnostics) send messages
to be externally transmitted by placing them into the transmit queue. Each message includes the protocol,
destination, and payload.
Receive queue (Rx): incoming messages from external systems are placed into the receive queue by the
communication drivers or interrupt callbacks. The COMM module processes these messages and
dispatches them to the appropriate internal modules.
The COMM module includes dedicated FreeRTOS tasks for transmission (COMMTxTask) and reception
(COMMRxTask). These tasks continuously monitor their respective queues, handle message encoding/decoding,
and interact with the hardware drivers. This implementation ensures thread safety and decoupling between
communication and application logic. The communication operations are non-blocking and responsive, thus
supporting scalability and easy extension to new protocols or message types. This is also beneficial for robust
error handling and diagnostics.
The COMM module abstracts all supported communication protocols behind a unified API. Each message is
identified by a type (COMM_sev_msgType_t) and an ID (COMM_sev_msgID_t). It includes all necessary data
and task handles for response notification. The rest of the system can send and receive messages without
knowing the details of the underlying protocol, and adding support for new protocols or message types requires
changes only within the COMM module. Typical interactions with the COMM module include:
•
•
•
•
•
eFuse: it receives and dispatches commands to enable/disable channels, read parameters, or perform
diagnostics.
PMIC: it sends and receives power management and diagnostic messages.
UDS: it handles UDS diagnostic requests and responses.
PARK: it receives parking/shutdown commands and forwards them as needed.
ERR: it transmits error notifications and diagnostic information.
The following figure lists the functions implemented for the COMM module.
UM3594 - Rev 1
page 47/98
UM3594
Software description
Figure 56. COMM module functions
6.3.4.1
CAN protocol usage
The STEVAL-PDUBV1 CAN interface is designed for a bus high (BH) network at 125 kbps with the following key
parameters:
•
•
•
•
•
•
Bitrate: 125 kbps (set in the CAN driver configuration).
Bus type: high-speed CAN (bus high).
Termination: 120 Ω resistors at both ends of the bus.
Physical layer: standard ISO 11898-2 transceiver.
Bus length: up to 500 m (typical for 125 kbps, but please verify your application).
Node addressing: message routing is based on CAN IDs as defined in the DBC file.
All devices on the CAN network must be configured for 125 kbps and use compatible transceivers. We use a DBC
file for all message definitions to ensure interoperability and reduce errors. Commercial CAN tools can be used for
diagnostics, commissioning, and automated testing by leveraging the DBC.
The CAN_db.h file defines the structure, IDs, and bitfields for all CAN messages used in the system. When a
CAN message is received, the COMM module uses the macros and definitions from CAN_db.h to decode the
message, extract relevant fields, and convert it into a structured request for the appropriate service layer module.
In detail, the CAN driver or ISR receives a CAN frame and calls the callback function PDUB_CAN_cfg_clbk(),
where the message ID and data fields are parsed using macros from the CAN_db.h file (for example,
CANMSG_GETFIELD, CANMSG_CH_ID, etc.). Once the message type and parameters (such as channel
number, command, or status) are extracted, a COMM_sev_msg_t structure is filled with the decoded information,
specifying the target module, command, and any required data. Then, the decoded message is placed into the
COMM receiving queue. The COMMRxTask retrieves the message, determines the target module (for example,
eFuse), and constructs a corresponding request (for example, EFUSE_sev_msgReq_t). The request is then
placed into the target module request queue for processing.
The DBC file is included in the project source directory and in the .zip file of the memory image of STEVALPDUBV1 (STSW-PDUB-UDS). As previously mentioned, the DBC file can be imported into any major commercial
CAN tool (such as Vector CANoe, Kvaser CANLIB, Peak PCAN, or similar). Once imported, these tools allow you
to easily send, receive, and monitor CAN messages, without having to manually handle bitfields or encoding.
The following table lists the supported CAN messages and IDs.
Table 12. Supported CAN messages and IDs
CAN message name
UM3594 - Rev 1
CAN ID (Hex)
Purpose/description
CANMSG_CH_ID
0xAA
Channel control: enable/disable e‑fuse channels
CANMSG_PARKING_ID
0xBB
Parking/standby command
CANMSG_ASSEMBLY_ID
0xCC
Assembly state notification
CANMSG_UDS_REQ_ID
0x7E0
UDS diagnostic request
page 48/98
UM3594
Software description
CAN message name
CAN ID (Hex)
CANMSG_UDS_RES_ID
0x7E8
Purpose/description
UDS diagnostic response
Note:
All message details (IDs, signals, bit positions, allowed values) are defined in the DBC file. You do not need to
modify the firmware or manually encode messages. Just use the DBC in your CAN tool.
6.3.4.2
e‑fuse channel activation example via CAN protocol
Supposing that the channel to enable is the EFUSE_OUTA6, the example below shows how to turn on an e‑fuse
channel via CAN.
Step 1.
Receive the CAN frame with ID CANMSG_CH_ID.
Step 2.
Decode the message using the CAN_db.h.
Figure 57. Example of hwo to turn on an e-fuse channel via CAN
Step 3.
COMM receive task dispatches the message to the eFuse module.
Figure 58. example of how the COMM receive task dispatches the message to the eFuse module
Step 4.
6.3.5
The eFuse control task (EFUSECtrlTask) processes the request and enables the specified channel
using the appropriate driver.
ADCWDT_mng of the service layer
The analog-to-digital converter watchdog timer (ADCWDT) module is a core component of the STEVAL-PDUBV1
firmware, responsible for the continuous monitoring of the main power supply rails (VccA, VccB, VccExt) using the
ADC hardware. It provides real-time voltage supervision, threshold checking, and fault notification, ensuring
safety and reliability for the power distribution system. The key implemented functions are:
UM3594 - Rev 1
page 49/98
UM3594
Software description
•
•
•
•
•
Voltage monitoring: it periodically samples the voltages of the main rails (VccA, VccB, VccExt) using the
ADC hardware.
Threshold checking: it compares measured voltages against configurable upper and lower thresholds to
detect out-of-range conditions.
Fault detection and notification: if a voltage is outside the allowed range (overvoltage = voltage rail > 18 V;
undervoltage = voltage rail < 7 V), the module triggers a fault notification to the error management system
(ERR), enabling rapid response and protection.
Data availability status: it maintains and provides the status of the latest ADC conversion, allowing other
modules to check if new data is ready.
Task synchronization: it integrates with FreeRTOS using semaphores and notifications to ensure
deterministic, periodic execution.
The ADCWDT module primarily interacts with other modules through task notifications and shared status
variables, rather than message queues. It is fully integrated into the system’s asynchronous, event-driven
architecture:
•
•
•
Semaphore-based activation: the ADCWDT task (ADCWDTTask) is activated by a semaphore, typically
released by the system scheduler (for example, in PDUB_stm10_clbk()), ensuring periodic and
deterministic execution.
Fault notification via task handles: when a voltage fault is detected, the ADCWDT module uses FreeRTOS
task notifications to asynchronously alert the corresponding error handler task (for example,
ERRVccRailATask or ERRVccRailBTask).
Status query function: other modules can query the latest voltage values and data readiness status using
dedicated getter functions.
This implementation ensures deterministic, periodic monitoring of critical voltages. It enables immediate,
asynchronous fault notification to error management by minimizing latency and maximizing system safety. This
approach integrates seamlessly with the system's event-driven, RTOS-based architecture. Typical interactions
with the ADCWDT module include:
•
•
ERR: it receives fault notifications from ADCWDT and logs or handles voltage faults.
ASS, eFuse, PARK, UDS: it might query voltage values or data status for diagnostics, control, or safety
checks.
The main scheduler (PDUB_mng) periodically activates the ADCWDT task to ensure continuous rail monitoring:
// Example: Periodic activation from the system scheduler
ADCWDT_sev_runTask(); // Releases the semaphore to activate ADCWDTTask
// Example: Querying the latest voltage value
if (ADCWDT_sev_getDataSts() == ADCWDT_DATAREADY) {
float vccA = ADCWDT_sev_getVccRailA();
// Use the voltage value for diagnostics or control
}
The activated task performs ADC conversions, checks thresholds, and notifies error tasks if needed. Other
modules can read the latest voltage values and status at any time.
The ADCWDT module abstracts the monitoring of multiple voltage rails, regardless of the underlying ADC
hardware configuration. Each monitored rail (VccA, VccB, VccExt) is associated with a specific ADC channel,
defined by configuration macros (for example, ADCWDT_CH_VCCA, ADCWDT_CH_VCCB,
ADCWDT_CH_VCCEXT). The module uses driver-layer functions (for example, saradc_lld_readchannel) to read
ADC values, making it independent of the specific ADC hardware implementation.
Upper and lower voltage thresholds are defined by macros and can be easily adjusted to match system
requirements. In this way, the rest of the system can refer to voltage rails in a hardware-independent way. The
ADCWDT module handles all the logic for sampling, conversion, and threshold checking. When adding new rails
or changing hardware mappings, changes are required only for the ADCWDT module.
To ensure that voltage faults are handled by the correct error management logic, the ADCWDT module allows you
to attach the error handler tasks (defined in the ERR module) to each monitored rail:
1. In the ERR module, create the error handler tasks for VccA and VccB (for example, ERRVccRailATask and
ERRVccRailBTask).
2. Obtain their FreeRTOS task handles (xTaskCreate(ERRVccRailATask, ..., &ERRVccRailAHandle); and
xTaskCreate(ERRVccRailBTask, ..., &ERRVccRailBHandle);).
3. After creating the tasks, call the attach functions provided by ADCWDT to link each ERR task to the
corresponding rail (ADCWDT_sev_attachErrorHandleA(ERRVccRailAHandle); and
ADCWDT_sev_attachErrorHandleB(ERRVccRailBHandle);).
UM3594 - Rev 1
page 50/98
UM3594
Software description
This operation is typically performed during system initialization (for example, in ERR_sev_initTask()). After these
operations, whenever a voltage fault is detected on VccA or VccB, ADCWDT notifies the correct ERR task using
the stored handle.
When the ADCWDT module detects that a rail voltage is out of the allowed range (either above the upper
threshold or below the lower threshold), it uses a software interrupt mechanism to immediately notify the attached
ERR task:
void ADCWDT_FailA_PDUB_Clbk(void) { // for Rail A
xTaskNotifyFromISR(ErrorTaskRAILAHandle, 0, eSetBits, NULL);
}
void ADCWDT_FailB_PDUB_Clbk(void) { // for Rail B
xTaskNotifyFromISR(ErrorTaskRAILBHandle, 0, eSetBits, NULL);
}
The xTaskNotifyFromISR function is a FreeRTOS API that safely sends a notification from an ISR (or any context)
to a specific task, acting as a software interrupt. Obviously, the ERR tasks are implemented to wait for these
notifications.
for (;;) {
if (xTaskNotifyWait(0x0, 0xffffffff, NULL, portMAX_DELAY) == pdTRUE) {
// Handle the voltage fault (for example, log DTC, initiate recovery)
}
}
The notification is immediate and asynchronous, ensuring a fast response to faults. The mechanism is robust,
thread-safe, and leverages FreeRTOS efficient intertask signaling.
The following figure shows a list of functions implemented in the ADCWDT module.
Figure 59. ADCWDT module functions
6.3.6
ASS_mng of the service layer
The Assembly (ASS) module is responsible for the initial configuration of e‑fuse channels during the assembly
phase of the ECU. Its main function is to enable or disable specific channels according to a static configuration
table, ensuring that the system is correctly set up for initial testing, validation, or production procedures. The key
implemented functions are:
•
•
•
•
Initial channel configuration: during the assembly phase, the ASS module reads a static configuration table
(ASS_sev_cfg[ ]) that specifies which e‑fuse channels should be enabled or disabled.
Automated channel activation: the module automatically sends commands to the eFuse module to set the
state (enable/disable) of each channel as defined in the above mentioned static configuration table.
Verification and feedback: after attempting to configure all channels, the module verifies the actual state of
each channel to ensure that the configuration was applied successfully.
Status reporting: the module provides feedback on the outcome of the assembly procedure, indicating
success or failure, and can notify external systems or operators via CAN messages and status LEDs.
Typical interactions with the ASS module include:
UM3594 - Rev 1
page 51/98
UM3594
Software description
•
•
•
•
•
ADCWDT: it provides the VccExt voltage measurement that determines whether assembly mode should be
entered.
eFuse: it receives and executes channel configuration commands from ASS during assembly.
COMM: it sends assembly status notifications (success/failure) via CAN.
ERR: it might be used to log or handle errors if the assembly procedure fails.
PARK: it should be used after assembly to safely turn off all loads and put the ECU into a low-power state.
A key feature of the ASS module is that the assembly procedure is only initialized if the voltage on VccExt is
greater than 2.5 V at ECU startup. The ASS module interacts with the ADCWDT module, which is responsible for
acquiring and converting the VccExt voltage. At startup, the ASS module calls ADCWDT_sev_startConv() to
trigger an ADC conversion. It then checks the result using ADCWDT_sev_getVccExt(). If VccExt > 2.5 V, the
assembly procedure is started; otherwise, the ECU skips Assembly mode and enters normal operation.
This mechanism ensures that Assembly mode is entered only under controlled conditions, such as during vehicle
production or maintenance, preventing accidental reconfiguration during normal operation. The channels to be
activated during Assembly mode are indicated in a static configuration table defined as an array of
ASS_sev_cfg_t structures:
typedef struct{
EFUSE_sev_channel_t EFUSE_sev_channel; // Logical channel identifier
EFUSE_sev_channelSts_t EFUSE_sev_channelSts; // Desired state (enable/disable)
} ASS_sev_cfg_t;
Each entry specifies a channel and whether it should be enabled or disabled during assembly.
The basic steps for the assembly mode are the following:
1. Start Assembly mode: the ASS module is triggered to enter assembly mode only if VccExt > 2.5 V (as
measured by ADCWDT) at startup.
2. Apply configuration: for each entry in the static configuration table, the module sends a request to the eFuse
module to set the channel state as specified.
3. Verification: after all requests are processed, the module queries the actual state of each channel to verify that
the configuration was applied correctly.
4. Outcome: if all channels are correctly configured, the module sends a "success" notification (for example, via
CAN message COMM_SEV_SET_ASSDONE) and blinks a status LED to indicate completion. The ECU is
now operational and ready for further use. On the other hand, if any channel fails to reach the desired state,
the module sends a "failure" notification (for example, via CAN message COMM_SEV_SET_ASSFAIL) and
sets a status LED to indicate an error. The system can be diagnosed or reconfigured as needed.
5. After Assembly mode: once the assembly procedure is complete and the ECU is operational, it is strongly
recommended to turn off all loads and put the ECU into Parking mode. This ensures that the system is in a
safe, low-power state and prevents unnecessary power consumption or potential faults before the ECU is
deployed in its final environment.
The following figure lists the functions implemented for the ASS module.
Figure 60. ASS module functions
The task logic (ASSTask) reads the static configuration table, sends set output requests to the eFuse module for
each channel, verifies the result for each channel, and sends status notifications (success/failure) via CAN while
updating the status LED.
6.3.7
PARK_mng of the service layer
The Park module is responsible for managing the transition of the STEVAL-PDUBV1 ECU into a safe, low-power
Parking state. This operation is essential before vehicle shutdown, during maintenance, or whenever the system
must be de-energized in a controlled and safe manner. The key implemented functions are:
UM3594 - Rev 1
page 52/98
UM3594
Software description
•
•
•
Safe system standby: it initiates a coordinated standby procedure for all e‑fuse devices and power
management ICs, ensuring that all loads are safely disconnected and the system is ready for low-power
operation.
Inter-module coordination: it orchestrates the interaction between e‑fuse (for channel/device standby) and
PMIC (for VBATT standby), guaranteeing that all safety and operational constraints are respected.
Wake-up policy management: it defines and manages the conditions under which the ECU can be safely
reactivated from Parking mode.
All the interactions with the Park module are performed using asynchronous message queues. Other service layer
modules (such as COMM or diagnostics) communicate with the Park module by placing structured request
messages into a dedicated request queue. Each message specifies the operation to be performed (for example,
enter Parking mode). The Park module includes a dedicated freeRTOS task (PARKTask) that continuously
monitors the request queue, processes incoming requests, and coordinates the standby procedure.
A central aspect of the Park module is its interaction with the eFuse module, specifically through the
EFUSE_sev_setStandby() function. This function is designed to safely transition all e‑fuse devices and channels
into standby mode. However, it does not force devices into standby unconditionally. Instead, it performs a series
of safety checks to ensure that entering standby does not cause unsafe or damaging conditions. The checks
performed depend upon the device:
•
•
VNF1248F devices: it checks if the bypass switch is saturated (that is, the bypass MOSFET is conducting
due to a fault or overload). If saturation is detected, the device does not enter standby, as this could leave
the load unprotected or cause hardware damage.
L99SP08 devices: it checks if the current output on any channel exceeds the ITHx threshold (the
programmable current limit). If any channel is above threshold, the device does not enter standby, as this
indicates an active load or fault condition, and the shutdown sequence is aborted to prevent unsafe
conditions. Otherwise, all e‑fuse devices are transitioned to Standby mode. The Park module then issues
the VBATT standby command to the PMIC SPSB081 PMIC
(AEK_POW_SPSB081_Force_VBAT_StandBy(SPSB081_DEV0);).
This command puts SPSB081 into Standby mode, disabling both V1 and V2 outputs (as per the datasheet
DS14048). As a result, all downstream loads are de-energized, and the SPSA068 PMIC is also forced into
standby since its supply rails are now at 0 V. As a consequence of the PMICs entering standby, the
microcontroller loses power and shuts down.
After entering Parking mode, the system can be woken up in several ways:
•
•
•
CAN message to SPSB081: the sending of a specific CAN message to SPSB081 triggers its exit from
standby and re-enables V1/V2 outputs, thus powering up the other PMIC and the microcontroller.
Physical wake up Pin transition: a transition (typically a rising or falling edge) on the physical wake up pin
of SPSB081 causes it to exit standby, as described in the device datasheet DS14048.
Fault condition on e‑fuse devices: if a bypass switch saturation is detected on a VNF1248F device, the
device asserts its DIAG pin, which can be wired to a wake up input on the PMIC. Similarly, if the current
threshold is exceeded on an L99SP08 channel, the corresponding DIAG pin is asserted, which can also be
used as a wake up source.
Upon microcontroller wake-up, all e‑fuse devices and PMICs automatically return to Normal mode. The system
resumes full operation, ready to handle new commands or events. Typical interactions with the Park module
include:
•
•
•
•
eFuse: the Park module’s core logic is built around the EFUSE_sev_setStandby() function, which ensures
all e‑fuse devices are in a safe state before power-down.
PMIC: it issues the VBATT standby command to SPSB081 and it powers down the SPSA068 and,
consequently, the microcontroller.
COMM: it can receive parking requests via CAN and send status notifications.
ERR: it might be used to log or handle errors if the parking procedure fails or is aborted due to unsafe
conditions.
The following figure lists the functions implemented for the Park module.
UM3594 - Rev 1
page 53/98
UM3594
Software description
Figure 61. Park module functions
The Park task logic (PARKTask) receives a parking request (from CAN, user command, or another module). It
calls the EFUSE_sev_setStandby() function to safely transition all e‑fuse devices to standby (only if all safety
conditions are met). Finally, it issues the VBATT standby command to SPSB081 PMIC. Once Parking mode is
completed, it monitors wake-up events and manages the transition back to operational mode as required.
6.3.8
ERR_mng of the service layer
The error management (ERR) module is a critical component of the STEVAL-PDUBV1 firmware, responsible for
the detection, classification, storage, and reporting of all errors that occur within the ECU. It ensures that every
relevant fault is tracked, its status is updated in real time, and that diagnostic information is available for UDS and
after-sales analysis. The key implemented functions are:
•
•
•
•
•
Error detection and classification: it monitors all relevant system events and conditions, classifies errors as
ACTIVE or NOT_ACTIVE, and updates their status accordingly.
Diagnostic trouble code (DTC) management: it converts detected errors into DTCs (as per UDS standards)
and manages their life cycle.
EEPROM storage: it stores DTCs persistently in EEPROM, ensuring that error history is retained across
power cycles.
UDS integration: it provides DTC data and error status to the UDS diagnostic module for external querying
and reporting.
Interaction with other modules: it receives error notifications from modules such as ADCWDT, eFuse,
PMIC, and manages their status and reporting.
An error is considered ACTIVE when the condition that triggered it is still present (for example, a voltage is still
out of range, or a device is still in fault). An error becomes NOT_ACTIVE when the triggering condition is no
longer present (for example, the voltage returns within range or the device recovers). The ERR module
continuously updates the status of each error based on real-time system feedback. Each error is mapped to a
diagnostic trouble code (DTC) according to UDS standards, allowing external diagnostic tools to query and
interpret error conditions. All DTCs are stored in EEPROM, ensuring that error history is preserved across power
cycles and available for after-sales diagnostics.
The ERR module updates the ACTIVE/NOT_ACTIVE status of each DTC in real-time, based on the current
system state. Typical interactions with the ERR module include:
•
•
•
•
ADCWDT: it notifies ERR of voltage faults via software interrupts; ERR manages the corresponding error
status and DTC.
eFuse and PMIC: the ERR task monitors and logs errors reported by these modules.
UDS: it provides DTC data and error status for external diagnostics.
COMM: it can send error notifications or status updates via CAN.
The following figure lists the functions implemented in the ERR module.
UM3594 - Rev 1
page 54/98
UM3594
Software description
Figure 62. ERR module functions
All DTCs are written to and read from EEPROM for persistent storage. The following table summarizes the
function calls and their results.
Table 13. Summary table for ERR interactions
Step
6.3.8.1
Module
Action / function called
Result / effect
1
ADCWDT
Detects out-of-range voltage, notifies ERR Fault detected, software interrupt sent
2
ERR
ERRVccRailATask wakes up and calls
setDTC()
Error code set to ACTIVE, DTC updated
3
ERR
It writes the DTC into EEPROM
Error history is persistent
4
eFuse
RAILAOFF called (if auto recovery is
enabled). RAILA channels disabled.
Mapped RAILB channels enabled.
5
UDS/COMM
DTC is available for diagnostics and
notifications.
Error can be read by external tools or
systems.
6
ADCWDT/ERR
Condition clears, setDTC called with
NOT_ACTIVE
DTC status updated. It remains in
EEPROM for historical accounting
purposes.
List of diagnosable errors for ERR_mng
Table 14 provides a detailed list of all errors that can be diagnosed and managed by the ERR module, as defined
in the error code enumeration (ERR_sev_errorCode_t). Each error is accompanied by a comment describing its
meaning and typical cause.
Table 14. ERR diagnosable errors
UM3594 - Rev 1
Error code enum
Device
Description
PMIC_VSUV_SPSA068
SPSA068
Supply undervoltage detected
PMIC_VSUH_SPSA068
SPSA068
Supply overvoltage detected
PMIC_OV_SPSA068
SPSA068
General overvoltage condition
PMIC_WDGERROR_SPSA068
SPSA068
Watchdog error
PMIC_BISTERROR_SPSA068
SPSA068
Built-in self-test error
PMIC_BUCKPWUPERROR_SPSA068
SPSA068
Step-down converter power-up error
PMIC_BUCKGNDLOSS_SPSA068
SPSA068
Step-down converter ground loss
PMIC_OTGLOBAL_SPSA068
SPSA068
Overtemperature global error
PMIC_VSUV_SPSB081
SPSB081
Supply undervoltage detected
PMIC_VSOV_SPSB081
SPSB081
Supply overvoltage detected
PMIC_V1UV_SPSB081
SPSB081
V1 undervoltage detected
page 55/98
UM3594
Software description
Error code enum
Device
Description
PMIC_V1OV_SPSB081
SPSB081
V1 overvoltage detected
PMIC_WDGFAIL_SPSB081
SPSB081
Watchdog failure
PMIC_TW_SPSB081
SPSB081
Thermal warning
EFUSE_HSHT
e‑fuse
HSHT warning
EFUSE_VDSMAX
e‑fuse
Maximum drain-source voltage exceeded
(MOSFET protection)
EFUSE_FUSELATCH
e‑fuse
Fuse latch triggered (permanent fault)
EFUSE_OVC
e‑fuse
Overcurrent detected
EFUSE_OVT
e‑fuse
OVT detected
EFUSE_WDGFAIL
e‑fuse
Watchdog failure
EFUSE_TW
e‑fuse
Thermal warning
EFUSE_VDSHSR
e‑fuse
High-side short detected (VDSHSR)
EFUSE_ITLOFFSR
e‑fuse
ITL off detected
EFUSE_CHLOFFSR
e‑fuse
CHL off detected
EFUSE_ITST
e‑fuse
ITST detected
EFUSE_OTSR
e‑fuse
Overtemperature detected
EFUSE_IPEAKLSR
e‑fuse
IPEAK low-side short detected
PCHANNEL_WDFAIL
L99SP08
Watchdog failure
PCHANNEL_BGFAIL
L99SP08
Bandgap reference failure
PCHANNEL_OSCFAIL
L99SP08
Oscillator failure
PCHANNEL_VCCOV
L99SP08
VCC overvoltage
PCHANNEL_VCCUV
L99SP08
VCC undervoltage
PCHANNEL_TW
L99SP08
Thermal warning
PCHANNEL_VDSMAX
L99SP08
Maximum drain-source voltage exceeded
VCC_RAILA
Rail A
VccA rail out of range (voltage above or below
threshold)
VCC_RAILB
Rail B
VccB rail out of range (voltage above or below
threshold)
Special attention is given to errors detected by the ADCWDT module:
•
•
•
Fault detection: when ADCWDT detects that VccA or VccB is out of range, it uses a software interrupt
(FreeRTOS task notification) to immediately notify the corresponding ERR task (ERRVccRailATask or
ERRVccRailBTask).
Error status management: upon receiving the notification, the ERR task sets the corresponding error
(VCC_RAILA or VCC_RAILB) to ACTIVE. If the voltage returns within range, the error is set to
NOT_ACTIVE.
DTC update and storage: the status change is immediately reflected in the DTC list and stored in
EEPROM, ensuring traceability and compliance with diagnostic requirements.
Considering the case where the voltage on rail VccA goes out of range (either above the upper threshold or below
the lower threshold), the steps below show an example of error detection and management.
1. Fault detection by ADCWDT: the ADCWDT module detects the out-of-range voltage on VccA. It triggers a
software interrupt to the ERR module by notifying the dedicated error handler task for VccA:
xTaskNotifyFromISR(ErrorTaskRAILAHandle, 0, eSetBits, NULL).
UM3594 - Rev 1
page 56/98
UM3594
Software description
2. Error handler task activation (ERR module): ERRVccRailATask wakes up and processes the error.
for (;;) {
If (xTaskNotifyWait(0x0, 0xffffffff, NULL, portMAX_DELAY) == pdTRUE) {
// Set VCC_RAILA error to ACTIVE, store/update DTC in EEPROM
ERR_sev_setDTC(VCC_RAILA, ACTIVE, 0);
// Optionally, trigger recovery actions or notify other modules
}
}
3. DTC management and EEPROM storage: the ERR module calls ERR_sev_setDTC() to set the error code
VCC_RAILA as ACTIVE. The error is added to the DTC list and written to EEPROM for persistent storage.
4. Automatic switched recovery (RAILAOFF): if the system is configured for automatic switched recovery (that is,
RAILA channels are mapped to RAILB channels in the recovery configuration), the ERR module or the system
logic call EFUSE_sev_RAILOFF(). For each mapped RAILA channel, the function disables the RAILA channel
and enables the corresponding RAILB channel. This ensures that loads are automatically switched to the
backup rail, maintaining system operation even in the presence of a fault. If a channel is not mapped, no
automatic recovery is performed for that channel, therefore manual intervention is required.
5. System response and UDS availability: the error is now available as a DTC for UDS diagnostics. If a UDS tool
queries the ECU, the DTC for VCC_RAILA is reported as ACTIVE. The system can also send a CAN
notification or update a status LED, depending on the configuration.
6. Error resolution: when the voltage on VccA returns within the allowed range, ADCWDT no longer triggers the
error. The ERR task, upon periodic check or notification, updates the DTC status to NOT_ACTIVE:
ERR_sev_setDTC(VCC_RAILA, NOT_ACTIVE, 0). The DTC remains stored in EEPROM, but its status is now
NOT_ACTIVE, indicating that the fault is no longer present but was detected in the past.
6.3.9
UDS_mng of the service layer
The unified diagnostic services (UDS) module implements a simplified version of the ISO14229 standard,
providing diagnostic and service access to the STEVAL-PDUBV1 ECU via CAN. It enables external tools and
testers to interact with the ECU for configuration, fault reading, and system status using a standardized protocol
widely adopted in the automotive industry. The key implemented functions are:
•
•
•
•
•
Session management: it supports different diagnostic sessions (for example, default, extended) to control
access to various services and data.
Service identifier (SID) handling: it decodes and processes UDS service requests (SIDs) such as session
control, DTC reading, DTC clearing, and data reading.
Data identifier (DID) handling: it provides access to specific data items (DIDs) such as channel status,
current, voltage, temperature, and error information.
Positive and negative response generation: it returns standardized positive or negative responses to each
UDS request, as per ISO14229.
Integration with other modules: it interacts with ERR, eFuse, and other modules to retrieve diagnostic data
and execute service requests.
Typical interactions with the UDS module include:
•
•
•
ERR: it provides DTC data and error status for UDS DTC services.
eFuse: it provides channel status, current, voltage, temperature, and other data for UDS data services.
COMM: it receives UDS requests via CAN and sends UDS responses.
The following figure lists the functions implemented for the UDS module.
Figure 63. UDS module functions
The task logic (UDSTask) receives UDS requests from the communication module, decodes the SID and DID,
and interacts with ERR, eFuse, and other modules to retrieve or modify data. The task sends positive or negative
responses according to ISO14229.
UM3594 - Rev 1
page 57/98
UM3594
Software description
6.3.9.1
UDS sessions, SIDs, and DIDs
The UDS sessions define the diagnostic access level and available services. The default session (DEFAULT)
allows basic diagnostic access with limited services. The extended diagnostic session
(EXTENDED_DIAGNOSTIC) grants full access to advanced diagnostics, DTC management, and data reading.
SIDs are 1-byte codes that identify the requested UDS service. The UDS module implements the following SIDs.
Table 15. SID codes
SID (Hex)
Service name
Description
0x10
Session control
Switches between diagnostic sessions
0x14
Clear DTC
Clears all stored diagnostic trouble codes
0x19
Read DTC
Reads DTCs and their status
0x22
Read data by identifier
Reads specific data items (DIDs)
DIDs are 2-byte codes that specify the data item to be accessed. The UDS module implements the following
DIDs:
Table 16. Examples of DID codes
DID (Hex)
Data item
Description
0xF110
Channel status
It returns the status (on/off) of a channel
0xF111
Channel current
It returns the current of a channel
0xF112
Channel voltage
It returns the voltage of a channel
0xF113
Channel temperature
It returns the temperature of a channel
0xF114
Channel ITLOff status
It returns I2t event feedback status of a channel
0xF115
Channel DIEN status
It returns DI input pin status
0xF116
Channel OVC
It returns the overcurrent status of a device
0xF117
Channel OVT
It returns overtemperature status of a device
0xF118
Channel HSHT
It returns hard short circuit latched off for VNF1248F
0xF119
Channel VDSMax
It returns the voltage drain source max flag for a channel
0xF120
Channel FuseLatch
It returns a flag in case of overcurrent (VNF1248F)
0xF121
Channel CHLOFF
It returns a flag in case of power limitation of overcurrent
0xF122
Channel IPEAK
It returns a flag in case of peak detected
0xF123
Channel WDGFail
It returns a flag in case of watchdog failure
0xF124
P-Channel WDGFail
It returns a flag in case of P-Channel watchdog failure
0xF126
Channel LCC
It returns the LCC status of a channel
0xF127
SPSA068 WDGFail
It returns a flag in case of SPSA068 watchdog failure
0xF128
SPSB081 WDGFail
It returns a flag in case of SPSB081 watchdog failure
0xF129
Bypass saturation
It returns a flag in case of bypass saturation (VNF1248F)
All the implemented SIDs and DIDs in the STEVAL-PDUBV1 stack software are listed below:
UM3594 - Rev 1
page 58/98
UM3594
Software description
•
Session control (SID 0x10): it switches between default and extended diagnostic sessions.
–
–
–
•
Example request: SID: 0x10, Data: 0x03 (EXTENDED_DIAGNOSTIC).
Positive response: SID: 0x50 (0x10 + 0x40) echo session type, timing parameters.
Negative response: SID: 0x7F, Data: 0x10 (original SID), error code (for example, 0x12 for
subfunction not supported).
Clear DTC (SID 0x14): it clears all DTCs stored in the ERR module and EEPROM.
•
–
Example request: SID: 0x14.
–
Positive response: SID: 0x54 (0x14 + 0x40) confirmation of DTC clear.
–
Negative response: SID: 0x7F, Data: 0x14, error code (for example, 0x22 for wrong conditions).
Read DTC (SID 0x19): it reads the list of DTCs and their status (ACTIVE/NOT_ACTIVE).
•
–
Example request: SID: 0x19, Data: 0x01 (report number of DTCs), 0xFF (all statuses).
–
Positive response: SID: 0x59 (0x19 + 0x40) number of DTCs, DTC codes, status.
–
Negative response: SID: 0x7F, Data: 0x19, error code (for example, 0x31 for request out of range).
Read data by identifier (SID 0x22): it reads specific data items (DIDs) such as channel status, current,
voltage, temperature, LCC, etc.
–
–
–
Example request: SID: 0x22, Data: 0xF1 0x10 (DID for channel status), channel number.
Positive response: SID: 0x62 (0x22 + 0x40) DID, channel, value.
Negative response: SID: 0x7F, Data: 0x22, error code (for example, 0x31 for request out of range,
0x22 for wrong conditions).
Table 17. UDS message examples
Message
Request
Positive response
50 03 00 32 01 F4 00 00
50: Positive response SID
Switch to extended diagnostic
session
10 03
03: Session type (extended)
0032: P2 server timing
01F4: P2* extended timing
54 00 00 00 00 00 00 00
Clear all DTCs
14
54: Positive response SID
Remaining bytes: confirmation
Report number of DTCs in all
statuses
19 01 FF
7F: Negative response SID
10: Original SID
12: Subfunction not supported
7F 14 22
7F: Negative response SID
14: Original SID
22: Wrong conditions
7F 19 31
59: Positive response SID
7F: Negative response SID
01: Subfunction
19: Original SID
00000002: Number of DTCs
31: Request out of range
62: Positive response SID
22 F1 10 06
7F 10 12
59 01 00 00 00 02 00 00
62 F1 10 06 01 00 00 00
Read status of channel 6
Negative response
F1 10: DID for channel status
06: Channel number
01: Status (enabled)
7F 22 31
7F: Negative response SID
22: Original SID
31: Request out of range
62 F1 11 06 00 64 00 00
Read current of channel 6
UM3594 - Rev 1
22 F1 11 06
62: Positive response SID
7F 22 31
F1 11: DID for channel current
7F: Negative response SID
06: Channel number
22: Original SID
0064: Current value (for example,
100 mA)
31: Request out of range
page 59/98
UM3594
Software description
6.4
STEVAL-PDUBV1 software state machine
The figure below shows the state machine for the STEVAL-PDUBV1 software.
Figure 64. Application software state machine
Parking
Mode
Normal
Error Detected
(Critical Fault)
Error Recovery /
Clear
6.4.1
Error
Normal mode
Normal mode is the standard operational state of STEVAL-PDUBV1, where all modules (eFuse, PMIC, ADCWDT,
COMM, UDS, etc.) are fully functional and manage loads and channels according to the system logic. In this
mode, power distribution, diagnostics, and protection mechanisms are fully active. The system enters Normal
mode after a wake-up event, when:
•
•
•
•
An exceeding current threshold is present in one of the L99SP08 channels (RAILA or RAILB), typically
when the load-demand surpasses the standby capability.
A CAN message requesting system activation is received (for example, a wake-up command from the
vehicle network).
Wake-up from Parking mode is requested via a pin, or a hardware fault event.
There is a recovery from an ERROR state, that is, all critical faults have been cleared, and all modules
have returned to a safe operational state.
While in Normal mode, the following policies are active:
•
•
•
•
Power channel management: both the P-channel switches (L99SP08) and the e‑fuses operate in Normal
mode. With the I²t protection, each channel is monitored according to its programmed energy curve,
preventing overheating of wiring and components. In addition, according to thermal policy, junction and
case temperatures are continuously monitored and, if thresholds are exceeded, shutdown or derating
policies are applied according to the configuration. Each channel must respect its nominal current, and any
overcurrent is managed according to the configured protection policy (latch-off, auto-restart, etc.).
Load management: all loads are powered and managed according to system logic and application
requirements. Diagnostics are active; therefore, any anomalies are reported via CAN or through status
registers. When a Parking mode request is received, the system evaluates load priorities: only
non‑essential loads are powered down, while critical loads remain supplied until it is safe to disconnect
them.
State transition handling: the system continuously monitors the status of all channels, temperatures,
currents, and voltages, and reacts promptly in case of anomalies. All state transitions are subject to safety
checks to prevent unintended power loss to sensitive or safety-critical loads.
Diagnostics and reporting: all protection events (I²t, thermal, overcurrent) are logged and can be reported
via CAN or diagnostic interfaces for traceability and maintenance.
While in Normal mode, the system can transition to:
•
•
UM3594 - Rev 1
Parking mode: transition to Parking mode is only allowed if all e‑fuses are no longer required (that is, no
critical load is active), and the total load current has dropped below the threshold manageable by L99SP08
in standby mode (typically below I_THRx). Any parking/shutdown request via CAN, user command, or
system logic is considered only if these safety and operational conditions are met, ensuring that essential
loads remain powered as long as necessary.
ERROR: if a critical fault is detected (for example, persistent out-of-range voltage, unrecoverable e‑fuses
or PMIC error), the system transitions to Error mode, disabling loads according to the safety policies.
page 60/98
UM3594
Software description
6.4.2
Parking mode
In Parking mode, STEVAL-PDUBV1 is in a safe, low-power state. All e‑fuse channels (for example, VNF9x family)
are powered down as the microcontroller is off, and the PMICs are in standby mode. The P-channel switches
(L99SP08) are in standby mode too. In this state, all channels connected with essential always-on loads remain
powered as they were in Normal mode (for example, telematics, security, or gateway modules). Only wake-up
channels are monitored to allow the system to resume operation when required.
To enter Parking mode, a Park request shall be received and all safety checks in setStandby shall pass (for
example, no bypass saturation, no overcurrent, all e‑fuses can be safely powered down).
The specific actions connected to Parking mode are:
•
•
•
•
•
e‑fuse channels (VNF9x): all e‑fuse channels are powered down, as the microcontroller is not operational
and cannot manage them.
PMICs: all PMICs are in Standby mode, supplying only the minimal power required for the wake-up logic.
P-channel switches (L99SP08): the P-channel switches enter Standby mode. In this state, any channels
that were active during Normal mode remain powered, ensuring continuity for always-on loads.
Microcontroller: the microcontroller is powered down and does not execute the code.
Wake-up monitoring: only wake-up sources (CAN, physical wake-up pins, or hardware fault events) are
monitored.
While in Parking mode, the system can transition to:
•
•
•
Normal: upon a valid wake-up event, such as a CAN message addressed to the PMIC, a physical wake-up
pin activation, or a hardware fault event (for example, bypass saturation, overcurrent on a P-channel
detected via DIAG pin).
Error: if a fault is detected during the transition to Parking mode and the system cannot safely enter
standby (for example, a channel cannot be safely powered down, or a persistent fault is present). The
system has detected a critical fault (for example, voltage out-of-range, e‑fuse/PMIC unrecoverable error,
persistent hardware fault). Error becomes ACTIVE and DTC is set. The same happens when any module
(typically ADCWDT, eFuse, PMIC) detects a critical error and notifies ERR, which sets the error to ACTIVE.
Parking: when a failed attempt to enter Parking mode due to unsafe conditions is recorded. This could go
back to Normal if all errors are cleared (for example, voltage returns in range; faults are resolved, and
DTCs are cleared).
If a programmable current threshold is exceeded on any P-channel (L99SP08) during Parking mode, we get a
corresponding DIAG pin transition (typically towards LOW). This DIAG signal is routed to the PMICs, which
interpret it as a wake-up event. The PMICs then power up the microcontroller, which resumes operation and
transitions the system from Parking mode to Normal. This mechanism ensures that if an unexpected load or fault
condition occurs on an always-on channel, the system can immediately wake up and take appropriate action.
UM3594 - Rev 1
page 61/98
UM3594
Software description
6.5
Task scheduling and duration
The figures below show the typical scheduling for the service layer main tasks.
UM3594 - Rev 1
page 62/98
UM3594
Software description
•
eFuse task: task scheduled every 40.09 msec with a duration of 3.8 msec.
Figure 65. eFuse task timing diagram
•
PMIC task: task scheduled every 10.05 msec with a duration of 610.3 µsec.
Figure 66. PMIC task timing diagram
UM3594 - Rev 1
page 63/98
UM3594
Software description
•
ADCWDT task: task scheduled every 100 msec with a duration of 44.85 µsec.
Figure 67. ADCWDT task timing diagram
•
ERR task: task scheduled every 9.956 msec with a duration of 2.1 msec.
Figure 68. ERR task timing diagram
UM3594 - Rev 1
page 64/98
UM3594
Software description
•
COMMRx task: task scheduled every 100.3 msec (CAN sent from host every 100 msec) with a duration of
316 µsec.
Figure 69. COMMRx task timing diagram
UM3594 - Rev 1
page 65/98
UM3594
Software description
•
Park task: task scheduled every 200.6 msec (CAN sent from host every 200 msec) with a duration of 30.58
msec.
Figure 70. Park task timing diagram
Figure 71. Sti2Fuse PDUB software timing
According to the values in the figures above, the complete time diagram shall be like Figure 72.
UM3594 - Rev 1
page 66/98
UM3594
Software description
Figure 72. All task timing diagram
6.6
How to download STSW-PDUB-UDS image on STEVAL-PDUBV1
The software is pre-burned on STEVAL-PDUBV1.
To download the flash memory image on the board, follow the few steps below:
Step 1.
From the product folder page of STSW-PDUB-UDS, download the software zip file.
Step 2.
Unzip the file. This file has three folders:
–
–
–
Note:
The Build folder that contains the out.elf file to program the board.
The PDUB_Project_ELF folder that contains the debug.wsx file to be used to program the board
through UDE PLS IDE.
The PDU_database contains the PDUB_database.dbc file. This file contains CAN messages for
diagnostic access and available services (log, fault, etc.).
According to the debugger you are using, you can choose to download the .elf file or .wsx.
Refer to Section 6.3.9.1 for details on how to send messages to the board and get responses implemented
through the UDS protocol.
UM3594 - Rev 1
page 67/98
UM3594 - Rev 1
7
Schematic diagrams
Figure 73. STEVAL-PDUBV1 circuit schematic (1 of 14)
UM3594
Schematic diagrams
page 68/98
UM3594 - Rev 1
Figure 74. STEVAL-PDUBV1 circuit schematic (2 of 14)
UM3594
Schematic diagrams
page 69/98
UM3594 - Rev 1
Figure 75. STEVAL-PDUBV1 circuit schematic (3 of 14)
UM3594
Schematic diagrams
page 70/98
UM3594 - Rev 1
Figure 76. STEVAL-PDUBV1 circuit schematic (4 of 14)
UM3594
Schematic diagrams
page 71/98
UM3594 - Rev 1
Figure 77. STEVAL-PDUBV1 circuit schematic (5 of 14)
UM3594
Schematic diagrams
page 72/98
UM3594 - Rev 1
Figure 78. STEVAL-PDUBV1 circuit schematic (6 of 14)
UM3594
Schematic diagrams
page 73/98
UM3594 - Rev 1
Figure 79. STEVAL-PDUBV1 circuit schematic (7 of 14)
UM3594
Schematic diagrams
page 74/98
UM3594 - Rev 1
Figure 80. STEVAL-PDUBV1 circuit schematic (8 of 14)
UM3594
Schematic diagrams
page 75/98
UM3594 - Rev 1
Figure 81. STEVAL-PDUBV1 circuit schematic (9 of 14)
UM3594
Schematic diagrams
page 76/98
UM3594 - Rev 1
Figure 82. STEVAL-PDUBV1 circuit schematic (10 of 14)
UM3594
Schematic diagrams
page 77/98
UM3594 - Rev 1
Figure 83. STEVAL-PDUBV1 circuit schematic (11 of 14)
UM3594
Schematic diagrams
page 78/98
UM3594 - Rev 1
Figure 84. STEVAL-PDUBV1 circuit schematic (12 of 14)
UM3594
Schematic diagrams
page 79/98
UM3594 - Rev 1
Figure 85. STEVAL-PDUBV1 circuit schematic (13 of 14)
UM3594
Schematic diagrams
page 80/98
UM3594 - Rev 1
Figure 86. STEVAL-PDUBV1 circuit schematic (14 of 14)
UM3594
Schematic diagrams
page 81/98
UM3594
Bill of materials
8
Bill of materials
Table 18. STEVAL-PDUBV1 bill of materials
Item
Ref.
Part/value
Description
Manufacturer
Order code
2
C95, C98
100uF
100uF/
50V_20%_CES
_D_10
PANASONIC
EEHZC1H101V
2
12
C55A, C55B,
C125A, C125B,
C125C, C125D,
C125E, C125F,
C126A, C126B,
C127A, C127B
22uF
22uF/
50V_20%_CES
_D_6.3
PANASONIC
EEHZ
3
1
Q1
BC68PA
BC68PA
NEXPERIA
BC68PASX
4
1
U12
LDL40PURY,
DFN 6L 2X2X
LDL40PURY
0.75 PITCH0.65
AG
ST
LDL40PURY
5
1
U8
SPC58NG84E7
QEH0X, LQFP
176 24x24x1.4
SPC58NG84E7
ST
SPC58NG84E7QEH0X
6
2
P6, P12
G&H 8pin
GH 8pin
MTConnectivity
401100ABK
7
2
P13, P16
M5_screw_conn
MTConnectivity
ector
01.1.0003
8
6
P3, P4, P5, P9,
P10, P11
M6_screw_conn
MTConnectivity
ector
01.1.0004
9
6
P1, P2, P7, P8,
P14, P15
M8_screw_conn
MTConnectivity
ector
01.1.0005
10
2
N/A
Power Protector
N/A
for 16 pin
MTConnectivity
01.0.0002
11
12
N/A
Power Protector
N/A
for 25 pin
MTConnectivity
01.0.0003
12
44
T4A, T4B, T4C,
T4D, T4E, T4F,
T5A, T5B, T5C,
T5D, T5E, T5F,
T6A, T6B, T6C,
T6D, T6E, T6F,
T7A, T7B, T8A,
T8B, T9A, T9B,
T10A, T10B,
T11A, T11B,
T12A, T12B,
T13A, T13B,
T14A, T14B,
T15A, T15B,
T16A, T16B,
T17A, T17B,
T18A, T18B,
T19A, T19B
STL059N4S8A
G
STL059N4S8A
G
ST
STL059N4S8AG
13
4
U1A, U1B, U1C,
U1D
VNF9D1M5Q
ST
VNF9D1M5QTR
14
1
U11
TJA1101
NXP
TJA1101AHN/0Z
15
1
U10
SPSA068-TR
ST
SPSA068-TR
1
UM3594 - Rev 1
Q.ty
SPSA068-TR,
QFN-32L WF
page 82/98
UM3594
Bill of materials
Item
UM3594 - Rev 1
Q.ty
Ref.
Part/value
Description
Manufacturer
Order code
16
10
U4A, U4B, U4C,
U4D, U4E, U4F,
QFN-32L WF
U5A, U5B, U6A,
U6B
VNF1248F
ST
VNF1248FTR
17
2
U7A, U7B
Tape and Reel
L99SP08
ST
L99SP08TR
18
1
U9
QFN-32L WF
SPSB081
ST
SPSB0813-TR
19
2
U2A, U2B
VNF9D5SF
ST
VNF9D5SFTR
20
1
U3
VNF9Q20SF
ST
VNF9Q20SFTR
21
4
Tr_d3, Tr_d4,
Tr_d10, Tr_d13
SM15T30AY,
SMC
SM15T30AY
ST
SM15T30AY
22
2
Tr_d18, Tr_d19
SM15T33AY,
SMC
SM15T33AY
ST
SM15T33AY
23
2
Tr_d20, Tr_d21
SM15T18AY,
SMC
SM15T18AY
ST
SM15T18AY
24
10
D8A, D8B, D8C,
D8D, D8E, D8F, 40 V,
D9A, D9B,
SOD123Flat
D10A, D10B
STPS1L40-Y
ST
STPS1L40ZFY
25
5
D14A, D14B,
D17, D18, D19
60 V, SOD128
Flat
STPS360-Y
ST
STPS360AFY
26
1
CR1
SOT323
ESDCAN03-2B
WY
ST
ESDCAN03-2BWY
27
30
D1A, D1B, D1C,
D1D, D2A, D2B,
D5, D6A, D6B,
D6C, D6D,
D6E, D6F, D7A,
D7B, D11A,
40 V, SOT-323
D11B, D12,
D13, D15, D16,
D20, D21, D22,
D23, D24, D26,
D27, D28A,
D28B
BAT54-Y,
BAT54C
ST
BAT54CWFILM
28
4
D3A, D3B, D4,
D25
BAT54A
ST
BAT54AWFILMY
29
1
J3
CMP-00786551
TE Connectivity
9-2304372-9
30
1
X1
40 MHz
CX3225CA4000
Kyocera AVX
0D0HSSZ1
CX3225CA40000D0HSSZ1
31
1
X2
25MHz
CX3225CA2500
Kyocera AVX
0D0HSSZ1
CX3225CA25000D0HSSZ1
32
1
L4
DLW43MH201X DLW43MH201X
Murata
K2L
K2L
DLW43MH201XK2L
33
1
J2
Cannon 9M
Cannon 9M
WE
618009231221
34
1
L2
15uH
LPS6235-153
Coilcraft
LPS6235-153MRC
35
1
J1
JTAG
JTAG_PPC
WE
61201421621
36
6
R43A, R43B,
R43C, R43D,
R43E, R43F
0R0002
CurrentShunt_9
W_3921
Vishay
WSLP3921L2000FEA
37
2
R60A, R60B
0R0001
CurrentShunt_1
5W_5930
Vishay Foil
Resistors
Y14860R00010F9R
40 V, SOT-323
page 83/98
UM3594
Bill of materials
Item
Ref.
Part/value
Description
Manufacturer
Order code
2
R82A, R82B
0R0002
CurrentShunt_1
5W_5930
Vishay Foil
Resistors
Y14860R00020F9R
39
10
R54A, R54B,
R54C, R54D,
R54E, R54F,
R73A, R73B,
R93A, R93B
NTC, 10K
NTC
EPCOS
B57321V2103J060
40
1
CR2
PESD2ETH1GT
NEXPERIA
PESD2ETH1G-TR
41
1
Q2
BSS138
BSS138
NEXPERIA
BSS138PW,115
42
7
T1A, T1B, T1C,
T1D, T2A, T2B,
T3
BC847
BC847
NEXPERIA
BC847CW,115
43
1
T20
BC857
BC857
NEXPERIA
BC857CW,115
44
1
L1
74438367100
WE
74438367100
45
40
C1A, C1B, C1C,
C1D, C5A, C5B,
C5C, C5D,
C8A, C8B, C15,
C31A, C31B,
C31C, C31D,
C31E, C31F,
C41A, C41B,
C51A, C51B,
100nF
C58A, C58B,
C63, C64, C65,
C66, C67, C68,
C69, C70, C71,
C72, C74,
C109, C110,
C111, C112,
C114, C119
100nF/
MURATA
50V_10%_0603
GCJ188R71H104KA12D
46
7
C2A, C2B, C2C,
C2D, C9A, C9B, 1nF
C16
1nF/
MURATA
50V_10%_0603
GCJ188R71H102KA01D
32
C3A, C3B, C3C,
C3D, C4A, C4B,
C4C, C4D,
C10A, C10B,
C11A, C11B,
C17, C18,
C25A, C25B,
C25C, C25D,
220nF
C25E, C25F,
C35A, C35B,
C45A, C45B,
C54A, C54B,
C56A, C56B,
C87, C99,
C115, C116
220nF/
MURATA
50V_10%_0603
GCJ188R71H224KA01D
31
C6A, C6B, C6C,
C6D, C7A, C7B,
C7C, C7D,
C13A, C13B,
C14A, C14B,
C20, C21, C22, 10nF
C23, C32A,
C32B, C32C,
C32D, C32E,
C32F, C42A,
C42B, C52A,
10nF/
MURATA
50V_10%_0603
GCJ188R71H103KA01D
38
47
48
UM3594 - Rev 1
Q.ty
page 84/98
UM3594
Bill of materials
Item
Q.ty
Ref.
Part/value
Description
Manufacturer
Order code
C52B, C73,
C77, C79, C81,
C83
8
C12A, C12B,
C19, C75, C84, 2.2uF
C85, C92, C100
2.2uF/
TDK
16V_10%_0603
CGA3E1X7S1C225K080AE
44
C24A, C24B,
C24C, C24D,
C24E, C24F,
C27A, C27B,
C27C, C27D,
C27E, C27F,
C29A, C29B,
C29C, C29D,
C29E, C29F,
C30A, C30B,
C30C, C30D,
C30E, C30F,
C34A, C34B,
C37A, C37B,
C39A, C39B,
C40A, C40B,
C44A, C44B,
C47A, C47B,
C49A, C49B,
C50A, C50B,
C57A, C57B,
C113, C118
470nF
470nF/
TDK
50V_10%_0603
CGA3E3X7R1H474K080AE
51
41
C26A, C26B,
C26C, C26D,
C26E, C26F,
C28A, C28B,
C28C, C28D,
C28E, C28F,
C33A, C33B,
C33C, C33D,
C33E, C33F,
C36A, C36B,
C38A, C38B,
C43A, C43B,
C46A, C46B,
C48A, C48B,
C53A, C53B,
C59A, C59B,
C88, C89, C90,
C91, C106,
C108, C122,
C123, C124
1uF
1uF/
TDK
50V_10%_0603
CGA3E3X5R1H105K080AB
52
4
C60, C61,
C120, C121
10pF
10pF/
Kyocera AVX
50V_10%_0603
06035A100K4T2A
53
4
C76, C78, C80,
C82
47nF
47nF/
TDK
50V_10%_0603
CGA3E2X7R1H473K080AA
54
1
C117
4.7nF
4,7nF/
TDK
50V_10%_0603
CGA3E2X7R1H472K080AA
55
2
C105, C107
2,2uF
2,2uF/
TDK
50V_10%_0805
CGA4J3X7R1H225K125AE
56
9
C86, C93, C94,
C96, C97,
C101, C102,
C103, C104
10uF
10uF/
TDK
50V_10%_1206
CGA5L3X5R1H106K160AB
49
50
UM3594 - Rev 1
page 85/98
UM3594
Bill of materials
Item
Ref.
Part/value
Description
Manufacturer
Order code
57
1
L3
100uH
100uH/
0,15A_+50%/-3
0%_1812
TDK
ACT45B-101-2P-TL003
58
1
LED1
Red LED
LED/
RED_00603
WE
155060RS73200
59
4
LED2, LED8,
LED9, LED10
Orange LED
LED/
WE
ORANGE_0603
155060AS73200
60
5
LED3, LED4,
LED5, LED6,
LED7
Green LED
LED/
GREEN_0603
WE
155060GS73200
61
1
JUMP_3_PIN
JUMP_3_PIN
WE
609002115121
62
1
JP3
JUMP_3_PIN
JUMP_3_PIN
WE
61300311121
63
8
JP1A, JP1B,
JP1C, JP1D,
JP2A, JP2B,
JP2C, JP2D
JUMP_3_PIN
JUMP_3_PIN
PANASONIC
ERJ-3GEYJ473V
64
2
JP4, JP5
47k
JUMP_3_PIN
PANASONIC
ERJ-3GEYJ473V
65
9
R3A, R3B, R3C,
R3D, R17A,
330R
R17B, R31,
R101A, R101B
330R/
VISHAY
0.1W_5%_0603
CRCW0603330RJNEA
66
7
R1A, R1B, R1C,
R1D, R15A,
330R
R15B, R29
330R/
VISHAY
150V_1%_0805
CRCW0805330RFKEAHP
67
9
R2A, R2B, R2C,
R2D, R16A,
100R
R16B, R30,
R152, R153
100R/
PANASONIC
0.1W_5%_0603
ERJ-U03J101V
68
7
R4A, R4B, R4C,
R4D, R18A,
120R
R18B, R32
120R/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ121V
16
R5A, R5B, R5C,
R5D, R19A,
R19B, R28A,
R28B, R33,
4k7
R42, R127,
R154, R157,
R163, R164,
R192
4k7/0.1W_5%_
0603
PANASONIC
ERJ-U03J472V
90
R6A, R6B, R6C,
R6D, R7A, R7B,
R7C, R7D,
R10A, R10B,
R10C, R10D,
R11A, R11B,
R11C, R11D,
R20A, R20B,
R21A, R21B,
R22A, R22B,
R23A, R23B,
2k7
R24A, R24B,
R34, R35, R36,
R37, R38,
R48A, R48B,
R48C, R48D,
R48E, R48F,
R57A, R57B,
R57C, R57D,
R57E, R57F,
R58A, R58B,
2k7/0.1W_5%_
0603
PANASONIC
ERJ-3GEYJ272V
69
70
UM3594 - Rev 1
Q.ty
page 86/98
UM3594
Bill of materials
Item
Q.ty
Ref.
Part/value
Description
Manufacturer
Order code
R58C, R58D,
R58E, R58F,
R59A, R59B,
R59C, R59D,
R59E, R59F,
R67A, R67B,
R77A, R77B,
R78A, R78B,
R80A, R80B,
R87A, R87B,
R97A, R97B,
R98A, R98B,
R99A, R99B,
R102A, R102B,
R103A, R103B,
R104A, R104B,
R105A, R105B,
R106A, R106B,
R107A, R107B,
R156, R159,
R162, R193,
R194, R195,
R196
71
72
73
UM3594 - Rev 1
26
R8A, R8B, R8C,
R8D, R9A, R9B,
R9C, R9D, R46,
R52, R65,
R123, R129,
R130, R146,
15k
R147, R148,
R149, R150,
R151, R160,
R161, R169,
R185, R186,
R188
15k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ153V
38
R12A, R12B,
R12C, R12D,
R13A, R13B,
R13C, R13D,
R25A, R25B,
R26A, R26B,
R39, R40,
R49A, R49B,
R49C, R49D,
R49E, R49F,
R51A, R51B,
R51C, R51D,
R51E, R51F,
R68A, R68B,
R70A, R70B,
R88A, R88B,
R90A, R90B,
R108A, R108B,
R109A, R109B
5k6
5k6/0.1W_5%_
0603
PANASONIC
ERJ-3GEYJ562V
21
R14A, R14B,
R14C, R14D,
R27A, R27B,
R41, R50A,
R50B, R50C,
R50D, R50E,
R50F, R69A,
R69B, R89A,
R89B, R110A,
R110B, R155,
R165
180R
180R/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ181V
page 87/98
UM3594
Bill of materials
Item
74
75
76
77
78
UM3594 - Rev 1
Q.ty
Ref.
Part/value
Description
Manufacturer
Order code
44
R44A, R44B,
R44C, R44D,
R44E, R44F,
R47A, R47B,
R47C, R47D,
R47E, R47F,
R53A, R53B,
R53C, R53D,
R53E, R53F,
R61A, R61B,
R62A, R62B,
R63A, R63B,
R66A, R66B,
R72A, R72B,
R74A, R74B,
R79A, R79B,
R81A, R81B,
R83A, R83B,
R86A, R86B,
R92A, R92B,
R95A, R95B,
R100A, R100B
1R
1R/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ1R0V
33
R45A, R45B,
R45C, R45D,
R45E, R45F,
R55A, R55B,
R55C, R55D,
R55E, R55F,
R64A, R64B,
R75A, R75B,
R84A, R84B,
R94A, R94B,
R122, R128,
R166, R170,
R171, R173,
R174, R175,
R176, R179,
R180, R182,
R203
47k
47k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ473V
17
R56A, R56B,
R56C, R56D,
R56E, R56F,
R76A, R76B,
R85, R91,
R96A, R96B,
R134, R172,
R181, R190,
R191
10k
10k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ103V
12
R111, R112,
R113, R114,
R115, R116,
R117, R118,
R197A, R197B,
R198A, R198B
0R
0R/
PANASONIC
0.1W_5%_0603
ERJ-3GEY0R00V
20
R119, R120,
R121, R124,
R125, R126,
R131, R132,
R133, R135,
R136, R137,
R139, R140,
R141, R184,
R204, R205,
R206A, R206B
47R
47R/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ470V
page 88/98
UM3594
Bill of materials
Item
Ref.
Part/value
Description
Manufacturer
Order code
79
3
R138, R142,
R202
1K5
1k5/0.1W_5%_
0603
PANASONIC
ERJ-U03J152V
80
4
R143, R144,
R145, R183
100k
100k/
PANASONIC
0.1W_5%_0603
ERJ-U03J104V
81
3
R158, R167,
R168
3k3
3k3/0.1W_5%_
0603
PANASONIC
ERJ-U03J332V
82
3
R177, R178,
R187
1k
1k/
PANASONIC
0.1W_5%_0603
ERJ-U03J102V
83
1
R189
30k
30k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ303V
84
1
R199
360k
360k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ364V
85
2
R200, R201
200k
200k/
PANASONIC
0.1W_5%_0603
ERJ-3GEYJ204V
86
1
C62
4,7uF
4,7uF/
TDK
16V_10%_0805
CGA4J3X7R1C475K125AE
10
ZD1A, ZD1B,
ZD1C, ZD1D,
ZD1E, ZD1F,
ZD2A, ZD2B,
ZD3A, ZD3B
5,6V
5,6V/SOT-323
BZB784-C5V6
87
UM3594 - Rev 1
Q.ty
Nexperia
page 89/98
UM3594
Board versions
9
Board versions
Table 19. STEVAL-PDUBV1 versions
Finished good
STV$PDUBV1A (1)
Schematic diagrams
Bill of materials
STV$PDUBV1A schematic diagrams
STV$PDUBV1A bill of materials
1. This code identifies the STEVAL-PDUBV1 evaluation board first version.
UM3594 - Rev 1
page 90/98
UM3594
Regulatory compliance information
10
Regulatory compliance information
Notice for US Federal Communication Commission (FCC)
For evaluation only; not FCC approved for resale
FCC NOTICE - This kit is designed to allow:
(1) Product developers to evaluate electronic components, circuitry, or software associated with the kit to
determine whether to incorporate such items in a finished product and
(2) Software developers to write software applications for use with the end product.
This kit is not a finished product and when assembled may not be resold or otherwise marketed unless all
required FCC equipment authorizations are first obtained. Operation is subject to the condition that this product
not cause harmful interference to licensed radio stations and that this product accept harmful interference. Unless
the assembled kit is designed to operate under part 15, part 18 or part 95 of this chapter, the operator of the kit
must operate under the authority of an FCC license holder or must secure an experimental authorization under
part 5 of this chapter 3.1.2.
Notice for Innovation, Science and Economic Development Canada (ISED)
For evaluation purposes only. This kit generates, uses, and can radiate radio frequency energy and has not been
tested for compliance with the limits of computing devices pursuant to Industry Canada (IC) rules.
À des fins d'évaluation uniquement. Ce kit génère, utilise et peut émettre de l'énergie radiofréquence et n'a pas
été testé pour sa conformité aux limites des appareils informatiques conformément aux règles d'Industrie Canada
(IC).
Notice for the European Union
This device is in conformity with the essential requirements of the Directive 2014/30/EU (EMC) and of the
Directive 2011/65/EU (RoHS II), including subsequent revisions and additions, as well as amended by the
Delegated Directive 2015/863/EU (RoHS III).
Notice for the United Kingdom
This device is in conformity with the relevant provisions of the following EU legislation recognized by the United
Kingdom:
•
•
UM3594 - Rev 1
Electromagnetic Compatibility Regulations 2016 (S.I. 2016/1091) implementing Directive 2014/30/EU
(EMC)
The Restriction of the Use of Certain Hazardous Substances in Electrical and Electronic Equipment
Regulations 2012 (RoHS) (S.I. 2012/3032) implementing Directive 2011/65/EU (RoHS II), including
subsequent revisions and additions, as well as amended by the Delegated Directive 2015/863/EU (RoHS
III).
page 91/98
UM3594
Revision history
Table 20. Document revision history
UM3594 - Rev 1
Date
Revision
31-Mar-2026
1
Changes
Initial release.
page 92/98
UM3594
Contents
Contents
1
2
3
4
Safety information and on board protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1
Reverse polarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2
Short-to-ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3
ISO pulses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4
ESD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5
STi2Fuse protection behind onboard high-side drivers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Market availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
2.1
STEVAL-PDUBV1 board hardware availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2
STEVAL-PDUBV1 software availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
PDU-B application basic working modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1
STEVAL-PDUBV1 input stage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2
STEVAL-PDUBV1 Assembly mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3
STEVAL-PDUBV1 Normal mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4
STEVAL-PDUBV1 Parking mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5
Simple STEVAL-PDUBV1 usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
LEDs available on STEVAL-PDUBV1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2
STEVAL-PDUBV1 operating range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Hardware overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11
4.1
STEVAL-PDUBV1 conceptual functional block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2
STEVAL-PDUBV1 main hosted devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3
STEVAL-PDUBV1 connector overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4
5
3.5.1
4.3.1
VCCA and VCCB power input connectors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.2
GND connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.3
VCC_EXT connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.4
Power output connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.5
Low current connectors for 5 A and 10 A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.6
CAN communication connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.7
Ethernet 100BASETX connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.8
UART connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Main devices’ description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1
Board’s main microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2
STi2Fuse devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.3
L99SP08 standby companion chip with smart P-channels . . . . . . . . . . . . . . . . . . . . . . . . 26
Hardware test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
5.1
UM3594 - Rev 1
Test setup environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
page 93/98
UM3594
Contents
5.2
Test of sleep, wake up, startup time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3
Test of I2t functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.4
Cascaded channels test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.1
6
VNF1248F → VNF1248F + VNF1248F. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.5
Thermal design evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6
VNF1248F bypass switch operation test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.7
P-channel companion chip test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Software description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
6.1
STEVAL-PDUBV1 firmware basic startup steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2
Driver layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2.1
6.3
6.4
Driver layer implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Service layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.1
PDUB manager task PDUB_mng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.2
eFuse manager task (eFUSE_mng) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.3.3
PMIC_mng of the service layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.4
COMM_mng of the service layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.3.5
ADCWDT_mng of the service layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3.6
ASS_mng of the service layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.7
PARK_mng of the service layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.8
ERR_mng of the service layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3.9
UDS_mng of the service layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
STEVAL-PDUBV1 software state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.1
Normal mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4.2
Parking mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5
Task scheduling and duration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.6
How to download STSW-PDUB-UDS image on STEVAL-PDUBV1 . . . . . . . . . . . . . . . . . . . . 67
7
Schematic diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
8
Bill of materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
9
Board versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
10
Regulatory compliance information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
List of tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
List of figures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
UM3594 - Rev 1
page 94/98
UM3594
List of tables
List of tables
Table 1.
Table 2.
Table 3.
Table 4.
Table 5.
Table 6.
Table 7.
Table 8.
Table 9.
Table 10.
Table 11.
Table 12.
Table 13.
Table 14.
Table 15.
Table 16.
Table 17.
Table 18.
Table 19.
Table 20.
LED functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
LED status at startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Power Rail A current capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Power Rail B current capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Power Rail A 8-pin connector channel details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Power Rail B 8-pin connector channel details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Pin description of the CAN standard 9-pin DSUB male connector. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Shunt resistor value per channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Overcurrent threshold per shunt value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Latch-off times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Device-dependent channel parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Supported CAN messages and IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Summary table for ERR interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ERR diagnosable errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
SID codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Examples of DID codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
UDS message examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
STEVAL-PDUBV1 bill of materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
STEVAL-PDUBV1 versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
UM3594 - Rev 1
page 95/98
UM3594
List of figures
List of figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Figure 8.
Figure 9.
Figure 10.
Figure 11.
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
Figure 19.
Figure 20.
Example of a vehicle power distribution system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Basic STEVAL-PDUBV1 power-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
LED positions on the board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
LEDs at board power-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
STEVAL-PDUBV1 possible lab usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
STEVAL-PDUBV1 conceptual block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
STEVAL-PDUBV1 - main hosted devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
STEVAL-PDUBV1 - connector overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
G&H 8-pin connector (top view) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
G&H 8-pin connector (side view). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Power Rail A 8-pin connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Power Rail A 8-pin connector layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Power Rail B 8-pin connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Power Rail B 8-pin connector layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
CAN connector (front view) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Ethernet connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Ethernet, CAN, UART communication connectors on STEVAL-PDUBV1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Internal block diagram from SPC58NG84E7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Basic power blocks interaction in STEVAL-PDUBV1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Test setup schematic block. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 21.
VNF1248F STi2Fuse regular functionality test - tnom = 1s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 22.
VNF1248F STi2Fuse regular functionality test - tnom = 101 s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 23.
VNF9D1M5Q STi2Fuse regular functionality test - tnom = 1 s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 24.
VNF9D1M5Q STi2Fuse regular functionality test - tnom = 86 s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 25.
VNF9D5SF STi2Fuse regular functionality test - tnom = 1 s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 26.
Figure 27.
Figure 28.
Figure 29.
Figure 30.
Figure 31.
Figure 32.
Figure 33.
Figure 34.
Figure 35.
Figure 36.
Figure 37.
Figure 38.
Figure 39.
Figure 40.
Figure 41.
Figure 42.
Figure 43.
Figure 44.
Figure 45.
VNF9D5SF STi2Fuse regular functionality test - tnom = 86 s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Soft overload event on cascaded e‑fuse (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Soft overload event on cascaded e‑fuse (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Hard short circuit event on cascaded e‑fuse (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Hard short circuit event on cascaded e‑fuse (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
VNF1248F @ 200 A (OUTA1) thermal image, TFET = 57.5°C (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF1248F @ 200 A (OUTA1) thermal image, TFET = 57.5°C (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF1248F @ 150 A (OUTA2) thermal image, TFET = 58.5°C (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF1248F @ 150 A (OUTA2) thermal image, TFET = 58.5°C (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF1248F @ 100 A (OUTA4) thermal image, TFET = 58°C (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF1248F @ 100 A (OUTA4) thermal image, TFET = 58°C (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VNF9D1M5Q @ 27 A (OUTA6) thermal image (1 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF9D1M5Q @ 27 A (OUTA6) thermal image (2 of 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF9Q20SF @ 5 A (OUTA13) thermal image (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF9Q20SF @ 5 A (OUTA13) thermal image (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF9D5SF @ 10 A (OUTB13) thermal image (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF9D5SF @ 10 A (OUTB13) thermal image (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNF1248F bypass switch test - OUTA1. Zoomed version on the right (1 of 2) . . . . . . . . . . . . . . . . . . . . . . . . 35
VNF1248F bypass switch test - OUTA1. Zoomed version on the right (2 of 2) . . . . . . . . . . . . . . . . . . . . . . . . 35
VNF1248F bypass switch test - OUTA1. Current step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Figure 46.
VNF9D1M5Q: P-channel companion chip activating hybrid STi2Fuse device . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 47.
Figure 48.
Figure 49.
Figure 50.
Figure 51.
VNF9D5SF: P-channel companion chip activating monolithic STi2Fuse device . . . . . . . . . . . . . . . . . . . . . . . 36
Stack for L99SP08 in driver layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Nested function calls from service layer to MCU peripheral for L99SP08 channel 0 activation . . . . . . . . . . . . . 39
Service layer key components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Example of channel enablement request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
UM3594 - Rev 1
page 96/98
UM3594
List of figures
Figure 52.
Figure 53.
Figure 54.
Figure 55.
Figure 56.
Figure 57.
Figure 58.
Figure 59.
Figure 60.
Figure 61.
Figure 62.
Figure 63.
Figure 64.
Figure 65.
Figure 66.
Figure 67.
Figure 68.
Figure 69.
Figure 70.
eFuse module functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
eFuse module diagnostics and monitoring functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Example of communication with PMIC module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
PMIC module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
COMM module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Example of hwo to turn on an e-fuse channel via CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
example of how the COMM receive task dispatches the message to the eFuse module . . . . . . . . . . . . . . . . . 49
ADCWDT module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
ASS module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Park module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
ERR module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
UDS module functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Application software state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
eFuse task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
PMIC task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
ADCWDT task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
ERR task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
COMMRx task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Park task timing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 71.
Figure 72.
Figure 73.
Figure 74.
Figure 75.
Figure 76.
Figure 77.
Figure 78.
Figure 79.
Figure 80.
Figure 81.
Figure 82.
Figure 83.
Figure 84.
Figure 85.
Figure 86.
Sti2Fuse PDUB software timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
All task timing diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
STEVAL-PDUBV1 circuit schematic (1 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
STEVAL-PDUBV1 circuit schematic (2 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
STEVAL-PDUBV1 circuit schematic (3 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
STEVAL-PDUBV1 circuit schematic (4 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
STEVAL-PDUBV1 circuit schematic (5 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
STEVAL-PDUBV1 circuit schematic (6 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
STEVAL-PDUBV1 circuit schematic (7 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
STEVAL-PDUBV1 circuit schematic (8 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
STEVAL-PDUBV1 circuit schematic (9 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
STEVAL-PDUBV1 circuit schematic (10 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
STEVAL-PDUBV1 circuit schematic (11 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
STEVAL-PDUBV1 circuit schematic (12 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
STEVAL-PDUBV1 circuit schematic (13 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
STEVAL-PDUBV1 circuit schematic (14 of 14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
UM3594 - Rev 1
page 97/98
UM3594
IMPORTANT NOTICE – READ CAREFULLY
STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST
products and/or to this document at any time without notice.
In the event of any conflict between the provisions of this document and the provisions of any contractual arrangement in force between the purchasers and
ST, the provisions of such contractual arrangement shall prevail.
The purchasers should obtain the latest relevant information on ST products before placing orders. ST products are sold pursuant to ST’s terms and
conditions of sale in place at the time of order acknowledgment.
The purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of
the purchasers’ products.
No license, express or implied, to any intellectual property right is granted by ST herein.
Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product.
If the purchasers identify an ST product that meets their functional and performance requirements but that is not designated for the purchasers' market
segment, the purchasers shall contact ST for more information.
ST and the ST logo are trademarks of ST. For additional information about ST trademarks, refer to www.st.com/trademarks. All other product or service names
are the property of their respective owners.
Information in this document supersedes and replaces information previously supplied in any prior versions of this document.
© 2026 STMicroelectronics – All rights reserved
UM3594 - Rev 1
page 98/98
">