YunTu Forum

/*

Copyright 2020-2025 Yuntu Microelectronics Co., Ltd. All rights reserved. SPDX-License-Identifier: BSD-3-Clause @file yt_linker.ld @brief

*/

/* MEMORY MAP /
MEMORY
{
IVT (RX) : ORIGIN = 0x0, LENGTH = 0x400
TEXT (RX) : ORIGIN = 0x400, LENGTH = 0x7bc00
DTC (RX) : ORIGIN = 0x7c000, LENGTH = 0x1000
DTC_BACKUP (RX) : ORIGIN = 0x7d000, LENGTH = 0x1000
INF (RX) : ORIGIN = 0x7e000, LENGTH = 0x1000
INF_BACKUP (RX) : ORIGIN = 0x7f000, LENGTH = 0x1000
IVT_RAM (RW) : ORIGIN = 0x1fff8000, LENGTH = 0x400
STACK (RW) : ORIGIN = 0x20007c00, LENGTH = 0x400
RAM (RW) : ORIGIN = 0x1fff8400, LENGTH = 0xf800
}
/ SECTIONS */
SECTIONS
{
.IVT : {

IVT_start = .; isr_vector_region_start = .; KEEP(*(.isr_vector)) isr_vector_region_end = .; IVT_end = .; } > IVT .TEXT : { TEXT_start = .; rodata_region_start = .; *(.rodata) *(.rodata*) rodata_region_end = .; text_region_start = .; *(.text) *(.text*) text_region_end = .; TEXT_end = .; } > TEXT .ARM : { ARM_start = .; ARM.exidx_region_start = .; *(.ARM.exidx) *(.ARM.exidx*) ARM.exidx_region_end = .; ARM_end = .; } > TEXT CODE_RAM_rom_start_not_align = .; CODE_RAM_rom_start = CODE_RAM_rom_start_not_align + (CODE_RAM_rom_start_not_align % 4); CODE_RAM_rom_end = CODE_RAM_rom_start + CODE_RAM_ram_end - CODE_RAM_ram_start; DATA_RAM_rom_start_not_align = CODE_RAM_rom_end; DATA_RAM_rom_start = DATA_RAM_rom_start_not_align + (DATA_RAM_rom_start_not_align % 4); DATA_RAM_rom_end = DATA_RAM_rom_start + DATA_RAM_ram_end - DATA_RAM_ram_start; .DTC (NOLOAD): { . = ALIGN(4096); DTC_start = .; . += 4096; . = ALIGN(4096); DTC_end = .; } > DTC .DTC_BACKUP (NOLOAD): { . = ALIGN(4096); DTC_BACKUP_start = .; . += 4096; . = ALIGN(4096); DTC_BACKUP_end = .; } > DTC_BACKUP .INF (NOLOAD): { . = ALIGN(4096); INF_start = .; . += 4096; . = ALIGN(4096); INF_end = .; } > INF .INF_BACKUP (NOLOAD): { . = ALIGN(4096); INF_BACKUP_start = .; . += 4096; . = ALIGN(4096); INF_BACKUP_end = .; } > INF_BACKUP .IVT_RAM : { . = ALIGN(1024); IVT_RAM_start = .; . += 0X400; IVT_RAM_end = .; } > IVT_RAM .STACK : { STACK_start = .; . += 1024; STACK_end = .; } > STACK .BSS (NOLOAD): { BSS_start = .; bss_region_start = .; *(.bss) *(.bss*) bss_region_end = .; BSS_end = .; } > RAM .CODE_RAM : AT(CODE_RAM_rom_start) { . = ALIGN(4); CODE_RAM_ram_start = .; CODE_RAM_start = .; code_ram_region_start = .; *(.code_ram) code_ram_region_end = .; CODE_RAM_end = .; CODE_RAM_ram_end = .; } > RAM ASSERT((CODE_RAM_ram_end - CODE_RAM_ram_start) == (CODE_RAM_rom_end - CODE_RAM_rom_start), "Copy Section CODE_RAM Size non-aligned") .DATA_RAM : AT(DATA_RAM_rom_start) { DATA_RAM_ram_start = .; DATA_RAM_start = .; data_region_start = .; *(.data) *(.data*) data_region_end = .; DATA_RAM_end = .; DATA_RAM_ram_end = .; } > RAM ASSERT((DATA_RAM_ram_end - DATA_RAM_ram_start) == (DATA_RAM_rom_end - DATA_RAM_rom_start), "Copy Section DATA_RAM Size non-aligned") IVT_memory_start = ORIGIN(IVT); IVT_memory_end = ORIGIN(IVT) + LENGTH(IVT); IVT_memory_size = LENGTH(IVT); TEXT_memory_start = ORIGIN(TEXT); TEXT_memory_end = ORIGIN(TEXT) + LENGTH(TEXT); TEXT_memory_size = LENGTH(TEXT); DTC_memory_start = ORIGIN(DTC); DTC_memory_end = ORIGIN(DTC) + LENGTH(DTC); DTC_memory_size = LENGTH(DTC); DTC_BACKUP_memory_start = ORIGIN(DTC_BACKUP); DTC_BACKUP_memory_end = ORIGIN(DTC_BACKUP) + LENGTH(DTC_BACKUP); DTC_BACKUP_memory_size = LENGTH(DTC_BACKUP); INF_memory_start = ORIGIN(INF); INF_memory_end = ORIGIN(INF) + LENGTH(INF); INF_memory_size = LENGTH(INF); INF_BACKUP_memory_start = ORIGIN(INF_BACKUP); INF_BACKUP_memory_end = ORIGIN(INF_BACKUP) + LENGTH(INF_BACKUP); INF_BACKUP_memory_size = LENGTH(INF_BACKUP); IVT_RAM_memory_start = ORIGIN(IVT_RAM); IVT_RAM_memory_end = ORIGIN(IVT_RAM) + LENGTH(IVT_RAM); IVT_RAM_memory_size = LENGTH(IVT_RAM); STACK_memory_start = ORIGIN(STACK); STACK_memory_end = ORIGIN(STACK) + LENGTH(STACK); STACK_memory_size = LENGTH(STACK); RAM_memory_start = ORIGIN(RAM); RAM_memory_end = ORIGIN(RAM) + LENGTH(RAM); RAM_memory_size = LENGTH(RAM);

}
上面是项目中的ld檔,修改完后SPI的初始程序(下面所示)会一直在下面循环出不来(修改前是没问题的),请问有可能是什么原因呢?会不会是.bss档没清0呢?请问sample code清0的程序在那呢?
while (spiState->rxCount != (uint16_t)0)
{
/* Read the last word from the RX FIFO */
if (SPI_GetStatusFlag(base, SPI_RX_DATA_FLAG))
{
SPI_DRV_ReadRXBuffer(instance);
}
}

客户希望有一个基于 YCT 的 YT-LINK 实现的 Boot 与 App demo
Boot 部分就是打印信息以及跳转至应用程序
App 部分打印信息

e71e9d23-2d96-4328-bae5-6cc8243524b0-image.png 我想问下这种能编译但是又是全是错误的是什么意思啊？

b1910b5b-bb1c-46ab-965b-88d92ccce01c-280e46e8fa0c253e6f36c7f6f7adfb7.png
如题，ME05在使用mbedtls加密库时，用IAR编译后，使用JFLASH查看HEX,右侧会显示工程地址，现在查出是mbedtls加密库中影响的，客户不想生成这一段HEX，如何避免？

CMake 介绍

CMake 在嵌入式编程中的地位已经越来越重要。它是一个强大的跨平台自动化构建系统，能够管理大型项目中的软件构建过程。以下是几个方面，说明了CMake在嵌入式领域的重要性和使用情况：

跨平台兼容性：CMake可以生成各种平台上的编译环境，包括Windows、MacOS和各种Unix-like系统。这使得它特别适合于开发可以在多种硬件上运行的嵌入式软件。 灵活性和可扩展性：CMake支持复杂的项目结构，可以轻松地管理多个库和应用程序的依赖关系。这对于嵌入式系统开发尤其重要，因为这些系统往往包含多个模块和组件。 工具链集成：CMake可以与各种编译器和工具链无缝集成，如GCC、Clang等，以及专用的嵌入式开发工具链，如ARM Keil、IAR等。这使得开发者可以更容易地在其选择的环境中编译和测试代码。YCT 支持生成CMAKE-GCC/CMAKE-IAR/CMAKE-KEIL/CMAKE-GHS 代码可重用性：使用CMake可以更容易地在不同项目之间重用代码。通过寻找包和库，CMake允许开发者将常用的功能或库集成到新的嵌入式项目中，而无需重新配置整个构建环境。 YCT生成的CMAKE文件架构

YCT生成的cmake文件遵守最新的Modern Cmake的理解：

目标导向：Modern CMake 鼓励使用基于目标（target）的指令来管理构建配置，而不是基于全局的设置。每个目标可以定义自己的编译选项、预处理器定义、链接库等，这使得项目更加模块化和易于管理。 用法要求：在传统 CMake 中，库的依赖关系通常通过全局变量和目录链接来管理。而在 Modern CMake 中，推荐使用 target_link_libraries、target_compile_definitions 和 target_include_directories 等命令为目标设置用法要求。这样，当其他目标链接到库时，它们会自动继承正确的编译器标志、宏定义和包含路径。

YCT生成的工程默认是如下的配置：
project 包含：GENERATED_CONFIG_TARGET，GENERATED_SDK_TARGET

GENERATED_CONFIG_TARGET target 包含board下的源文件和头文件 GENERATED_SDK_TARGET target 包含生成代码（SDK/MCAL)的源文件 GENERATED_CONFIG_TARGET 和 GENERATED_SDK_TARGET 互相依赖 Project默认会包含APP目录下的所有的.c,.S文件，同时APP目录会作为include目录 add_executable(${project_elf} app/main.c) #add app as include path target_include_directories(${project_elf} PRIVATE app) #add all source files in app folder file(GLOB dir_sources "app/*.c" "app/*.cpp" "app/*.S") if(dir_sources) foreach(src ${dir_sources}) target_sources(${project_elf} PRIVATE ${src}) endforeach() endif() 添加额外的源文件 直接修改顶层的CMakeLists.txt文件

用户可以直接在 USER CODE BEGIN 开始，USER CODE END 介绍的中间部分增加自己的配置代码，在这之间生成的代码不会被覆盖掉

# USER CODE BEGIN include # target_include_directories(...) # USER CODE END include # USER CODE BEGIN add_executable # target_sources(${project_elf} PRIVATE ..) # USER CODE END add_executable

下面以增加bsp目录为例：

# USER CODE BEGIN include # 增加bsp/inc头文件搜索路径 target_include_directories(${project_elf} PRIVATE "bsp/inc") # USER CODE END include # USER CODE BEGIN add_executable # 增加源文件bsp/bsp.c 作为源代码 target_sources(${project_elf} PRIVATE "bsp/bsp.c") # USER CODE END add_executable 添加一个独立的target文件

当源文件比较多的时候，或者想更好的控制代码的编译选项的时候，建议增加一个独立的target方式来实现，还是以bsp代码作为例子。

写一个BSP.cmake 文件放到bsp目录 cmake_minimum_required(VERSION 3.16) set(sources bsp.c ) #增加头文件 set(includes inc) #增加私有头文件 set(priIncludes ) add_library(BSP STATIC ${sources}) target_include_directories(BSP PUBLIC ${includes}) target_include_directories(BSP PRIVATE ${priIncludes}) #添加基础的编译选项，如CPU类型等 configcore(BSP ${CMAKE_SOURCE_DIR}) #增加宏定义，PRVIATA代表只有这个target里的源代码可以识别到这个宏,(不用加-D) target_compile_definitions(BSP PRIVATE BSP ) #对BSP target的代码单独设置优化选项，不影响其他模块 target_compile_options(BSP PRIVATE -O1 ) #如果BSP代码访问到了SDK的头文件，那么需要添加依赖的target target_link_libraries(BSP GENERATED_CONFIG_TARGET GENERATED_SDK_TARGET ) 修改顶层的CMakeLists.txt文件 # USER CODE BEGIN include #包含我们添加的BSP.cmake文件 include(${CMAKE_SOURCE_DIR}/bsp/BSP.cmake) #把BSP target 加入到project里 target_link_libraries(${project_elf} BSP) # USER CODE END include

10df96fe-f7c1-41d7-9c1d-8789e3873e8e-image.png ruru'tru'tu如图所示进行uint64的数据除法运算时，编译会报错报错信息如下，这个问题怎么解决呢14f24e0a-2142-4c9a-97de-63a150ba17d3-image.png

36b4380b-db00-4c86-babd-186cca913ff5-image.png 配置使能，查看生成配置代码无变化，是有其他的注意事项吗？

各位大佬，YTC生成工程会报这个错误Error mvpking remote method
Ipc-gen-ide-tie' Typefrron Cannot tead properties of undefined (reading EWARM)，这个要怎么解决
6270249e-035d-4d74-99e1-de1519fc8487-c4b51eda896e74a65a250cb969fbee36.jpg

RAM中有一段地址设置为了只在Power on 的时候初始化。现在当APP进入PowerDown模式休眠后再次唤醒复位进入Boot后这一段区域未初始化进入hardfault。现在Boot已经不能修改了，请问还有其他方法可以解决这个问题吗。有唤醒中断吗
54eb96d6-96a9-426c-8718-0b8e0a566799-image.png

fb27a4f6-35e9-4558-b2c9-0615aa751f99-d3de98e3cbbb50a0542d8bc8d8b1642b.png

回复: HA0 Trng随机数生成器，多次触发不更新随机数这个连接无法查看，我想请问运行YTM32B1ME05芯片有没有可以参考的生成随机数的函数

b650ebfcbc41f4b258bed03b483baf69.png

30dea35d-13f6-4bdf-b30e-d52dd5627fc5-image.png 我在参考BTdemo工程使用跳转APP的函数时，图示位置执行会报错，通过demo工程确认APP工程可以正常跳转没有问题，我自己的BT工程使用这个函数时无法正常运行，这个函数bootup_application
调用有什么依赖吗

本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
5e1b4583-94f0-4786-8b03-c70851e6bb51-image.png

烧录Bootloader
新建YTM32B1MC03的JFLASH工程
e31f21d8-f1b4-4be0-960d-b1bdd08bc63d-image.png
找到Bootloader编译的烧程文件
9ceb1572-c212-4c57-a815-0b8d7e84806c-image.png
加载Bootloader文件
807cf228-2a95-43a9-b84f-4cf29b0332a3-image.png
擦除芯片（或者快捷键F4）
ace171c2-6b70-4201-99c3-50d9863d1af6-image.png
4ddc4c41-a35e-49fd-9404-c0a4cf401dd3-image.png
烧录程序（或者快捷键F6）
98170abf-7180-46a8-b7da-86a82369cd88-image.png
d226326b-944a-499f-ad36-a6af638db7fb-image.png 上下电运行Bootloader
拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。 升级上位机配置
将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
435a580c-314d-4f54-8a4b-6d2e9007348d-image.png
打开升级上位机工程（如上图中.TSProj_x86文件）配置收发ID
45aa0f66-c39f-4794-8fc9-eb3a8489d382-image.png

配置TP时间参数，配置加密dll
6438a816-417d-45ad-b0f1-200d3b1e75ce-image.png
配置FlashDriver和Application和校验方式
8a33cf16-38f8-4cb4-b500-e24496e683db-image.png
配置自动诊断流程
b726c12e-406e-485c-9441-b671b51efb75-image.png
4. 执行升级
4.1 从Bootloader升级
dc21dc68-a986-49b0-a596-453a1e948641-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.2 从Application升级
从Bootloader升级成功运行到Application后，再次点击运行，从Application升级。
1ba1902e-953b-4e91-978d-989d81d4320e-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.3 StayInBoot升级
从Application升级中，是有升级请求标识的（KeepInBootVar变量）。
本方案设计上认为：
运行到Bootloader以后，如果通讯一半断开未发生升级服务（擦除芯片/请求下载/数据传输/下载退出等UDS服务），则即使有升级请求，可以超时退出重新跳转到Application运行；反之则必须StayInBoot等待重新升级。
4.3.1 未发生升级流程请求
升级一半，拔掉CAN线模拟通讯断开，升级失败
0b519b6a-91d3-44a0-b6bf-794829a3652b-image.png
通讯断开超时后，Bootloader重新进入Application运行，Demo板上LED灯1000ms闪烁。
4.3.2 已发生升级流程请求
执行到升级流程后，拔掉CAN线模拟通讯断开，升级失败
d9d0ca85-0330-4f42-b93e-c7196f69ca0b-image.png
通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级
93dce8d5-9f9f-4619-b11d-62bbfea398c7-image.png
升级成功，Demo板上LED灯1000ms闪烁。
5. 附件代码
uds_can_fbl_mc03_release_20250529_2.zip

1、问题：
8cd613af-f399-40db-af3e-cb19baa96ca7-61120d41fcb69a4633ea860186e84c5.png

使用 YTM32B1MC03 SDK 1_3_1
我创建一个bootload工程，并集成了OTA升级功能，在升级完成后执行跳转APP操作，但APP无法正常启动，单步调试APP发现程序卡在了SPI Master初始化里不出来了

2、配置如下：
boot：
144423cd-d5d1-4b86-acb4-c3da6c24225d-6299e211d1c76e033e19a1985fc438e0_.png
06cadc11-2895-491d-af64-2a7f00a728fa-269d6a21873411c782f732b49a0207b0_.png

3、补充：
A、屏蔽掉无法初始化的外设，启动定时器，启动RTOS task，分别在两个位置操作IO翻转，示波器观察到，bootload升级完APP 跳转至APP后，IO一直在翻转，可以确定升级跳转都没问题。

B、在APP做地址偏移之前 程序所有功能都能正常执行。

C、另外，在修改APP的偏移地址后，编译出现下面图片中的信息
f9003ffb-6934-4cf6-8efb-247dc5812334-image.png

本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
dbc523c3-21f4-4d1a-98b3-3b50282fac1a-image.png

烧录Bootloader
新建YTM32B1MD14的JFLASH工程
c609c5a4-00b8-434b-a244-ae5bde77e46e-image.png
找到Bootloader编译的烧程文件
a0b6c9f7-8e07-40e7-aaa4-3076355c8caa-image.png
加载Bootloader文件
3900e9bd-c72e-4bc9-acc3-e2287c796557-image.png
擦除芯片（或者快捷键F4）
156d3954-7e53-4a13-8e5f-026e4a1bff49-image.png
fae94334-266c-4740-969c-f69d2650440e-image.png
烧录程序（或者快捷键F6）
ac129ec4-4b1b-42cc-80ba-44d166e59e25-image.png
6d1d1b5c-28af-444d-84a1-01280c9a14e3-image.png 上下电运行Bootloader
拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。 升级上位机配置
将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
3f15b88d-af6f-43f6-b285-877a7d0ca419-image.png
打开升级上位机工程（如上图中.TSProj_x86文件）配置收发ID
ade66a27-609f-4150-8fde-a1f6f0833ec9-image.png

配置TP时间参数，配置加密dll
b8723e3c-c726-4876-b46a-e8e4488d0ec1-image.png
配置FlashDriver和Application和校验方式
95adfb20-50a3-4532-bd58-7b9a69330010-image.png
配置自动诊断流程
6d7f2e9f-73b1-4354-a03a-37f565903759-image.png
4. 执行升级
4.1 从Bootloader升级
b35da6fc-c501-4ebb-9e57-6167a92185d6-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.2 从Application升级
从Bootloader升级成功运行到Application后，再次点击运行，从Application升级。
14c4d1e0-df93-4efb-80f3-fda4130399e3-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.3 StayInBoot升级
从Application升级中，是有升级请求标识的（KeepInBootVar变量）。
本方案设计上认为：
运行到Bootloader以后，如果通讯一半断开未发生升级服务（擦除芯片/请求下载/数据传输/下载退出等UDS服务），则即使有升级请求，可以超时退出重新跳转到Application运行；反之则必须StayInBoot等待重新升级。
4.3.1 未发生升级流程请求
升级一半，拔掉CAN线模拟通讯断开，升级失败
b38f0141-062e-4be3-96d8-74d35fb5f42b-image.png
通讯断开超时后，Bootloader重新进入Application运行，Demo板上LED灯1000ms闪烁。
4.3.2 已发生升级流程请求
执行到升级流程后，拔掉CAN线模拟通讯断开，升级失败
d66fcdc3-fedc-4180-98b0-07e4e5dc9259-image.png
通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级
e3fce7cf-3ad9-49f9-b415-9d64b295a22b-image.png
升级成功，Demo板上LED灯1000ms闪烁。
5. 附件代码
uds_can_fbl_md14_release_20250530_2.zip

3ed7d7a96997c671e51f3ba4a5eb0ea.jpg
这两个接口中间是不是不能被打断？
运行的时候，无论是在它们中间打断点，还是用线程去打断它，mcu都会一直循环进spi中断，有点像某个导致中断的标志位没有被清。
这个spi这个任务优先级不高，运行一段时间后恰好被高级任务从这两接口之间抢段，mcu就死机了，一直进spi中断。
试过加调度器临界保护，结果这个现象还是会出现，不知道是不是有其他原因也会造成这个问题

芯片：ME05 64pin芯片
SDK：1.4.0
休眠：powerdown，wup唤醒
描述：powerdown休眠唤醒时对POR ONLY数据进行赋值会跑飞
cc5c6530-5178-4f7a-ae09-be9425af2a18-image.png
工程附件：project.yct
之前用ME0 144pin，sdk1.3.1，standby模式POR ONLY变量是可以正常计数的

没有找到retention ram的定义，有没有相关文档介绍？
30abbd3b-50cd-4c21-9bda-9e20fcc17838-image.png

目前只是晶振在跑，做循环累积，其它程序都屏蔽了，芯片的功耗都有0.4W，芯片厂商那边有没有遇到这种情况 ，看看什么原因

6a91abcf-ef33-44a9-a31a-5bc3520c0fa8-image.png 708e6539-c8b3-4262-ae54-55edaf399880-image.png