Hello,
We have designed a modified version of the i.MX6G2 processor board. We are using the SPI interface to communicate with an MRAM chip (Everspin MR25H40VDF(R)). We have successfully communicated with this MRAM chip in the past using a TI MSP430, so we know our interface code works.
We are trying to use the SPI Polling example code in the SDK to talk to the MRAM, but we are not having success. We are pointing to the proper instance of SPI (ECSPI2). The IOMUX settings appear to be correct for ECSPI2 for the five signals (SCLK, MOSI, MISO, CS1, and CS2). We have probed the various SPI signals. CS# gets pulled low properly. Data gets sent-out MOSI.
However, there is no clock signal sent out of the MCU. We have checked our schematic, and the clock appears to be connected properly. We are using the original version of the BOARD_BootClockRUN() function from the SPI Polling example.
Is there something about the stock code for the SPI Polling example in the SDK that needs to be modified?
Here are the versions of the hardware and software that we are using:
Hardware
Processor Kit: MCIMX6UL-EVKB
Base Board: MCIMX6UL-BB
Processor Board: MCIMX6UL-CM
Processor: MCIMX6G2CVM05AA
Software
IDE: IAR Embedded Workbench Arm 8.32.4
Debug Probe: IAR I-jet
MCUXpresso Software Development Kit (SDK) Release Version: 2.2.0
Thank you for any help you can provide.
Dennis Jelcic
Solved! Go to Solution.
Hi Dennis
one can check if ecspi2 clocks are enabled in CCM_CCGR1 register.
Also recheck pin muxing for pads CSI_DATA00, UART4_TX_DATA, which
could provide ecspi2 clock. Reconfigure them as gpio and try to toggle, check
if ecspi2 traces and not shorted with other signals.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hi Igor,
We did figure-out the problem. Your suggestion to check the pin muxing was a good one. We were not providing enough drive strength on the pins. Once we adjusted this, the clock signal appeared and behaved as expected.
Thanks you very much for your help.
Dennis
Hi Dennis
one can check if ecspi2 clocks are enabled in CCM_CCGR1 register.
Also recheck pin muxing for pads CSI_DATA00, UART4_TX_DATA, which
could provide ecspi2 clock. Reconfigure them as gpio and try to toggle, check
if ecspi2 traces and not shorted with other signals.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------