This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM263P4:从闪存引导时 MCAN 波特率错误

Guru**** 2528480 points
Other Parts Discussed in Thread: AM263P4, SYSCONFIG

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1557358/am263p4-mcan-baudrate-wrong-when-booting-from-flash

器件型号:AM263P4
主题: SysConfig 中讨论的其他器件

工具/软件:

您好、

我有一个可正常工作的多核工程、在 devboot 模式下使用 CCS 加载时、工作正常。 MCAN 波特率应为 1000kbit/s

但是、当这个工程在 OSPI 引导模式下通过 SBL 从闪存加载时、波特率错误、约为 310kbit/s

  1. 这里的问题可能是什么?  
  2. 使用 CCS 加载时、gel-files 会执行许多时钟配置。 通过 SBL 引导时、会在何处/何时发生这种情况? 我是否需要在 SBL 中进行一些额外的配置?

其他信息:

SoC:AM263P4_ZCZ_F
MCAN 代码主要来自“CAN_EXTERNAL_READ_WRITE_"示“示例
SBL 代码主要来自“sbl_ospi"示“示例

此致、
Frank

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Frank、

    MCAN 模块的时钟由 ti_power_clock_config.c 中的 Module_clockSetFrequency () 配置 时钟在 同一文件的 gSocModulesClockFrequency[]中定义。

    如果未配置该引脚、则默认 MCNA 时钟源为 WUCPUCLK (25MHz)、时钟分频器为 1。

    如果 MCAN 时钟定义的  SocModuleClockFrequency[]为 80MHz、则预计 80MHz 传输速率为 310Kbps:1000kbps * MCAN/MCAN 25MHz = 310kbps。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    那么、我现在应该做些什么来解决这个问题呢?

    应用程序代码中的 MCAN 在 ti_power_clock_config.c 中像在您的图像中一样进行配置、由于这是自动生成的文件、因此我仍然无法对其进行更改。 此外、向 SBL 添加 MCAN 不会更改观察到的行为。  对我来说、SBL 执行的 SOC 配置与 GEL 文件不同。  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Frank、

    ROM 引导加载程序仅配置引导期间所需的内核 PLL。 SBL 重新配置内核 PLL 和外设 PLL。 内核 CLKOUT0 为 400MHz、CLKOUT1 为 500MHz、每个 CLKOUT0 为 160MHz、CLKOUT1 为 192MHz。

    如果启用了 MCAN (SysConfig)、则 MCAN 时钟配置为来自内核 CLKOUT0 的 80MHz。 您设置中的 MCAN 时钟配置 (POWER_CLOCK_CONFIG.c) 是什么?  

    请仔细检查 PLL 设置(寄存器位于 0x5320_04xx)。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    R5_0 上的应用代码中的时钟设置如下所示:

    SOC_ModuleClockFrequency gSocModulesClockFrequency[] = {
        { SOC_RcmPeripheralId_I2C, SOC_RcmPeripheralClockSource_DPLL_PER_HSDIV0_CLKOUT1, 96000000},
        { SOC_RcmPeripheralId_MCAN1, SOC_RcmPeripheralClockSource_DPLL_CORE_HSDIV0_CLKOUT0, 80000000},
        { SOC_RcmPeripheralId_MCAN0, SOC_RcmPeripheralClockSource_DPLL_CORE_HSDIV0_CLKOUT0, 80000000},
        { SOC_RcmPeripheralId_OSPI0, SOC_RcmPeripheralClockSource_DPLL_CORE_HSDIV0_CLKOUT0, 133333333},
        { SOC_RcmPeripheralId_WDT0, SOC_RcmPeripheralClockSource_SYS_CLK, 200000000},
        { SOC_RcmPeripheralId_LIN0_UART0, SOC_RcmPeripheralClockSource_DPLL_PER_HSDIV0_CLKOUT1, 48000000},
        { SOC_MODULES_END, SOC_MODULES_END, SOC_MODULES_END },
    };

    请回答以下问题、以了解基本工作流程:

    • 如果我使用 MCAN、LIN 或应用程序代码中的任何模块、我是否需要在 SBL 代码/SysConfig 中执行其他操作? 或者在应用程序中使用 SysConfig 进行配置是否足够、并且 SBL 是通用的且独立于应用程序代码。

    我已经比较了 PLL 寄存器。 唯一的区别(CCS 与 OSPI_SBL 加载)是 TOP_RCM_PLL_CORE_CLKCTRL 和 TOP_RCM_PLL_PER_CLKCTRL 中的 PLL_CORE_CLKCTRL_CLKDCOLDOEN 位 和一些状态位、我认为 PLL_CORE_STATUS_CLKDCOLDOACK。 明天我可以再检查一下。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如果您使用 OSPI SBL、则需要检查 SBL 代码以确保 PLL 已重新配置。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我不明白应该怎么做。

    我是否需要在 SBL 中执行特定于应用的操作?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    TI OSPI SBL 示例 重新配置内核 PLL 和外设 PLL。 内核 CLKOUT0 为 400MHz、CLKOUT1 为 500MHz、每个 CLKOUT0 为 160MHz、CLKOUT1 为 192MHz。

    SoC_RcmPeripheralClockSource_DPLL_CORE_HSDIV0_CLKOUT0 在您的 MCAN0 和 MCAN1 设置中使用、分频器应为 MCAN/MCAN0 400MHz = 5 80MHz。 您能否检查是否使用了右分频器对 MCAN 分频器寄存器进行了编程?

    0x53208100 时的 MSS_RCM_MCAN0_CLK_SRC_SEL

    0x53208300 时的 MSS_RCM_MCAN0_CLK_DIV_VAL

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    以下是来自 MMS_CTRL、MMS_RCM 和 TOP_RCM 的所有不同寄存器:

    您提到的寄存器是相同的。

    Address		CCS devboot	SBL OSPI	Register
    			MCAN 1MBd	MCAN 310kBd
    0x50D00020	0x00000000	0x07000700	MSS_CTRL_R5SS0_CONTROL
    0x50D00040	0x00000000	0x00000707	MSS_CTRL_R5SS1_CONTROL
    0x50D0004C	0x00000000	0x00000100	MSS_CTRL_R5SS1_STATUS_REG
    0x50D00054	0x00000000	0x00000011	MSS_CTRL_R5SS1_CORE1_STAT
    0x50D00080	0x00000007	0x00000707	MSS_CTRL_R5SS0_ROM_ECLIPSE
    0x50D00244	0x0000003F	0x00000000	MSS_CTRL_L2IOCRAM_MEM_INIT_DONE
    0x50D00830	0x00000000	0x000001FD	MSS_CTRL_TPCC0_INTAGG_MASK
    0x50D00838	0x00000000	0x00000003	MSS_CTRL_TPCC0_INTAGG_STATUS_RAW
    0x50D18104	0x00000000	0x00000007	MSS_CTRL_R5SS0_CORE0_TCM_ADDRPARITY_ERRAGG_STATUS
    0x50D18108	0x00000000	0x00000007	MSS_CTRL_R5SS0_CORE0_TCM_ADDRPARITY_ERRAGG_STATUS_RAW
    0x50D18164	0x00000000	0x000002D1	MSS_CTRL_R5SS1_CORE0_ADDRPARITY_ERR_ATCM
    0x53208010	0x00000783	0x00000603	MSS_RCM_R5SS0_RST_STATUS
    0x53208024	0x00000707	0x07070007	MSS_RCM_R5SS0_RST_WFICHECK
    0x53208030	0x00000603	0x00000003	MSS_RCM_R5SS1_RST_STATUS
    0x53208044	0x00000707	0x07070707	MSS_RCM_R5SS1_RST_WFICHECK
    0x53208104	0x00000444	0x00000000	MSS_RCM_MCAN1_CLK_SRC_SEL
    0x53208108	0x00000444	0x00000000	MSS_RCM_MCAN2_CLK_SRC_SEL
    0x5320810C	0x00000444	0x00000000	MSS_RCM_MCAN3_CLK_SRC_SEL
    0x5320811C	0x00000222	0x00000000	MSS_RCM_RTI2_CLK_SRC_SEL
    0x53208120	0x00000222	0x00000000	MSS_RCM_RTI3_CLK_SRC_SEL
    0x53208130	0x00000222	0x00000000	MSS_RCM_WDT2_CLK_SRC_SEL
    0x53208134	0x00000222	0x00000000	MSS_RCM_WDT3_CLK_SRC_SEL
    0x5320813C	0x00000333	0x00000000	MSS_RCM_MCSPI0_CLK_SRC_SEL
    0x53208140	0x00000333	0x00000000	MSS_RCM_MCSPI1_CLK_SRC_SEL
    0x53208144	0x00000333	0x00000000	MSS_RCM_MCSPI2_CLK_SRC_SEL
    0x53208148	0x00000333	0x00000000	MSS_RCM_MCSPI3_CLK_SRC_SEL
    0x5320814C	0x00000333	0x00000000	MSS_RCM_MCSPI4_CLK_SRC_SEL
    0x53208150	0x00000333	0x00000000	MSS_RCM_MMC0_CLK_SRC_SEL
    0x53208158	0x00000333	0x00000000	MSS_RCM_CPTS_CLK_SRC_SEL
    0x53208160	0x00000222	0x00000000	MSS_RCM_CONTROLSS_PLL_CLK_SRC_SEL
    0x53208178	0x00000777	0x00000000	MSS_RCM_LIN1_UART1_CLK_SRC_SEL
    0x5320817C	0x00000777	0x00000000	MSS_RCM_LIN2_UART2_CLK_SRC_SEL
    0x53208180	0x00000777	0x00000000	MSS_RCM_LIN3_UART3_CLK_SRC_SEL
    0x53208184	0x00000777	0x00000000	MSS_RCM_LIN4_UART4_CLK_SRC_SEL
    0x53208188	0x00000777	0x00000000	MSS_RCM_LIN5_UART5_CLK_SRC_SEL
    0x53208204	0x00000444	0x00000000	MSS_RCM_MCAN1_CLK_DIV_VAL
    0x53208208	0x00000444	0x00000000	MSS_RCM_MCAN2_CLK_DIV_VAL
    0x5320820C	0x00000444	0x00000000	MSS_RCM_MCAN3_CLK_DIV_VAL
    0x5320823C	0x00000333	0x00000000	MSS_RCM_MCSPI0_CLK_DIV_VAL
    0x53208240	0x00000333	0x00000000	MSS_RCM_MCSPI1_CLK_DIV_VAL
    0x53208244	0x00000333	0x00000000	MSS_RCM_MCSPI2_CLK_DIV_VAL
    0x53208248	0x00000333	0x00000000	MSS_RCM_MCSPI3_CLK_DIV_VAL
    0x5320824C	0x00000333	0x00000000	MSS_RCM_MCSPI4_CLK_DIV_VAL
    0x53208250	0x00000333	0x00000000	MSS_RCM_MMC0_CLK_DIV_VAL
    0x53208258	0x00000111	0x00000000	MSS_RCM_CPTS_CLK_DIV_VAL
    0x53208404	0x00000410	0x00000001	MSS_RCM_MCAN1_CLK_STATUS
    0x53208408	0x00000410	0x00000001	MSS_RCM_MCAN2_CLK_STATUS
    0x5320840C	0x00000410	0x00000001	MSS_RCM_MCAN3_CLK_STATUS
    0x5320841C	0x00000004	0x00000001	MSS_RCM_RTI2_CLK_STATUS
    0x53208420	0x00000004	0x00000001	MSS_RCM_RTI3_CLK_STATUS
    0x53208430	0x00000004	0x00000001	MSS_RCM_WDT2_CLK_STATUS
    0x53208434	0x00000004	0x00000001	MSS_RCM_WDT3_CLK_STATUS
    0x5320843C	0x00000308	0x00000001	MSS_RCM_MCSPI0_CLK_STATUS
    0x53208440	0x00000308	0x00000001	MSS_RCM_MCSPI1_CLK_STATUS
    0x53208444	0x00000308	0x00000001	MSS_RCM_MCSPI2_CLK_STATUS
    0x53208448	0x00000308	0x00000001	MSS_RCM_MCSPI3_CLK_STATUS
    0x5320844C	0x00000308	0x00000001	MSS_RCM_MCSPI4_CLK_STATUS
    0x53208450	0x00000308	0x00000001	MSS_RCM_MMC0_CLK_STATUS
    0x53208458	0x00000108	0x00000001	MSS_RCM_CPTS_CLK_STATUS
    0x53208460	0x00000004	0x00000001	MSS_RCM_CONTROLSS_PLL_CLK_STATUS
    0x53208478	0x00000080	0x00000001	MSS_RCM_LIN1_UART1_CLK_STATUS
    0x5320847C	0x00000080	0x00000001	MSS_RCM_LIN2_UART2_CLK_STATUS
    0x53208480	0x00000080	0x00000001	MSS_RCM_LIN3_UART3_CLK_STATUS
    0x53208484	0x00000080	0x00000001	MSS_RCM_LIN4_UART4_CLK_STATUS
    0x53208488	0x00000080	0x00000001	MSS_RCM_LIN5_UART5_CLK_STATUS
    0x53208804	0x00000555	0x00000000	MSS_RCM_HSM_WDT_CLK_SRC_SEL
    0x53208840	0x00000020	0x00000001	MSS_RCM_HSM_WDT_CLK_STATUS
    0x53209024	0x0000032C	0x00000310	MSS_RCM_FAULT_ADDRESS
    0x53200024	0x0000000B	0x00000003	TOP_RCM_SOP_MODE_VALUE
    0x53200404	0x00095001	0x200B5001	TOP_RCM_PLL_CORE_CLKCTRL
    0x53200424	0xC0001610	0xC0001E10	TOP_RCM_PLL_CORE_STATUS
    0x53200804	0x00095001	0x200B5001	TOP_RCM_PLL_PER_CLKCTRL
    0x53200824	0xC0001618	0xC0001E18	TOP_RCM_PLL_PER_STATUS
    0x53200C20	0x00000222	0x00000000	TOP_RCM_TRCCLKOUT_CLK_SRC_SEL
    0x53200C24	0x00000111	0x00000000	TOP_RCM_TRCCLKOUT_DIV_VAL
    0x53200C2C	0x00000104	0x00000001	TOP_RCM_TRCCLKOUT_CLK_STATUS
    

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    OSPO 的 MCANx 时钟源为 0x0、MCAN 的 MCAN 时钟分频器也为 0x0

    0x53208104 0x00000444 0x00000000 MSS_RCM_MCAN1_CLK_SRC_SEL
    0x53208108 0x00000444 0x00000000 MSS_RCM_MCAN2_CLK_SRC_SEL
    0x5320810C 0x00000444 0x00000000 MSS_RCM_MCAN3_CLK_SRC_SEL

    0x53208204 0x00000444 0x00000000 MSS_RCM_MCAN1_CLK_DIV_VAL
    0x53208208 0x00000444 0x00000000 MSS_RCM_MCAN2_CLK_DIV_VAL
    0x5320820C 0x00000444 0x00000000 MSS_RCM_MCAN3_CLK_DIV_VAL

    这意味着 XTALCLK (25MHz) 用于 OSPI 模式的 MCAN 模块。

    对于 DEV 模式、时钟源为 0x4 (DPLL_CORE_HSDIV0_ CLKOUT0、400MHz)、分频器为 0x5 (4+1)、因此 MCNA 功能时钟为 400/5= 80MHz。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    玩了一会儿后,情况如下:

    重申一下:我正在使用 UND 观察 MCAN1(将配置 MCAN0,但现在实际上并未使用)。 为两者都正确生成了 power_clock_config.c 中的时钟配置代码。 但是、如果我使用 OSPI 引导、只会配置 MCAN0 时钟、而不会配置 MCAN1、从而导致上面显示的寄存器差异和这一主题的原因。

    现在、如果在 main 函数中首先放置一个阻塞 while 循环、那么在 OSPI 引导后、我可以首先与调试器连接并观察时钟初始化情况、它正在正常运行。 因此代码本身是并且正常运行。

    那么、什么可能会导致在没有调试器的 OSPI 引导后只有 MCAN1 时钟配置没有发生?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    此外:仅当同时启动两个内核 R5_0 和 R5_1 时、才会发生该问题。 如果我阻止其中一个函数、使其 System_init() 函数 连续执行、则一切都正常。

    如何应对这种情况?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Frank、

    我不知道为什么 R5-1 代码执行会阻止 R5-0 中的时钟配置。 R5-1 是否覆盖了 MCAN1 时钟配置?  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    不可以、这不是 R5_1 代码(它只更改 WDT1 时钟)。  如果 R5_0 首先运行、然后是 R5_1、则运行。 另一种方法是、首先是 R5_1、然后 R5_0 它也可以工作。 仅当两者都从 OSPI SBL 同时启动(几乎)时、该功能才起作用。

    我将在不使用任何用户代码的情况下稍后重试、仅使用 SysConfig 代码。 也许我会找到一些东西。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    如果您找到根本原因、请告诉我。 谢谢