CCS烧录uboot遇到的问题

最新推荐文章于 2024-04-28 15:05:15 发布
最新推荐文章于 2024-04-28 15:05:15 发布
阅读量1.1k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： CCS 文章标签： 开发语言
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_45073889/article/details/129174955
在使用CCS进行uboot烧录时遇到CortexA8处理器内存写入错误，具体表现为Error-2130。尝试多种解决办法无效后，发现通过在板子通电瞬间点击Debug可以避免该问题，从而成功烧录。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

CCS烧录uboot遇到的问题

烧录uboot过程中，加载.gel文件，报错如下：

CortexA8: Trouble Writing Memory Block at 0x40300ca8 on Page 0 of Length 0x24: (Error -2130 @ 0x40300CA8) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 5.1.207.0)
CortexA8: GEL: File: D:\app\CCS5.5\CCS5.5\workspace\dm8168\Debug\dm8168.out: Load failed.

询问解决办法无果。
形成原因未知，最后经测试，解决办法如下：

给板子通电的一瞬间点击Debug，
便可以成功，不会遇到该错误。

CCS软件编译时Relocation Overflow Error报错解决方法（含CCS2解决方法）
er131的博客
09-12 931
在32位的指令结构中，一个时钟周期只能访问偏移地址范围内的内存，32位的寻址结构使用其中的15位来作为偏移地址，所以可以访问的内存空间共2^15=32k.这些内存空间中用来保存near型的变量。编译器在编译的时候默认将所有全局变量作为near型变量，数组作为far型变量。有时候代码执行时会将一个far的变量按照near去访问，就会警告或报错，提示原因是xxxis too large to encode in the 15bit field，就是说这个变量太大，超出了15位的偏移地址的访问范围。
uboot学习（一）使用ccs方式烧录uboot
chenxuol的博客
12-31 2998
参考 http://processors.wiki.ti.com/index.php/DM816x_AM389x_PSP_Flashing_Tools_Guide#Burning_images_to_NAND_Flash_.28using_CCS.29 ccs5.4.0+seed xds560plus 1.1.1       启动ccs 器件Family和器件分别选择ARM和DM8
基于AM335x的U-Boot/SPL 的CCS 调试
望都者
04-07 3280
在基于Linux的AM335x软件开发流程中，第一步就是U-Boot/SPL（SecondProgram Loader）的移植。在移植中遇到问题比较常见，而U-Boot/SPL的调试手段比较简陋，不便于迅速找到问题。利用仿真器可以单步调试的特点，就可以迅速定位到出问题的代码所在位置，加速移植的调试过程。本文主要介绍如何用CCS+emulator调试基于AM335x的U-Boot/SPL。
CCS11.2 could not open file.out,Load program error
m0_72166999的博客
12-13 5147
编译正常，debug的时候报错 发现debug文件夹也没有.out文件 查看配置发现Linked Resources里面居然有C盘路径（代码是从别的电脑拷过来的)，果断把ccs和c2000路径重装到c盘根目录了，解决。 强烈建议安装默认路径，装在别的地方乱七八糟问题太多了！
CCS复制工程后烧录失败
please_stable的博客
08-27 1800
CCS烧录问题
CCS编译U-boot
weixin_34365635的博客
07-25 341
CPU选用TI出的am335x，为方便调试采用CCS编译U-boot。准备Uboot源码包，交叉工具链，CCS安装包。1.打开CCS，选择File->new project，选择“Makefile project with existing code”2.下一步，选择Uboot源码包，选择"Cross GCC"工具链3.更改环境变量，如果已经在系统内修改交叉工具链的环境，可以略过4.显示ma...
CCS3.3利用SEED-XDS560PLUS烧录UBOOT到DM365 NANDFLASH详述
本文主要介绍了如何使用CCS3.3版本的软件工具将UBOOT固件烧写到TI的DM365板子的NAND...这篇文章为读者提供了一套完整的CCS3.3烧录UBOOT到NANDFLASH的实用教程，适用于TI DM365平台的开发者进行系统升级或初始化工作。
How to burn ubl and uboot with CCS.
10-14
在本篇文章中，我们将详细介绍如何使用Code Composer Studio (CCS) 来烧录 UBL（微引导加载程序）和 U-Boot（通用引导加载程序）到德州仪器 (TI) 的 DM365 IPNetCam 开发板上。该过程不仅包括了具体的步骤，还涵盖了...
codewarrior烧录_codewarrior烧写u-boot到nor(1)
weixin_39624774的博客
12-19 1275
这里的烧写方法是一次次尝试出来的，也是加强一下自己对p1020启动流程的理解吧。注意：烧写时，sw1拨位为0111，启动时拨位应该为0000使用codewarrior来烧写.创建SRAM程序，debug测试一下创建flash programmer打开flash file to targetimage检查以下选项image点击connection的editimage检查initialization和...
DM365 UBOOT烧写所用下载文件
10-19
- 如果烧写失败，可能是因为UBOOT文件问题、通信接口问题或者CCS设置错误。检查源代码、编译过程、硬件连接以及CCS的配置设置。 - 使用CCS的调试功能可以帮助定位问题，例如查看错误日志，或者使用硬件断点检查...
CCS3.3下载UBOOT到NANDFLASH详细步骤
10-19
CCS3.3下载UBOOT到NANDFLASH的详细步骤 有图有真相
TMS320F2808，实现定时器TIMER0中断定时，开发环境ccs4.2 例程
10-21
TMS320F2808，实现定时器TIMER0中断定时，开发环境ccs4.2 例程
CCS v5中烧写Flash实录：成功+失败
系统 运维
08-23 1558
记于2013年08月23日 环境：Win7 + CCS v5 +XDS100v2仿真器 + TMS320CF2812芯片 烧写方法：将SRAM.cmd替换成FLASH.cmd。一个通用的用于F2812的FLASH.cmd 例子为 MEMORY { PAGE 0 : OTP : origin = 0x3D7800, length = 0x000800 ...
关于DSPF28335报错“ a data verification error occurred,file load failed“
ljh3321的博客
01-10 8304
DSP报错“a data verification error occurred”问题，要么是链接文件或内存映射问题，要么就是硬件链接问题
CCS烧写28335失败
leo
06-01 2971
天气太热，硬盘受不了就开始罢工了，数据无价，实验的东东更是不敢动的，好在尽可能拷贝了部分数据，遗憾的是实验结果全丢了。。。测了一个多月呢。换了硬盘，重新装了CCS，一样的工程，一样的驱动器，不一样的系统（换win8了^_^），然后烧写出问题了~~~背景：最近在做课题《伺服驱动系统关键技术研究》的惯量在线辨识，仿真结果很舒坦呐，在电机上跑就是要调，影响的因素比较多，也就意味着任务量比较大，也不知道电机
CCS6.0编译可以生成.out文件，debug没反应，不自动load
lee_wayway的博客
05-22 1万+
问题描述： 一般而言，先build，点击debug之后会自动下载.out 文件，跳转到debug的界面，如下图所示： 但是这次点击debug时没有任何反应： 解决方法： 1.先设置好仿真器型号并链接工程文件 2. 再点击 Debug Configurations ，打开Debug配置 3.设置 configurations $...
【MSP430G2553】问题记录：CCS如何调试进入中断
qq_40771649的博客
09-25 2181
近期开始单片机的学习，发现单步调试的话进不了中断。 经过实验证明，设置断点后，点击debug后再点一下resume就可以进入中断了。 步骤1： 步骤2： 大功告成！
DSP学习常见注意事项，CCS编译及调试遇到的问题与解决办法（连续补充）
热门推荐
u013673437的博客
12-28 1万+
CCS编译及调试遇到的问题与解决办法1 常见注意事项1.1 开发板常见的启动方式区分2 调试遇到的问题与解决办法2.1 debug的时候连接不上仿真器 目前刚开始学习DSP，在这里记录一下学习过程中遇到的问题与解决办法，另外还包含一些常见的注意事项，避免重复遇到问题。 使用的DSP为：广州创龙电子的TMS320C6748 1 常见注意事项 1.1 开发板常见的启动方式区分 UART2： DEBUG...
CCS报错：Import failed for project ‘xxx‘ because its meta-data cannot be interpreted.
tangweijian123的博客
04-28 2387
CCS导入项目出现报错：Import failed for project 'xxx' because its meta-data cannot be interpreted.
Trouble Writing Register PC: Programming failed @ address 0x00000600 (block verification error) Failed to restore target. RAMCode never stops
最新发布
07-06
<think>嗯，用户提出的问题涉及嵌入式开发中的寄存器写入错误和RAMCode无法停止的问题，这通常发生在微控制器编程场景中。根据用户最后提到的错误信息"Trouble Writing Register PC: Programming failed at address 0x00000600"和"RAMCode does not stop"，可以判断这是典型的嵌入式系统调试故障。 用户可能正在使用JTAG或SWD调试器进行芯片编程，地址0x600这个位置很关键——它正好处于ARM Cortex-M的SRAM区域起始位置附近。考虑到用户提到"block verification error"，说明编程后校验失败，而"RAMCode does not stop"则暗示用户可能在使用RAM中运行的引导程序。 从技术角度需要排查几个层面：首先是硬件连接，JTAG/SWD的物理连接不稳定会导致此类错误；其次是内存映射配置，地址0x600是否在有效的可编程区域；还有电源稳定性问题，VDD波动会影响闪存编程。特别要注意的是，某些STM32芯片的SRAM区域起始地址就是0x20000000，而0x600这个地址看起来异常偏低，可能是地址映射错误。 用户没有说明具体芯片型号，但根据经验，这类错误在ST的STM32和NXP的LPC系列中较常见。建议用户先检查调试器配置中的芯片选型是否正确，再确认是否开启了写保护功能。关于RAMCode无法停止的问题，通常需要强制复位或者断开调试器电源才能解除CPU死锁状态。 值得注意的细节是，引用[2]提到的"killing interrupt handler"错误与用户情况有相似性——都涉及中断处理异常。虽然引用内容是Linux内核错误，但原理相通：当关键中断(如SysTick)被破坏时，会导致系统完全挂死。这提示我们需要检查用户的中断向量表是否被意外覆盖。</think>基于您遇到的嵌入式系统编程错误，以下是系统性解决方案： ### 问题分析 1. **寄存器PC写入失败** `Trouble Writing Register PC: Programming failed at address 0x00000600` 表明： - 目标地址 `0x00000600` 可能处于**受保护区域**（如只读内存或未映射区域） - 硬件连接不稳定导致数据传输错误 - 芯片写保护未解除 2. **块验证错误** `block verification error` 说明写入数据与预期不符，常见原因： - 时钟信号不稳定（如JTAG/SWD时钟过高） - 电源电压波动导致信号失真 - 内存对齐问题（如尝试写入未对齐地址） 3. **RAMCode无法停止** `RAMCode does not stop` 通常由： - 中断处理程序死循环 - 看门狗未正确配置 - 堆栈溢出导致程序跑飞 --- ### 解决方案 #### 第一步：硬件检查 1. **电源与时钟** - 用示波器检测 `VDD/VREF` 电压纹波（需<5%） - 降低调试器时钟频率（建议先降至1MHz） - 检查复位电路是否稳定 2. **连接可靠性** ```mermaid graph LR A[调试器] -->|SWDIO| B[目标板] A -->|SWCLK| B A -->|GND| B B -->|1-10kΩ上拉| C[RESET引脚] ``` #### 第二步：软件配置 1. **解除写保护** 在调试脚本中添加解锁序列（以STM32为例）： ```python # STM32 Flash解锁命令 debugger.write_memory(0x40022004, [0x45670123]) # KEY1 debugger.write_memory(0x40022004, [0xCDEF89AB]) # KEY2 ``` 2. **内存映射修正** 确认 `0x00000600` 的有效性： - 对于Cortex-M：该地址位于**系统保留区**，需重定位到SRAM（如 `0x20000000`） - 修改链接脚本确保代码段避开保留区 #### 第三步：故障处理 1. **RAMCode终止** - 强制断点：在 `SystemInit()` 入口设置硬件断点 - 看门狗紧急停止： ```c *((volatile uint32_t*)0xE0042008) = 0x00008000; // Cortex-M DWT_CTRL ``` 2. **错误跟踪** 启用故障诊断寄存器： ```c SCB->SHCSR |= SCB_SHCSR_MEMFAULTENA_Msk; // 使能内存错误中断 ``` --- ### 关键预防措施 1. **编程流程优化** ```mermaid sequenceDiagram 调试器->>芯片： 发送解锁序列 芯片-->>调试器： 返回ACK 调试器->>芯片： 擦除目标扇区 调试器->>芯片： 分块写入(≤256字节/块) loop 每块验证 调试器->>芯片： 读回数据 芯片-->>调试器： 返回数据 调试器->>调试器： CRC32校验 end ``` 2. **安全恢复机制** - 添加BOOT引脚检测：强制进入引导加载程序 - 实现双备份固件（Bank swap机制） > **重要提示**：若仍出现 `Aiee, killing interrupt handler` 类严重错误[^2]，表明系统已完全死锁，需物理断电复位并检查硬件损坏。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员3哥

有用的话赏点吧

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值