Hardware Mutex for Peripheral Access RT1176

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Hardware Mutex for Peripheral Access RT1176

ソリューションへジャンプ
1,501件の閲覧回数
D_TTSA
Contributor V

Good day

I am working on NXP's RT1176 processor, which has the ARM Cortex-M7 (master) and -M4 (slave) cores.

At a point in my code, I would like to restart the M4 in the M7's code. To do this, I have made use of the code from the MU SDK example (which follows boot procedure in i.MX RT1170 Dual Core Application (nxp.com)

D_Tram23_0-1631198969319.png

This resets the M4 successfully, but there's a catch. After resetting the M4, the M7 can't use the Ethernet (ENET_1G) port (I believe the interrupts are not triggered). I have had problems with using the LPI2C as well, so it isn't just an Ethernet problem. It seems that the peripherals that the M7 uses cannot be accessed, but the M4 can access the peripherals just fine.

It is worth noting that I do not use the ENET_1G module in my M4 project. The M4 only makes use of the other Ethernet module (ENET).

I think this problem is linked to the hardware mutex that controls the access to shared resources. It is possible that the M4 core is not releasing this mutex after it has restarted,. This must be released for both cores to access the necessary peripherals again.

If someone could provide me with some information on this, it would be greatly appreciated!

Kind regards

0 件の賞賛
返信
1 解決策
1,462件の閲覧回数
D_TTSA
Contributor V

We’ve resolved the issue.

The problem was that BOARD_BootClockRUN() was called at the top of the main() in the M4.
So when the M4 was restarted, it would overwrite the clock configuration that was setup by the M7’s BOARD_BootClockRUN() .

As a result, the M7 couldn’t use any of its peripherals properly after an M4 reset, as the clocks were incorrect.

The solution required the following steps:

  1. Remove the clock configuration code from each individual source file (in both projects)
  2. Configure the required clocks in the M7’s clock ConfigTool
  3. Remove the BOARD_BootClockRUN() call in the M4’s main()
  4. Add the clock configuration required for the M4 core to the M4's main. This code was identified by trial and error from BOARD_BootClockRUN() code surrounded by #ifdef __M_CORE_ == 4. 
    The required code is shown below:
    D_Tram23_0-1631708747660.png

元の投稿で解決策を見る

0 件の賞賛
返信
1 返信
1,463件の閲覧回数
D_TTSA
Contributor V

We’ve resolved the issue.

The problem was that BOARD_BootClockRUN() was called at the top of the main() in the M4.
So when the M4 was restarted, it would overwrite the clock configuration that was setup by the M7’s BOARD_BootClockRUN() .

As a result, the M7 couldn’t use any of its peripherals properly after an M4 reset, as the clocks were incorrect.

The solution required the following steps:

  1. Remove the clock configuration code from each individual source file (in both projects)
  2. Configure the required clocks in the M7’s clock ConfigTool
  3. Remove the BOARD_BootClockRUN() call in the M4’s main()
  4. Add the clock configuration required for the M4 core to the M4's main. This code was identified by trial and error from BOARD_BootClockRUN() code surrounded by #ifdef __M_CORE_ == 4. 
    The required code is shown below:
    D_Tram23_0-1631708747660.png
0 件の賞賛
返信