Thanks Igor for the hint!
After further code debugging I realized the issue is because of the flavor of i.MX6SX I am using, which has no support for PCIe module, when the Cortex-M4 or Cortex-A9 try to access the RDC (Resource Domain Controller).
It is documented in Errata #: ERR009572 of the Chip Errata for the i.MX6SoloX:
Description:
On certain i.MX6 SoloX part numbers that do not support the PCIe module, Freescale programs
the PCIe_DISABLE fuse to disable this module's functionality. When this PCIe_DISABLE fuse is
programmed, it has the inadvertent effect of disabling a clock source required by the Resource
Domain Controller (RDC) module on i.MX6 SoloX. The absence of this clock to the RDC causes
the master (ARM Cortex A9 or M4) that initiates an RDC register access (read or write) to hang.
This issue is only observed on specific part numbers that have the PCIe_DISABLE fuse
programmed to disable the PCIe module. The part numbers that support PCIe do not have this
issue.
Projected Impact:
The ARM Cortext-A9 or ARM Cortext-M4 can hang.
Workarounds:
No software workarounds available that would allow RDC registers accesses on devices that have
the PCIe_DISABLE fuse programmed to disable the PCIe module.
The issue only occurs when a master tries to access the RDC and has no impact if the application
software does not access any of the RDC registers.
Proposed Solution:
For existing Rev 1.2 silicon devices that do not support the PCIe module, the PCIE_DISABLE fuse
will not be programmed during the manufacturing process. These Rev 1.2 un-fused silicon devices
have date code 1524 or later.
The date code can be read from the package markings. Directly below the part number, there is a
code of the form xxxYYWW. YY is the year (15 for 2015) and WW is the work week number (24
for the 24th calendar week of that year).
Fixed in silicon revision 1.3
Thanks,
Omid
