Hardware Mutex for Peripheral Access RT1176

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Hardware Mutex for Peripheral Access RT1176

Jump to solution
1,137 Views
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 Kudos
1 Solution
1,098 Views
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

View solution in original post

0 Kudos
1 Reply
1,099 Views
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 Kudos