RT1176 FlexSPI Config Tool Generated Init Code: Bug and Fix

[zylalx1]

Below is part of the config tool generated init code (SDK14.0, flexspi peripheral drivers 2.5.0) which does not work. 

static void FLEXSPI2_init(void) {
  /* FLEXSPI2 peripheral initialization */
  FLEXSPI_Init(FLEXSPI2_PERIPHERAL, &FLEXSPI2_config);
  /* Update LUT table. */
  FLEXSPI_UpdateLUT(FLEXSPI2_PERIPHERAL, 0, FLEXSPI2_LUT, FLEXSPI2_LUT_LENGTH);
  /* Configure flash settings according to serial flash feature. */
  FLEXSPI_SetFlashConfig(FLEXSPI2_PERIPHERAL, &FLEXSPI2_config_Device_0, kFLEXSPI_PortA1);
}

The problem is the MCR0->MDIS bit is set to 1 in the FLEXSPI_Init function, which means the FLEXSPI is in stop mode. The LUT registers are unaccessible under that mode according to the reference manual, causing the write to LUT registers fails in the FLEXSPI_UpdateLUT function. 

It can be fixed by simply changing the executing sequence of the init functions because the MCR0->MDIS bit is set to 0 in the FLEXSPI_SetFlashConfig function:

static void FLEXSPI2_init(void) {
  /* FLEXSPI2 peripheral initialization */
  FLEXSPI_Init(FLEXSPI2_PERIPHERAL, &FLEXSPI2_config);
  /* Configure flash settings according to serial flash feature. */
  FLEXSPI_SetFlashConfig(FLEXSPI2_PERIPHERAL, &FLEXSPI2_config_Device_0, kFLEXSPI_PortA1);
  /* Update LUT table. */
  FLEXSPI_UpdateLUT(FLEXSPI2_PERIPHERAL, 0, FLEXSPI2_LUT, FLEXSPI2_LUT_LENGTH);
}

But I think modifying the UpdateLUT function itself may be a better solution:

1. Save the MDIS bit state

2. Clear the MDIS bit

3. Write LUT registers

4. Restore the MDIS bit state

This assures the independency of this function, eliminating the risk of accidentally mess up with other steps in the initiating process. 

[CktDesigner]

Hi zylalx1,

Thanks for your post...   It was very helpful in allowing me to get anything to show up on a logic analyzer when trying to debug the FlexSPI interface to my PSRAM.    I can now at least see some signals moving!  (Before your post, I couldn't get anything to show up!!)

However, I'm not seeing what I expected...    Since it sounds like you have already been through this, perhaps you have some hints/answers that will help.

I'm using the FlexSPI on an iMXRT1062.    I'm using SDK version 2.14.1 for SDK_2.x_MIMXRT1062xxxxB

I'm also attempting to use the Config Tool to set things up.   The first thing I'm attempting to do is read the PSRAM ID register.   I chose this because it is one of the easier transactions...    

I do see the CS signal go low as expected to initiate the operation, and it de-asserts at the correct time.

I do see the clock start and it appears to pulse the correct number of times, but it is not at the expected frequency.    I expected a frequency based on the FlexSPI clock set in the "Clocks" tab of the Config Tool.   This same frequency shows up as a selection on the "Peripherals/FlexSPI" tab of the Config tool as the clock source for FlexSPI.     I tried changing this frequency (in the Clocks tab as an experiment) and don't really see a difference in the captured waveform.   I don't see a significant change in the captured waveform, no matter what change I make to the source clock, making me wonder if I'm missing some code that "enables" the clock specified in the Config tool.    Shouldn't the FlexSPI CK signal pulse at the frequency of the root clock?

I also don't see exactly what I expect for the command/address lines.  I'm attempting to interface to an ISSI IS66WVQ8M4DALL/BLL device.   I made some adjustments to the LUT entry to accommodate the SDR for command and DDR for the address and data (as required by the device).   The command seems to come out as expected, but the address does not.  (This device has a "strange" requirement on the position of the row and column bits that requires some adjustment of the source address delivered to FLEXSPI.)   Note that reading the ID register doesn't really need a complicated address, but I'm using this command to view the behavior of FlexSPI.

I posted a Support Request (Case 00594771) for this problem and one of the responses pointed me to your post.   The case also has some screen shots of my setup, but I wasn't able to get anything resolved...

Do you have any suggestions?

Many thanks!!

[zylalx1]

There is another bug in the config tool generated code. Not sure if it's related to your case but I got my flexspi worked after fixing that one. 

https://community.nxp.com/t5/i-MX-RT/RT1176-FlexSPI-Config-Tool-Generated-Init-Code-Another-Bug/m-p/... 

I'm not a NXP staff so I can't see your support ticket. Maybe you can provide more detail of your setup here. 

[CktDesigner]

Thanks for your response!

I think I found one of my problems.   Since I am booting from SDcard and running from ITCM/DTCM (on a custom board), I needed to define XIP_EXTERNAL_FLASH as '0'.   This then "ifdefs out" where the FlexSPI clock is defined (in config_clock.c).     It looks like there are a number of "defines" that may be in the SDK code specifically for the EVK board that tend to get in the way when using the chips in custom boards.

In any case, if I set XIP_EXTERNAL_FLASH to '1' (to allow the FlexSPI clock code in config_clocks.c to be included) other things (like the USB interface) fails...    So I "manually" put the FlexSPI clock code in and I now have clocks.

One other place I'm having trouble is defining row and column bits for the PSRAM I'm using.   I think I understand the RADDR_SDR/DDR and CADDR_SDR/DDR LUT commands as sending row and column address bits, but seem to be having trouble getting CAS bits to come out.   The operands for these LUT commands indicate how many bits should be sent.   There is also a parameter named columnspace that appears to define how many bits are in the column address.

My PSRAM (ISSI ISS66WVQ8M4DALL/BLL) has a "strange" CAS configuration.  The CAS portion is 9 bits, but offset/embedded with some reserved ('0') bits to fill in a full 16-bit CAS field:

For IP style accesses, I can manipulate the address, so I take the original access address and break it into a row section and column section (with the column bits properly adjusted).   The row part is placed in bits 31:16 of the new access address and the column portion is placed in bits 15:0 of the new access address.   Then the access is started with RADDR_DDR with 16 bits and CADDR_DDR with 16 bits.   Columnspace is set to 16.   My assumption is that the row bits are taken from the address register (offset by the columnspace bits) and the col bits are taken from the address register starting at bit 0.   But I don't see any column bits (they are all '0').     I got around this by treating all of the bits as row bits and using RADDR_DDR with 32 bits.

But this won't work when trying to access via AHB.   The AHB address to FlexSPI translation appears to go directly to the LUT, so there isn't an opportunity to modify the bits to deal with the CAS offset as needed by this device.    I may need to design in a different PSRAM...

If I do use a different PSRAM, I may want to switch to an 8-bit interface.   But app note AN13028 indicates (in section 5.5.2) that there may be a limitation when using iMXRT1060 (I'm using iMXRT1062) devices...    I'm not sure exactly what limitation is being referred to...

Any comment on the above issues?

Thanks!!!

[zylalx1]

For the CADDR issue, did you set the CAS field in the Flash Control 1 register? ("Column space size" in config tool)

I'm using a spi nand flash, which has a similar "padding to 16bit" on CADDR. But I don't see any issue with the addr on my board. 

For SoC limitation on 8-bit PSRAM, I don't have any idea. But I don't think it's a good idea trying to use it since NXP said you may run into problem. 

[CktDesigner]

Thanks again for your reply.   Yes, I set the CAS value, but I believe this defines the number of bits for the column portion of the address.   But I need to offset those bits by 5 (the low order 5 bits of the column address field (to the PSRAM) are reserved), then put in the 9 actual column bits, then pad the remainder of the column bits.    I submitted a new question to NXP...

Thanks again!

[EdwinHz]

Hi @zylalx1,

Thanks for reporting this! I will take a look into it and pass on the comments to the ConfigTools team so they van evaluate your insights further.

BR,
Edwin.