[参考译文] F28M35H52C：出于固件更新目的将 UART0外设映射到替代引脚

Michael、您好！

我不知道有这样的示例(您当前是否在使用特定示例？)、但让我进一步研究这个示例并在明天为您提供更新。

此致、

艾里森

尊敬的 Allison：

不、我们目前没有使用任何特定示例。 这是我们第一次尝试将 UART0重新分配给备用引脚、我们正在寻求有关该主题的任何相关信息和/或指导。

话虽如此、我们期待您的最新动态。
感谢您的帮助。

此致、Michael

Michael、您好！

为了说明这一点、您是否尝试对 UART0仅使用不同的 GPIO (如果我错、请更正我)？

有多组不同的 GPIO 可用于 UART0、具体取决于您的 GPIO 寄存器设置、如  表4-2中的器件 TRM 所述。 GPIO 引脚和交替模式功能：

• GPIO0和 GPIO1
• GPIO27和 GPIO28
• GPIO35和 GPIO36
• GPIO58和 GPIO59

还有第 4.1.4节"初始化和配置"、其中包含示例 UART GPIO 配置代码。 请告诉我此信息是否对您有所帮助！

此致、

艾里森

尊敬的 Allison：

是的、但是... 我们清楚地知道外设可被重新分配到应用的替代引脚、并且这不会产生任何问题。 我们的问题是、对于与引导加载程序的通信、UART0仅分配给 PA0和 PA1引脚、如表6-8中所示。 这些引脚已在我们的应用中使用、我们需要引导加载程序来使用 GPIO28、29。 我们希望确保就引导加载程序而言、此类重新分配是可行的。

问题3： 是否有任何限制可能阻止我们在自定义引导加载程序中使用 GPIO28、29个引脚与 UART0？ 我们打算使用"引导至 OTP"选项。

此致、Michael

Michael、您好！

感谢您的澄清。 在重新配置 UART 引脚时、应该没有限制(除非您尝试使用必须配置 备用引导模式引脚的引导引脚(GPIO34、35、47、43)。  

此致、

艾里森

尊敬的 Allison：

好的、那么我们的计划是使用引导至 OTP 引导模式、并将我们的自定义引导加载程序的起点放在 M-boot_rom_otp_entry_point 位置。 该自定义引导加载程序内部有一些自定义配置函数、与 TI 的 ConfigureDevice ()函数类似，将配置 UART0外设。 但与 ConfigureDevice ()相反,我们的自定义函数将使用替代引脚集,即 GPIO28,29。 因此、我们希望 UART0能够通过这组备用引脚下载闪存内容、因为目前没有阻止此类重新配置的已知限制。

请确认该方法正确无误、如果您认为错误、则应予以否定。

此致、Michael

尊敬的 Allison：

请回答我以上的问题吗？

谢谢您、Michael