Troubleshooting

Frequently Asked Questions

Does the Charge SOM have a CE certification?

Currently, the Charge SOM does not have CE certification yet.

Does the Charge SOM have Wi-Fi support?

The Charge SOM does not have built-in Wi-Fi support, but it provides suitable interfaces (SDIO / USB 2.0) via its connectors. For instance, the Charge SOM Single Channel DC Carrier Board provides a mini PCIe connector, which is connected to USB.

Is it possible to use the Charge SOM as an EV simulator?

The Charge SOM hardware is not designed to be used as an EV simulator. Please refer to our website for more suitable products.

I want to control EVerest via CAN, how can I achieve this?

Currently, no such EVerest module is available, so you will need to implement it yourself.

However, there are at least DC power supply modules and a library, both of which use the CAN interface. This might help as a starting point.

How can I access the GPIOs under Linux?

Since the GPIO sysfs interface /sys/class/gpio has been deprecated since Linux 4.8, we recommend the usage of chardev GPIO and libgpiod. The modification of the bias settings via libgpiod is not yet implemented, so it needs to be done via device tree.

My application depends on libgpiod but requires GPIO chip and line, how can I figure them out?

For applications that do not support GPIO line names, you can use the following:

root@chargesom:/# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 512-541, parent: platform/43810000.gpio, 43810000.gpio:
gpio-512 (SPI_PLC_nCS0        |spi1 CS0            ) out hi ACTIVE LOW
gpio-519 (                    |int                 ) in  lo IRQ
...

The GPIO line is calculated as follows:

Line = GPIO number - GPIO chip offset
Line = 519         - 512
Line = 7

What is the difference between CHSTOP_IN and SAFETY_ESTOPx?

The signal CHSTOP_IN is connected to the i.MX93 SoC and can be used to gracefully stop the charging process. It is not designed for time-critical use cases. Currently, there is no EVerest module that can handle this signal. This work is pending.

To implement real-time emergency stop behavior, use the SAFETY_ESTOPx signals, which are connected to the safety processor.

How can I list the available UARTs?

All UARTs of the i.MX93 are handled by the fsl-lpuart driver, so the following command should list all available UARTs. Please keep in mind that Linux starts counting from zero (ttyLP0 = UART1, …).

root@chargesom:/# cat /proc/tty/driver/fsl-lpuart
serinfo:1.0 driver revision:
0: uart:FSL_LPUART mmio:0x44380010 irq:17 tx:9932 rx:0 RTS|CTS|DTR|DSR|CD
2: uart:FSL_LPUART mmio:0x42570010 irq:18 tx:12966 rx:26572 RTS|CTS|DTR|DSR|CD
3: uart:FSL_LPUART mmio:0x42580010 irq:19 tx:936 rx:617 RTS|CTS|DTR|DSR|CD
4: uart:FSL_LPUART mmio:0x42590010 irq:20 tx:0 rx:0 CTS|DSR|CD

How can I list the available I²C interfaces?

All I²C interfaces are available via I²C device driver. Please keep in mind that Linux starts counting from zero (i2c-0 = I2C1, …).

root@chargesom:/# i2cdetect -l
i2c-0   i2c             44340000.i2c                            I2C adapter
i2c-1   i2c             44350000.i2c                            I2C adapter
i2c-2   i2c             42530000.i2c                            I2C adapter

How can I print the current pin/pad control settings (e.g. bias, drive strength)?

The current PAD control settings are available under Linux only via debugfs, but this requires an equivalent pinctrl setting within the device tree:

root@chargesom:/# cat /sys/kernel/debug/pinctrl/443c0000.pinctrl/pinconf-pins
Pin config settings per pin
Format: pin (name): configs
pin 0 (IMX93_IOMUXC_DAP_TDI): 0x31e
...

Which LVDS displays have been tested with the Charge SOM EVB?

The Distec DD-0700-MC01 (7 inch, 800x480 resolution) has been tested with the Charge SOM EVB.

I like to create my own DT overlay. Is there an example?

Yes, please have a look at this commit .

Where can I find the device tree sources of the Charge SOM?

The device tree sources of the Charge SOM are divided into multiple layers:

Part

Level

Layer

Filename

i.MX93

0

SoC

imx93.dtsi

phyCORE-i.MX93

1

SoM

imx93-phycore-som.dtsi

Charge SOM

2

SoM

imx93-charge-som.dtsi

Charge SOM Single Channel DC Carrier Board

3

Board

imx93-charge-som-dc-evb.dts

UART7 overlay

4

Overlay

imx93-charge-som-uart7.dtso

How can I access the EVerest admin panel on Charge SOM?

Currently, the Charge SOM does not have the EVerest admin panel integrated. Please use your development environment to set up your configuration file. Alternatively, you can use a plain text editor.

How should TLS or Plug & Charge private keys be protected?

For TLS and especially Plug & Charge, private keys should be protected according to the requirements of the certificate authority or certificate management system. In many production environments, this means using hardware-backed key storage such as a TPM, HSM, or comparable technology.

Charge SOM includes an integrated TPM to support secure storage of TLS and Plug & Charge private keys. For more information about using the TPM and implementing a production Plug & Charge scenario, please contact chargebyte support so that key storage and certificate handling can be aligned with your requirements.

Does EVerest on Charge SOM support ISO 15118-20 yet?

The required module for ISO 15118-20 has been included in the image since the Charge SOM EVerest release 0.2.0. Please note that the implementation is still under development and integrated into the image only for test purposes.

EVerest integrates the libiso15118 library to provide support for ISO 15118-20. Here you can find more information about the current status of the ISO 15118-20 implementation. Please note, however, that the range of functions described in the linked libiso15118 library documentation may not correspond to those already integrated in EVerest, as the library has not yet been fully integrated. Implementation gaps may exist, particularly in the case of BPT (bidirectional power transfer) functionality.

How do I set up OCPP 2.0.1 on Charge SOM with EVerest?

To support OCPP 2.0.1, the EVerest OCPP201 module must be integrated into the EVerest configuration. The OCPP 2.0.1 and 2.1 tutorial already contains information about the module parameters, the provided and required interfaces, and the initial creation of the OCPP database.

The most important points are summarised here:

  1. The OCPP201 module must be included in your EVerest configuration.

  2. The CbSystem module can be used to fulfill the requirement of the system interface.

  3. While configuring the OCPP 2.0.1 module, ensure that you are using OCPP configuration and database paths which are covered by the update mechanism. The following paths are recommended:

    • CoreDatabasePath: /var/lib/everest/ocpp201

    • DeviceModelDatabasePath: /var/lib/everest/ocpp201/device_model_storage.db

    • DeviceModelConfigPath: /var/lib/everest/ocpp201/component_config

    Otherwise, if you don’t want to use a persistent storage, you can also deploy those files in your RAUC image.

  4. The CoreDatabasePath is used, among other things, to store OCPP transaction data.

  5. The OCPP 2.0.1 device model initialization is done automatically by the OCPP201 module after the first start of EVerest. The database is stored at the DeviceModelDatabasePath.

  6. The component config files are stored in the DeviceModelConfigPath. Component config files are used to initialize or update the device model database. To update a component config file, just place a component config file in the same directory structure in the DeviceModelConfigPath and change the values accordingly. Important keys of the component config files are:

    • standardized/InternalCtrlr.json: ChargePointId: In “attributes” adapt the “value” key to configure the ChargePointId. Used to identify the Charging Station.

    • standardized/InternalCtrlr.json: NetworkConnectionProfiles: In “attributes” adapt the “ocppCsmsUrl” key. The URL in “ocppCsmsUrl” is used to connect to the CSMS.

    • standardized/SecurityCtrlr.json: SecurityCtrlrIdentity: In “attributes” adapt the “value” key to configure the SecurityCtrlrIdentity. It is the Charging Station identity.

    For further information about the device model initialization, please refer to the libocpp documentation.

I tried to compile chargebyte’s Hardware EVerest Modules, but it fails to build. How can I fix this?

The EVerest mainline development is very dynamic and does not guarantee stable APIs across EVerest modules. Therefore, after almost every EVerest release, chargebyte needs to adapt its modules to the latest API changes.

Please have a look at the compatibility matrix to see which EVerest release works with which chargebyte EVerest modules release.

I would like to implement a custom Modbus device in EVerest. Where should I start?

EVerest already has a module that takes care of Modbus communication. Please have a look at SerialCommHub and let your module interact with this module via the serial_communication_hub interface.

Contact

Support

EVerest is an open-source project with a lot of modules, which is supported by a big community. chargebyte is an active part of this community. However chargebyte is not able to provide support for every aspect of EVerest. In order to get quick answers, here are some suggestions:

Do you have general questions about EVerest, please use the EVerest community’s Zulip.

Do you have questions about the chargebyte BSP (incl. Yocto), please use our support desk.

Note

Before submitting a support request, make sure that all relevant log files have been captured. The chapter Logging and Debugging describes the debugging options EVerest offers and shows which logs are relevant for the respective case.

Address

chargebyte GmbH

Bitterfelder Straße 1-5

04129 Leipzig

Germany

Website: https://chargebyte.com