可以试试查一下错误信息，感觉像是JVM导致，

“openjdk platform binary 未响应” 通常是由于 Java 应用程序占用过多系统资源、文件路径问题、软件冲突或 JVM 配置不合理等原因导致的，可参考以下方法解决：

查看系统资源占用情况：通过任务管理器（Windows 系统可按 Ctrl + Shift + Esc 组合键打开），查看是否有进程占用了过多的 CPU、内存等系统资源。如果发现与 Java 相关的进程占用资源过高，可能会导致 “openjdk platform binary 未响应”。
停止占用资源较多的进程：确定是哪个进程占用资源过多后，在任务管理器中找到该进程，点击 “结束任务” 来停止它，或者使用命令 “kill -9 < 进程 ID>”（Linux 系统）来终止进程，释放系统资源。
检查文件路径：若使用特定软件（如 STM32CubeMX）时出现该问题，需检查项目所在目录或文件名称中是否存在中文字符或特殊符号，若有则将项目存储位置更改为仅包含英文字符和数字的路径。
避免多任务冲突：如果是在多个软件同时运行时出现此问题，可能是资源争用或锁死导致的。例如在 STM32CubeMX 执行代码生成过程中，不要同时操作 Keil 等其他软件。若已出现未响应情况，可通过任务管理器强制终止相关 Java 进程，然后重新启动软件和相关工作流程。
调整 JVM 配置参数：可手动修改启动配置以增加可用内存限额。例如对于 STM32CubeMX，可修改其安装根目录下的快捷方式目标字段中的命令行选项部分，加入 “-J -Xms512m -J -Xmx1024m”，将初始最小堆尺寸定义为 512MB，最大堆尺寸设置为 1GB。
更新软件版本：官方通常会持续改进产品兼容性和稳定性，可将相关软件更新到最新的稳定发行版，以修复已知缺陷并优化性能，有可能解决该未响应问题。
【 在 veriloghdl 的大作中提到: 】
: Platform designer一上午运行十次能起来一次
--
FROM 222.129.54.*

有没有可能不是cpu的问题？

【 在 veriloghdl 的大作中提到: 】
: 从sopcbuilder到qsys到platformdesigner一直是基于java，以前很少这么崩溃
: 谁知道会越做越差
: 基本的测试都没有就发布

- 来自 水木说
--
FROM 183.227.100.*

如果实在怀疑 可以升级换个新版本试试
【 在 veriloghdl 的大作中提到: 】
: 从sopcbuilder到qsys到platformdesigner一直是基于java，以前很少这么崩溃
: 谁知道会越做越差
: 基本的测试都没有就发布
--
FROM 222.129.54.*