你好
我正在使用 S32E288-975EVB，我正在尝试使用 R52_0 内核作为启动内核，并从 QSPI 闪存中运行我的应用程序代码。
使用 IVT 工具，我可以成功地使用 M33 SMU 内核从闪存中启动我的应用程序代码。当我尝试在 R52_0 项目 IVT 工具中使用原始二进制文件作为应用程序引导加载程序时，出现错误 " 所选二进制文件的大小大于最大 RAM 大小 "。问题很可能不在于大小，因为我可以使用 S32 Debug Probe 成功启动我的代码，而代码本身只是 LED 闪烁一次。
我还可以看到二进制文件一开始大部分是空的。在 0x0-0x20 处有一些数据然后在 0x0098_0000 之前只是零，这是有道理的，因为我可以从我的链接器文件中看出 动态随机存取存储器\(DRAM\) 从 0x3178_0000 开始，CRAM 从 0x3210_0000 开始（0x3210_0000-0x3178_0000 = 0x0098_0000）：
/*
* Target device: This linker is demo and it is using for device S32Z2xx and S32E2xx only
* Target core: This linker target application which is running on RTU0 clusters for both split-lock and lockstep mode.
* Linker support for application running on single/multicore within RTU0 cluster by single image file. It need to align with MPU default setup in core.c as well.
* Memory setting: Local ram of RTU0 (CRAM and DRAM)
*/
/*
* GCC Linker Command File:
* 0x30000000 0x3000FFFF 65536 ; RTU0_R52_0_TCM_A
* 0x30100000 0x30103FFF 16384 ; RTU0_R52_0_TCM_B
* 0x30200000 0x30203FFF 16384 ; RTU0_R52_0_TCM_C
* 0x30400000 0x3040FFFF 65536 ; RTU0_R52_1_TCM_A
* 0x30500000 0x30503FFF 16384 ; RTU0_R52_1_TCM_B
* 0x30600000 0x30603FFF 16384 ; RTU0_R52_1_TCM_C
* 0x30800000 0x3080FFFF 65536 ; RTU0_R52_2_TCM_A
* 0x30900000 0x30903FFF 16384 ; RTU0_R52_2_TCM_B
* 0x30A00000 0x30A03FFF 16384 ; RTU0_R52_2_TCM_C
* 0x30C00000 0x30C0FFFF 65536 ; RTU0_R52_3_TCM_A
* 0x30D00000 0x30D03FFF 16384 ; RTU0_R52_3_TCM_B
* 0x30E00000 0x30E03FFF 16384 ; RTU0_R52_3_TCM_C
* 0x31780000 0x317C0000 262144 ; RTU0_DRAM_0 (Fast Data 0)
* 0x317C0000 0x31800000 262144 ; RTU0_DRAM_1 (Fast Data 1)
* 0x31800000 0x31880000 524288 ; RTU0_DRAM_2 (Fast Data 2)
* 0x32100000 0x321FFFFF 1048575 ; RTU0_CRAM_0 (Code ram 0)
* 0x32200000 0x322FFFFF 1048575 ; RTU0_CRAM_1 (Code ram 1)
* 0x32300000 0x323FFFFF 1048575 ; RTU0_CRAM_2 (Code ram 2)
* 0x32400000 0x324FFFFF 1048575 ; RTU0_CRAM_3 (Code ram 3)
* 0x32500000 0x325FFFFF 1048575 ; RTU0_CRAM_4 (Code ram 4)
* 0x32600000 0x326FFFFF 1048575 ; RTU0_CRAM_5 (Code ram 5)
* 0x32700000 0x327FFFFF 1048575 ; RTU0_CRAM_6 (Code ram 6)
* 0x79900000 0x799FFFFF 1048575 ; RTU0_CRAM_0_AXIF (Code ram 0 AXIF)
* 0x79A00000 0x79AFFFFF 1048575 ; RTU0_CRAM_1_AXIF (Code ram 1 AXIF)
* 0x79B00000 0x79BFFFFF 1048575 ; RTU0_CRAM_2_AXIF (Code ram 2 AXIF)
* 0x79C00000 0x79CFFFFF 1048575 ; RTU0_CRAM_3_AXIF (Code ram 3 AXIF)
* 0x79D00000 0x79DFFFFF 1048575 ; RTU0_CRAM_4_AXIF (Code ram 4 AXIF)
* 0x79E00000 0x79EFFFFF 1048575 ; RTU0_CRAM_5_AXIF (Code ram 5 AXIF)
* 0x79F00000 0x79FFFFFF 1048575 ; RTU0_CRAM_6_AXIF (Code ram 6 AXIF)
* 0x4E400000 0x4E400FFF 4096 ; AE_SRAM
*/我还尝试使用 .elf据我所知，格式化为 IVT 工具中的应用程序引导加载程序，它通过定义长度的 RAM 起始部分基本上有助于减少未使用的空间，并且应该减少二进制文件中未使用的空间量，但我无法让它按预期工作。
现在我有三个主要问题：
- 我能否在 IVT 工具中为我的应用程序引导加载程序使用原始二进制版本，或者 bootROM 能否正确解释 .elf 格式？
如果我不能使用 .elf 格式，那么我怎样才能让我的原始二进制文件可用呢？ - 当我尝试从 R52_0 内核启动时，我应该将什么设置为 RAM 入口指针。数据表指出 " 如果启动目标为 1，则允许下载应用程序的 SRAM 范围在 RTU0 Code RAM 区域内，地址范围为 3210_0000h 到 327f_fffh。"，所以它必须在这个范围内，但是应该将其设置为 Reset_Handler、ETABLE 或 VTABLE 还是完全设置为其他值？对于 M33 SMU 内核，我必须将其设置为 VTABLE 的起点，然后 VTABLE 将指向 Reset_Handler，但对于 R 内核，该如何操作？
- 我觉得我的地址有些不匹配。例如，我可以从映射文件中看到，我的异常向量表应该位于 0x3210_0360：
*(.extable)
.extable 0x32100340 0x20 ./Project_Settings/Startup_Code/Vector_Table.o
0x32100340 ETABLE
0x32100360 . = ALIGN (0x4)
0x32100360 __exceptions_ram_end = .
0x32100360 __interrupts_ram_start = .
*(.intc_vector)
.intc_vector 0x32100360 0xf04 ./Project_Settings/Startup_Code/Vector_Table.o
0x32100360 DEFAULT_VECTOR
0x32101264 . = ALIGN (0x4)
0x32101264 __interrupts_ram_end = .
0x32101264 . = ALIGN (0x4)
*(.startup)
0x32101264 . = ALIGN (0x4)由于我没有定义任何中断，所以每个条目都指向 undefined_handler 是有道理的，我应该能够从我的 raw_binary 中看到这一点：
但是 undefined_handler 的地址在映射文件中设置为 0x3210_14d0：
0x321014ce HVC_Handler
0x321014d0 undefined_handler
*fill* 0x321014d2 0x2
.systeminit 0x321014d4 0x124 ./Project_Settings/Startup_Code/system.o
这是否会成为一个问题，或者说，一个误差是否会在其他地方得到补偿？
嗨，HiddenSquid
请将您的案例发布到以下链接：https://support.nxp.com ?
然后，复制此链接并在支持系统中@乔伊。更有信心与你分享有关从 QSPI 启动 R52_0 的信息。
BR
乔伊
嗨，HiddenSquid
感谢您与我们联系。
我已收到您的问题，并将帮助您进行检查。
BR
乔伊
嗨，HiddenSquid
我还可以看到二进制文件一开始大部分是空的。在 0x0-0x20 处有一些数据然后直到 0x0098_0000 才是零，这是有道理的，因为我可以从我的链接器文件中看出 动态随机存取存储器(DRAM) 从 0x3178_0000 开始，CRAM 从 0x3210_0000 开始（0x3210_0000-0x3178_0000 = 0x0098_0000 = 0x0098_0000）
>>>就 RTD R52 示例项目而言，编译后的 bin 文件大小接近 8MB，太大了。原因是链接器文件将代码内存定义为从 0x3210000 (RTU0_CRAM_0) 开始，将数据 RAM 定义为从 0x31780000 (RTU0_DRAM_0) 开始，编译器会自动在这些地址范围内填写无效数据以保持二进制内容的连续性。
为了减小编译后的二进制文件的大小，您需要修改链接器脚本和启动代码，以便在 RTU0_CRAM 中重新部署数据 RAM，这样二进制文件就不会因数据填充无效而出现较大的地址间隙。
BR
乔伊