[参考译文] MSP430F2617：无效的 CPU 启动

这种行为与初始化的数据"太大"且数据复制期间 WDT 超时的情况一致。 我想缓坡可能会影响"太大"的定义。

通常的权变措施是添加类似[参考 CC 用户指南(SLAU132U)第6.9.1]节的内容

int _system_pre_init(void) {
    WDTCTL = WDTPW | WDTHOLD;   // Stop watchdog
    return(1);                  // You can finish C initialization now
}

我认识到数据初始化可能会导致这种情况，但正如我所指出的，我们使用的是`_low_level_init ()`，这是 IAR 版本的`系统_pre_init ()`，因此在进行任何数据初始化之前都要执行所有测量。

我@了反汇编并验证了在启动代码 Δ Σ 复位中初始化 SP 后立即在指令中调用__low_level_init()，因此不会出现数据初始化导致这些意外看门狗的情况。

我们还单独测量了数据初始化阶段、使其持续约7-8ms、因此我们知道这不是根本原因。

上下文-为了清晰起见、下面附上了我们的低级初始化代码

/**
 * Low-level pre-init code.
 *
 * @return Non-zero if segment initialization should continue normally. Zero if segment
 *         initialization should be skipped.
 */
int __low_level_init(void)
{
    // Debug code to indicate processor startup
    CHIP_GPIO_OUTPUT_HIGH(P3OUT, BIT6);

    // Debug code to flag initial watchdog indication
    if (IFG1 & WDTIFG)
    {
        CHIP_GPIO_OUTPUT_HIGH(P3OUT, BIT7);
    }
    else
    {
        CHIP_GPIO_OUTPUT_LOW(P3OUT, BIT7);
    }

    // (Not shown) Configure P3.6 and P3.7 as outputs

    // Wait for the supply to ramp up to at least 2.1V before configuring the internal battery.
    SVSCTL = (VLD1);

    // (Not shown) Wait for the SVS to turn on and indicate no low voltage

    // Disable the SVS to conserve power.
    SVSCTL = 0;

    // (Not shown) ... Enable power via the internal battery
    
    return 1;
}

很抱歉,我没有这种区别。 我不知道答案。 (我认为我在 F26-es 中没有看到过这种情况。) [有人？]

1.非正常器件是否每次都能解决此问题？ 如果是、您能否将电源设置为大约2V 以检查器件是否可以正常运行。

2.您能否仅使用一个 while (1)循环和 GPIO 切换来测试非正常器件、以再次检查它与代码之间是否存在关系、但器件本身。

我在数据表中唯一能找到的东西就是这个。 但 V (SVS_IT–)仅在电压从高电平变为低电平时工作。 很奇怪。

1.否-问题非常间歇性(在某些测试期间、它会在50%的时间发生、但随后将进行数千次重试而不会失败)

2.我们开发了一个定制应用程序，其中仅包含：

# RESET vector set to start execution at 0x3100
@ 0xFFFE: 0x3100

# Startup routine
@ 0x3100:
   MOV.W #0x30FC, SP
   CALL.A #__low_level_init
   
# Low-level-init actually located at 0xAE78, flash address in mid memory
@ __low_level_init:
    BIS.B #0x80, &P3OUT
    BIS.B #0x80, &P3DIR
    
    MOV.W #0x5A80,&WDTCTL
    
    # Infinite loop, implemented as 0x3FFF binary instruction.
    JMP PC

然后、我们用0x4343 (NOP)填充闪存的其余部分、并以256字节的间隔放入以下指令：

BIS.B #0x40, &P3OUT
BIS.B #0x40, &P3DIR

MOV.W #0x5A80, &WDTCTL
JMP PC

名义上、我们希望 P3.7有效。 正常运行的器件(例如、在 P3.7有效后无限循环)。 但是、我们偶尔会看到 P3.6生效、这向我们表明处理器正在闪存中执行任意代码。

1.有线连接很好。 如果 P3.6生效、则表示 P3OUT 和 P3DIR 中的 BIT6被置位。

2.由于无法始终重新创建、我认为它可能位于规格的边界。 由于数据表中的限制、很难判断路由原因是什么。 对于 MCU 状态、我不知道它是否在引导代码中被阻止、或者 CPU 甚至不工作。

至少我们知道问题与电源有关。 您能否将电源电压设置为2V 并对其重新供电、以查看它是否能够正常运行至主函数。 这可能是一种消除某些不确定选择的方法。