[参考译文] MSP430F6779A：使用大型代码模型的 MSPBoot 多映像

您好、Jorge、

计划对原始 MSPBoot 资源进行更新、但由于其他优先级的原因、尚未开始对其进行更新。 因此、尚未设定发布日期、也不应在近期内预计发布日期。 此更新也很可能仅支持 CCS IDE。您可能需要考虑使用自定义 BSL (SLAA450)、因为您使用的是基于闪存的 BSL 器件： www.ti.com/.../slaa450d.pdf

如果继续沿着这条路径运行、我建议您将 MSPBoot 中的闪存代码与 MSP430FRBoot 中的大内存模型支持相结合、创建您自己的主内存大内存模型引导加载程序。 到目前为止、您的存储器组织似乎是正确的。

此致、
Ryan

您好、Ryan。

我必须沿着这条路继续。 感谢您的参与。

我对矢量重定向到 RAM 所做的假设是正确的还是我错过了什么？

此致、
豪尔赫

很抱歉未能解决这个问题、正如 MSPBoot 应用报告第2.2.3/4节所述、您可以将矢量重定向到硬件中的 RAM (SYSRIVECT)。 这可以代替代理表来完成。

此致、
Ryan

您好、Ryan。

我已经取得了一些进展、但我仍然需要您帮助解决一些问题。

我决定仅使用双应用程序方法开始开发。

	启动	结束	尺寸	512B 扇区
应用领域	0x0C000	0x0EFFF	0x3000	24
引导区域	0x0F000	0x0FFFF	0x1000	8.
下载区域	0x10000	0x12FFF	0x3000	24
		共计	0x7000	56.

到 RAM 的矢量重定向运行良好。

为了实现这一点、我更改了应用程序链接器文件、将中断矢量放置在引导加载程序正下方的固定位置(0xEF80 - 0xEFFF)。

	启动	结束	尺寸
应用程序重置	0x0EFFE	0x0EFFF	0x00002
APP 中断矢量	0x0EF80	0x0EFFD	0x0007E
		共计	0x00080

在引导加载程序和应用程序链接器上、我保留了 RAM 的顶部。  

////////////////////////////////////////////////// RAM 地址//////////////////////////////////////////////////////////////////////////
//
//可用 RAM 的起始地址
-D_Available RAM_START=_RAM_START
// RAM 内部矢量的保留空间地址- 64个矢量
-D_RAM_RESERVE_=80
//可用 RAM 的结束地址
-D_Available RAM_End=(_RAM_END-_RAM_RESERVED)
//保留 RAM 的开始
-D_RAM_RESERVE_START=(可用_RAM_END+1)
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

//--------------------------------------------------------
//读/写存储器
//
-Z (data) DATA16_I、DATA16_Z、DATA16_N、TLS16_I=_Available RAM_START-_Available RAM_END
-Z (data) DATA16_heap+_DATA16_heap_size
-Z (data) code_i
-Z (data) DATA20_I、DATA20_Z、DATA20_N
-Z (data) CSTACK+_STACK_SIZE#

在应用程序启动时、我将向量复制到保留的 RAM 并设置 SYSRIVECT。

extern uint16_t _App_Vectors_Start；
extern uint16_t _App_end；
extern uint16_t _RAM_reserved_start；

memcpy ((void*)(&_RAM_reserved_start)、(const void*)(&&App_Vectors_Start)、((((uint16_t)))+ uint16_t App_starts)+ t)+ t App_Vectors_t
SYSCTL |= SYSRIVECT； 

我使用一个使用计时器中断来切换 LED 的小型应用进行了测试。 这很好。

引导加载程序的首次测试针对的是低于64KB 的应用和下载区域、测试正常。 我从 MSPBoot for IAR 中的双映像示例开始。 但是、由于我需要使用64KB 以上的空间、因此我开始根据 MSPFRBoot 更改代码。

我有几个问题：

•  网址为 TI_MSPBoot_MI.h

使用时：  

extern uint32_t _AppChecksumDown； /*！ 下载校验和地址*/
extern uint32_t _App_EndDown； /*！ 下载结束地址*/

/*！ 下载区域起始地址(来自链接器文件)*/
#define DOWN_START_ADDR ((uint32_t)&_AppChecksumDown)
/*！ 下载区域结束地址(来自链接器文件)*/
#define DOWN_END_ADDR ((uint32_t)&_App_EndDown) 

对于 DOWN_START_ADDR、我获得0x0而不是0x10000； 对于 DOWN_END_ADDR、我获得0x2FFF 而不是0x12FFF、地址以某种方式被截断、因为在调试期间、我可以看到 _AppChecksumDown 和 _App_EndDown 是正确的。

如果我使用：  

/*！ 下载区域起始地址(来自链接器文件)*/
#define DOWN_START_ADDR (0x10000+(uint32_t)&_AppChecksumDown)
/*！ 下载区域结束地址(来自链接器文件)*/
#define DOWN_END_ADDR (0x10000+(uint32_t)&_App_EndDown) 

我得到了正确的地址。

在将上部存储器中的地址转换为 uint32_t 时、我的器件上是否有任何错误？ 我使用的是大型代码模型。 这在 MSPFRBoot 中的实现方式与在 CCS 中的实现方式相同。

• 在 TI_MSPBoot_AppMgrDualImg.c 中

计算 CRC 时遇到问题。

在 MSPFRBoot 上：

CRCINIRES = 0xFFFF；
DATA_PTR =(uint8_t*)&_DOWN_Start_Memory；

for (i = 0；i <(uint32_t)&_DOWN_CRC_SIZe1；i++)
CRCDIRB_L =* DATA_PTR++；

if (uint32_t)&t <0x10000_CRC_SIZ1+；


I = 0x000_I +(uint8_I +)+(uint32_I +)；t = 0x10000 = uintxuint8_t +
CRCDIRB_L =*数据_PTR++；
｝
结果= CRCINIRES；

if (结果！=_ data20_read_short (((unsigned long)&& down_Checksum)
)返回 false_t；
否则
返回 try_t； 

在 MSPFRBoot 示例中 、_DOWN_Start_Memory 低于64KB。

如果我使用内存分配、将下载区域从0x10000开始：

extern uint32_t _AppChecksumDown；//下载区域校验和地址
extern uint32_t _App_StartDown； //下载区域起始地址
extern uint32_t _App_CRCDIR_SIZE；//下载区域的地址计算

值 CRCINIRES = 0xFFFF；
DATA_PTR =(uint8_t*)&_App_StartDown；

for (i = 0；i <(uint32_t)&_App_CRCDown =(uint8_start+




)；for (I = 0；unsigned CRICTR_RETURN = t++)++++++(unsigned CRICTRUTRUTR_RETURN += t_RETURN)++++++++！(uint_RETURN ++++++++= t+++++！(uint_RETURN)

我得到以下错误：

ERROR[E18]：范围误差、
数字超出范围。 有效范围为-32768 (-0x8000)至65535 (0xFFFF)。
文件：C：\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\src\MSPBoot\AppMgr\TI_MSPBoot_AppMgrDualImg.c、行：119
来源：MOV.W #_App_StartDown、R13
其中$= TI_MSPBoot_AppMgr_AppisValid + 0xF282 [0xF282]
在模块"TI_MSPBoot_AppMgrDualImg"(C：\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\IAR\MSPBoot\BSLBASed_DualImg\Obj\TI_MSPBoot_AppMgrDualImg.R43)中、
段段第7部分、段代码中的偏移量0x24
什么：_App_StartDown [0x10003]
允许的范围：0xFFFFFF80
操作数：_App_StartDown [0x10003]
在模块?abs_entry_MOD ()中，
这是绝对代码

这似乎是由于地址位于高64KB 上。

如果我对下载起始地址进行硬编码、就像在 MSPFRBoot 中完成的那样、将下载地址分为两个区域：

DATA_ptr =(uint8_t*) 0x10000； 

我得到：

警告[Pe1053]：从整数指针转换为较小指针 C：\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\src\MSPBoot\AppMgr\TI_MSPBoot_AppMgrDualImg.c 119

还有其他上部存储器地址的范围误差。

我缺少什么？

可以帮帮我吗？

此致、

豪尔赫

TI_MSPBoot_MI.h 问题：我不太确定为什么((uint32_t)&_AppChecksumDown)或返回16位值、我的所有工作都是在 CCS 中完成的、没有问题。 这可能是一个向 IAR 编译器团队提问的更好问题、同时您也有权变措施。

TI_MSPBoot_AppMgrDualImg.c 问题：这再次显示为 CCS 和 IAR 编译器之间的差异。 逻辑是正确的、但编译器期望的变量是指针、而不是具有地址的整数值、因此会生成警告。 我不明白的是、当您清楚地使用 uint32_t 时、错误消息会建议一个带符号值(-32768至65535和0xFFFFFF80)、这看起来不像一个大内存代码设置(我从未在 IAR 中使用过此模型)。 也许有一种更好的方法可以在编译器中声明这些变量、例如 extern unsigned long _App_StartDown；？ 毫无疑问、IAR 对允许的可用存储器空间感到困惑。

对在这方面没有多大帮助表示歉意、
Ryan

你好、Ryan。

很抱歉更新太晚了。

我接触了 IAR 支持、在 IAR 中、似乎需要使用大指针、不仅需要将代码模型更改为大代码模型、还需要将数据模型更改为大代码模型。

现在、我解决了问题的一部分、引导加载程序运行良好。

我的引导加载程序将使用大型代码和数据模型、但由于库限制、我的应用程序无法使用大型数据模型、因此在我的应用程序中、我必须使用一些权变措施(如我之前建议的那样)从链接器文件中检索变量。

我认为在引导加载程序中使用大数据模型和在应用程序中使用小数据模型(两者都将使用大代码模型)不会有任何问题。

此致、

Jorge Cunha

你好、Ryan。

如果您能帮我、我还有另一个问题。

为了进行调试、我是否有任何方法可以强制我的应用程序放置在我的下载区域中？

我尝试下载具有偏移的额外映像、但由于我的应用程序使用引导加载程序区域下方和上方的空间、因此额外的映像下载会考虑到这一点。 因此、应用程序的高内存部分会被引导加载程序的大小所抵消。

另一个选项是对二进制原始数据使用--input，但这也考虑到了同样的问题。

我是否可以通过任何方法来实现它？

此致、

豪尔赫

您好 Jorge、

我不太理解您尝试的是什么、但我不知道调试由自定义引导加载程序代码安装的应用程序的正式或正确方法。 应用程序运行后、您可以尝试使用应用程序项目中的程序符号调试正在运行的目标。 最佳选择可能是在自定义引导加载程序和应用程序代码之前单独对其进行完全调试(使用默认命令链接器文件)、并添加 MSPBoot 所需的其他必要文件。

此致、
Ryan

你好、Ryan。

我尝试合并应用程序和引导加载程序、但强制在下载区域放置应用程序。

但是、由于我的应用程序(同时使用低内存和高内存)环绕在引导加载程序周围、因此这不起作用。

我无法简单设置偏移、因为为此、我需要应用程序的低存储器部分和高存储器部分的另一个偏移。

这似乎是一个不执行的选项。

此致、

豪尔赫

您好 Jorge、

如果问题是环绕/偏移、那么不使用较低的存储器(0xC000至0xEFFF)并将应用程序和下载区域限制为>0x10000、您会从中受益吗？ 我知道这不是理想的、但它可能是调试的简单权变措施。

此致、
Ryan