1. Issues with Headless Execution and CLI Commands
- GUI Opens with CLI Flags: Certain CLI flags designed for automation still launch the AWT/Swing GUI components, which causes failures in headless environments (like Docker containers or typical Linux servers).
- Specific Example: The -P flag (Package Manager) throws a java.awt.AWTError: Can't connect to X11 window server error because it requires a display.
- Expected Behavior: All package management and code generation functions should have a truly headless (no GUI dependencies) CLI option that works universally in server environments.
- Lack of Clear CLI Documentation: Documentation for reliable, headless CLI commands (like swmgr install) is sparse or non-existent in the official user manual (UM1718), leading to trial-and-error with internal commands.
2. Issues with Offline Package Management and Database Indexing
- Discrepancy Between Repository and Database Paths: Manually placing firmware package ZIP files into the designated repository path (/root/STM32Cube/Repository/) is insufficient. The application fails to automatically index these files into its internal database path (/root/STM32CubeMX/db/mcu/).
- Resulting Error: This leads to the persistent error: [ERROR] .../STM32H5xx_I2c.ioc.xml doesn't exist and MCU is unknown, even when the package files are physically present in the correct repository location.
- Forced GUI Interaction for Installation: A functional installation and database registration appears to require running the GUI (either natively or via X11 forwarding) at least once to formally "install" the packages, which is a major hurdle for automated Docker builds and headless servers.
3. Network and Certificate Handling Issues
- Persistent Network Checks in Offline Mode: Even when running CubeMX with the -offline flag, internal threads (IntegrityCheckThread, ThirdPartyUpdater) still attempt network connections during startup.
- PKIX/Certificate Errors (Proxy Issues): These background checks often fail in corporate environments using proxies that intercept SSL certificates, resulting in PKIX path building failed errors.
- Startup Delays: The network timeouts and retries caused by the certificate errors add significant, unnecessary delays to startup time in automated scripts.
4. Docker Specific Issues
- Complex Dockerfile Execution: Automating the installation process within a Dockerfile is fragile due to the reliance on X11 forwarding (Xvfb) within a single RUN command, leading to permission and execution errors (/bin/sh: 1: : Permission denied).
