topic Re: Cortex-M4 firmware runs inconsistently accross different flavors of iMX6SX in i.MX Processors

Cortex-M4 firmware runs inconsistently accross different flavors of iMX6SX

omidehtemamhagh — Mon, 12 Dec 2016 03:22:13 GMT

Hello,

I am trying to run a firmware (pingpong or any other of the provided examples by NXP) on the Cortex-M4 of iMX6SX. The firmware is placed in the TCM and run from there. When I run the firmware on a Boundary Device Dev board which uses a MCIMX6X4EVM10AB (19x19) it works without any problem and I am able to see the output on UART2 and u-boot works fine afterwards. However when I run it on another board with the same u-boot but uses a MCIMX6X1CVO08AB (17x17) there is no output on UART2 and u-boot crashes right after and I have to reboot the board.

Does any one have any clue?

Thanks in advance

Re: Cortex-M4 firmware runs inconsistently accross different flavors of iMX6SX

igorpadykov — Mon, 12 Dec 2016 08:39:16 GMT

Hi omidehtemamhaghighi

instability issues were reported on rev.1.2 processors (maskset 2N19K)

which were fixed on rev.1.3 maskset 3N19K.

Also for new board/processor recommended to rebuild uboot with new ddr

settings found from ddr test and remove references for modules not present in processor

https://community.freescale.com/docs/DOC-105652

As another uart2 test one can try

https://community.nxp.com/thread/351961

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: Cortex-M4 firmware runs inconsistently accross different flavors of iMX6SX

omidehtemamhagh — Mon, 19 Dec 2016 00:40:47 GMT

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