我有一个自定义板，在那里我为我的应用程序改编了示例ble_app_all_in_one。我使用ARCH_EXT_SLEEP_OTP_COPY_ON。到目前为止一切正常，但是当我禁用CFG_DEVELOPMENT_DEBUG时，设备会在几秒钟后一致地重新启动。
对可能发生的事情有任何提示吗?
嗨,螺旋,
这个宏启用开发/调试模式。对于生产模式构建，必须禁用它。请定义此宏并在调试模式下运行代码。你的固件会崩溃吗?
谢谢,PM_Dialog
是的，当我定义这个宏一切工作(没有崩溃)。
我想在生产模式下禁用它，但大约两秒钟后它崩溃并重新启动——但只有当我把它刻录到Flash时，而不是当我在调试器中运行它时。
我在OTP中刻录了引导加载程序。
所以，你打算烧掉OTP然后从那里启动吗?当启用CFG_DEVELOPMENT_DEBUG时，它允许将OTP镜像模拟到System RAM。你能澄清一下你在OTP中烧毁了哪个引导程序吗?如果您将睡眠配置更改为ARCH_EXT_SLEEP_ON，您是否仍然面临同样的问题?
我们的HW制造商烧毁了一个引导加载程序在OTP，我们从那里引导，在flash中没有引导加载程序。不幸的是，我不知道它到底是哪个引导加载程序，但我怀疑它是相当标准的(但可能是一个较老的SDK?)
当我使用ble_app_all_in_one时也会发生这个问题。我只是添加了一个LED输出来查看FW何时运行，何时重启……启用CFG_DEVELOPMENT_DEBUG后，所有工作都很好。但是当我禁用CFG_DEVELOPMENT_DEBUG时，它每5秒重新启动一次。如果我通过BLE快速连接，在5秒之前，它不会重启，只要我保持连接。当我断开连接后，几秒钟后它会重新启动。
这发生在ARCH_EXT_SLEEP_OTP_COPY_ON和ARCH_EXT_SLEEP_ON…
能分享一下你做了哪些修改吗?请尝试使用没有睡眠模式的ble_app_barebone SDK示例，并且CFG_DEVELOPMENT_DEBUG未定义。当从Flash启动时，你有同样的问题吗?请尝试从系统ram引导。
我对ble_app_all_in_one项目和ble_app_barebone所做的唯一修改是将这些行添加到user_peri_setup .c GPIO_reservations()和set_pad_functions()以关闭面板led。引导加载程序将所有三个led都打开，因此我可以通过led的状态看到何时发生重新启动。
#define GPIO_RED_LED_PORT GPIO_PORT_0 #define GPIO_RED_LED_PIN gpio_pin2 #define GPIO_GREEN_LED_PORT GPIO_PORT_2 #define GPIO_GREEN_LED_PIN GPIO_PIN_5 #define GPIO_BLUE_LED_PORT GPIO_PORT_2 #define GPIO_BLUE_LED_PIN GPIO_PIN_9 RESERVE_GPIO(LED, GPIO_RED_LED_PORT, GPIO_RED_LED_PIN, PID_GPIO)Reserve_gpio (led, gpio_green_led_port, gpio_green_led_pin, pid_gpio);Reserve_gpio (led, gpio_blue_led_port, gpio_blue_led_pin, pid_gpio);GPIO_ConfigurePin(GPIO_RED_LED_PORT, GPIO_RED_LED_PIN, OUTPUT, PID_GPIO, true);GPIO_ConfigurePin(GPIO_GREEN_LED_PORT, GPIO_GREEN_LED_PIN, OUTPUT, PID_GPIO, true);GPIO_ConfigurePin(GPIO_BLUE_LED_PORT, GPIO_BLUE_LED_PIN, OUTPUT, PID_GPIO, true);
问题:
你有定制板吗，或者你正在使用我们的开发套件?由于这两个项目都在活动模式下工作，并且CFG_DEVELOPMENT_DEBUG未定义，我猜问题可能与睡眠模式有关。你使用哪个时钟作为低功率时钟?
是的，很明显这个问题与睡眠模式有关。
问题发生在定制板上，如上所述。定制板上的OTP被烧毁了。
我也有一个基本的开发工具包，那里的问题没有发生，而且OTP也没有烧毁那里。
我的OTP头说睡眠时钟源=外部晶体。HW文档也证实了32k振荡器被用作延长睡眠模式的时钟。也许我在我的应用程序中没有正确配置?检查什么?
当然我可以烧SPI flash，但如果我烧引导加载程序到flash和OTP也烧，它会使用flash中的引导加载程序吗?看来不是，我今天也试过了。当我将引导加载程序刻录到Flash时也会发生这个问题。
当我下载固件通过Keil，通过调试器。使用调试器时不会发生此问题。有没有办法下载固件通过Keil然后分离调试器?
好的，我已经在arch_main.c中追踪到以下两行:
SetBits16 (SYS_CTRL_REG DEV_PHASE 1);retained_ram_blocks = ret_mode;
如果存在这些，就像定义DEVELOPMENT_DEBUG时一样，则不会出现崩溃/重新引导。
根据DA14585 datasheet, SYS_CTRL_REG的DEV_PHASE位域设置开发阶段模式。如果设置了这个位，结合OTP_COPY位，OTP DMA将模拟系统RAM的OTP镜像。没有实际写入RAM，但花费的时间与镜像发生的时间完全相同。这是为了模仿行为，就好像系统代码已经在OTP中了，镜像在唤醒后发生，但是(开发)代码仍然驻留在外部源中。如果这个位被设置为'0'并且OTP_COPY='1'，那么OTP DMA将在唤醒时实际执行OTP镜像。
那么，当拥有开发阶段模式时，代码在所有情况下都正确运行?
是的，这就是我上面所说的。是的，我读过数据表。
谢谢您的指示。
问候,PM_Dialog
有什么消息吗?你认为我应该在产品版本中启用这个标志吗??对我来说，这个问题还没有解决。这充其量是一种变通方法。
你在ble_app_all_in_one项目中做了其他的修改吗?默认SDK在发布时使用扩展睡眠模式和OTP副本。请检查user_app_adv_start()。如果您有CFG_DEVELOPMENT_DEBUG，我认为您应该烧掉OTP。然而，请注意，OTP代表一次性可编程，因此您不能擦除和重写OTP多次，但您只能翻转位，仍然设置为0，并将它们变成1。
嗨,螺旋,
这个宏启用开发/调试模式。对于生产模式构建，必须禁用它。请定义此宏并在调试模式下运行代码。你的固件会崩溃吗?
谢谢,PM_Dialog
是的，当我定义这个宏一切工作(没有崩溃)。
我想在生产模式下禁用它，但大约两秒钟后它崩溃并重新启动——但只有当我把它刻录到Flash时，而不是当我在调试器中运行它时。
我在OTP中刻录了引导加载程序。
嗨,螺旋,
所以，你打算烧掉OTP然后从那里启动吗?当启用CFG_DEVELOPMENT_DEBUG时，它允许将OTP镜像模拟到System RAM。你能澄清一下你在OTP中烧毁了哪个引导程序吗?如果您将睡眠配置更改为ARCH_EXT_SLEEP_ON，您是否仍然面临同样的问题?
谢谢,PM_Dialog
我们的HW制造商烧毁了一个引导加载程序在OTP，我们从那里引导，在flash中没有引导加载程序。不幸的是，我不知道它到底是哪个引导加载程序，但我怀疑它是相当标准的(但可能是一个较老的SDK?)
当我使用ble_app_all_in_one时也会发生这个问题。我只是添加了一个LED输出来查看FW何时运行，何时重启……启用CFG_DEVELOPMENT_DEBUG后，所有工作都很好。但是当我禁用CFG_DEVELOPMENT_DEBUG时，它每5秒重新启动一次。如果我通过BLE快速连接，在5秒之前，它不会重启，只要我保持连接。当我断开连接后，几秒钟后它会重新启动。
这发生在ARCH_EXT_SLEEP_OTP_COPY_ON和ARCH_EXT_SLEEP_ON…
嗨,螺旋,
能分享一下你做了哪些修改吗?请尝试使用没有睡眠模式的ble_app_barebone SDK示例，并且CFG_DEVELOPMENT_DEBUG未定义。当从Flash启动时，你有同样的问题吗?请尝试从系统ram引导。
谢谢,PM_Dialog
我对ble_app_all_in_one项目和ble_app_barebone所做的唯一修改是将这些行添加到user_peri_setup .c GPIO_reservations()和set_pad_functions()以关闭面板led。引导加载程序将所有三个led都打开，因此我可以通过led的状态看到何时发生重新启动。
问题:
嗨,螺旋,
你有定制板吗，或者你正在使用我们的开发套件?由于这两个项目都在活动模式下工作，并且CFG_DEVELOPMENT_DEBUG未定义，我猜问题可能与睡眠模式有关。你使用哪个时钟作为低功率时钟?
谢谢,PM_Dialog
是的，很明显这个问题与睡眠模式有关。
问题发生在定制板上，如上所述。定制板上的OTP被烧毁了。
我也有一个基本的开发工具包，那里的问题没有发生，而且OTP也没有烧毁那里。
我的OTP头说睡眠时钟源=外部晶体。HW文档也证实了32k振荡器被用作延长睡眠模式的时钟。也许我在我的应用程序中没有正确配置?检查什么?
当然我可以烧SPI flash，但如果我烧引导加载程序到flash和OTP也烧，它会使用flash中的引导加载程序吗?看来不是，我今天也试过了。当我将引导加载程序刻录到Flash时也会发生这个问题。
当我下载固件通过Keil，通过调试器。使用调试器时不会发生此问题。有没有办法下载固件通过Keil然后分离调试器?
好的，我已经在arch_main.c中追踪到以下两行:
如果存在这些，就像定义DEVELOPMENT_DEBUG时一样，则不会出现崩溃/重新引导。
嗨,螺旋,
根据DA14585 datasheet, SYS_CTRL_REG的DEV_PHASE位域设置开发阶段模式。如果设置了这个位，结合OTP_COPY位，OTP DMA将模拟系统RAM的OTP镜像。没有实际写入RAM，但花费的时间与镜像发生的时间完全相同。这是为了模仿行为，就好像系统代码已经在OTP中了，镜像在唤醒后发生，但是(开发)代码仍然驻留在外部源中。如果这个位被设置为'0'并且OTP_COPY='1'，那么OTP DMA将在唤醒时实际执行OTP镜像。
那么，当拥有开发阶段模式时，代码在所有情况下都正确运行?
谢谢,PM_Dialog
是的，这就是我上面所说的。是的，我读过数据表。
嗨,螺旋,
谢谢您的指示。
问候,PM_Dialog
有什么消息吗?你认为我应该在产品版本中启用这个标志吗??对我来说，这个问题还没有解决。这充其量是一种变通方法。
嗨,螺旋,
你在ble_app_all_in_one项目中做了其他的修改吗?默认SDK在发布时使用扩展睡眠模式和OTP副本。请检查user_app_adv_start()。如果您有CFG_DEVELOPMENT_DEBUG，我认为您应该烧掉OTP。然而，请注意，OTP代表一次性可编程，因此您不能擦除和重写OTP多次，但您只能翻转位，仍然设置为0，并将它们变成1。
谢谢,PM_Dialog