The HW_SSP_CTRL0_RUN bit is not cleared after first write to SPI-NOR memory (i.MX278)

[lmajewski]

Please find more detailed explanation of the problem.

Setup:

• iMX287SoC (rev. 1.2) with SSP2 used to read the boot device (SPI-NOR).
• u-boot
• HAB is supported (u-boot.sb built with combining u-boot.{bin|ivt|sig|dtb}. However, there are some HAB events displayed on the console and most of all the device is not "locked" (fuses are not touched).

Reproduction steps:

• Perform some busy looping to heat up the device (die temperature to 70 deg C - measured with LRADC ch9 and ch8) and reset (with u-boot reset command) it all the time (the u-boot's bootcmd command is properly adjusted)
• It takes around 10 minutes of continuous restarts to observe the issue

Problem:

• The device hangs (sporadically) when SPI-NOR memory is accessed for the first time in u-boot (to read envs)
• It looks like the only previous user of SSP2 is the BOOT ROM of iMX287
  
• By "hangs" - I mean the transmission via SSP2 is stopped. The HW_SSP_CTRL0_RUN bit (29) in HW_SSP_CTRL0 register is not cleared after the successful transmission. The sent command is 0x9F (CMD_READ_ID). The 0x9F is sent from imx287 SoC (I can read it from the oscilloscope). The clock and MOSI signals have the same shapes in both cases (no distortion).
• Subsequent calling of `sf probe 2:0` causes the device to work correctly (it is unlocked and operates correctly).
• The problem happens in PIO mode (not DMA) : https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/spi/mxs_spi.c#L125 [*]

Note:

• I've found on the Internet similar issue: https://community.nxp.com/t5/i-MX-Processors/About-SPI-I-F-control-for-MX28/td-p/447819 but the recommendation was to use the code to wait for the result in busy waiting. Such code is already present in the u-boot used by me.
• In the thread above NXP's customer suggested to read HW_SSP_STATUS register to "unlock" the state of HW_SSP_CTRL0. Is this recommended?

Questions to be answered:

• I would like to know if the above problem is known - in other words if there is a possibility for the SSP2 controller to lock itself?
• Is reading the HW_SSP_STATUS register helping in preventing the locking ? -> This seems not to be the case, as on my setup reading it didn't "clear" the RUN bit.
  
• Can the BOOT ROM is some case leave the SSP2 controller in unstable condition?

I've attached:

• Dump of SSP2 registers just after the hang [*] (after the printf statement).
• Dump of AHB_to_APBH registers just after the hang [*]

Interesting observation:

• The SSP2 works with 40MHz clock. Reducing this frequency to 26.6 MHz causes this error to not be apparent anymore.

[lmajewski]

The imx28 datascheet:

https://www.nxp.com/docs/en/data-sheet/IMX28CEC.pdf

in point "3.5.14.4 SPI AC Timing" recommends using SPI CLK frequency (for SSP2) not higher than 20 MHz. In my application 40 MHz was set (as it is also present on the Linux kernel DTS - for example for imx28-evk.dts)

[lmajewski]

I've debugged more thoroughly the AHB-to-APBH DMA state for the Channel 2 (SSP2).

The dump of its registers can be found in the file attached in the above file - those are the next instruction after the SSP2 PIO transfer hangs. 

HW_SSP_STATUS:

(gdb) p/x *0x80014100

$3 = 0xe00c0020

Here we do have set the: `ssp_dmareq` and `ssp_dmaend` signals

The same signals are visible on the APBH debug registers:

HW_APBH_CH2_DEBUG1

(gdb) p/x *0x80004230

$15 = 0x90a00000

HW_APBH_CH2_DEBUG2

(gdb) p/x *0x80004240

$16 = 0x0

In the CH2_DEBUG1 register the "REQ" [bit31] and "END" [bit28] are set.

Please correct my understanding - does this mean that the SSP2 IP block first requested

DMA CMD/DATA and then (immediately?) signaled the END of this transfer?

Other IP blocks have the CHX_DEBUG1 as 0xb0a0_0000 (REQ, KICK,END) or just 0x00a0_0000 (IDLE, no operation).

I also assume the WR|RD_FIFO_EMPTY are correctly set to indicate that nothing has left for the transfer?