Are there any known issues with using multiple SEMC device simultaneously?

[EdSutter]

Our hardware (RT1062) has (among other things) SDRAM and an FPGA on which we connect both the SEMC-NOR and SEMC-PSRAM chip selects (and associated addr/data/ctrl) pins.  The bulk of our code executes out of SDRAM and has been working just fine (when not attempting to access the FPGA memory space).

Now I'm trying to pump the FPGA by configuring GPIO_B0_00_SEMC_CSX01 as the chip-select into the FPGA. I set up SEMC->IOCR->MUX_CSX1 as NOR. SEMC->NORCR0 has port size set to 1 (16-bit) and all timing values (NORCR1-3) maxed out for now.  

I have disabled my MPU (for simplicity) and the base address (SEMC->BR[5]) is set to 0xa8000019 (Base address=0xa8000000, size=16MB, Active). 

As soon as I access 0xa8000000 the CPU takes a HardFault exception.  Is there some configuration setup I'm missing?  Is there anything illegal about executing out of SDRAM (SEMC SDRAM bank 0) and accessing EMC-NOR at the same time?

Ed

[EdSutter · Accepted solution]

Final comments regarding this whole issue (if anything below is incorrect, please inform) for anyone else that may walk this path (note this is with reference to iMXRT1062)...

1) I've concluded that it's illegal to attempt to write directly to SEMC->NOR space, it has to be written to using IPCMD protocol.  I concluded this because whenever I wrote to that space my system took a hard-fault.  Eventually I enabled all so-called "interrupts" in the SEMC->INTEN register, and then in my hard-fault handler I queried the INTR register and noticed that the AXIBUSERR bit was set.  That pointed me back to the description of the SEMC->INTR register (25.4.1.17) where one of the causes of an AXIBUSERR is a write to NOR flash space.  So I re-implemented my NOR writes using IPCMD.

2) Different issue, but I'll mention it here cause its also SEMC stuff... I noticed that when I had SEMC->PSRAM space configured for 0xA0000000 my single accesses would result in a burst of CS & WR activity.  I used that address based on this post, but found that it still resulted in multiple accesses; however just by chance I increased my base address to 0xB0000000 and magically the burst went away.  It would be nice to have an explanation for this.

3) Finally, and this is an issue we are still trying to work through for both SEMC->NOR and SEMC->SRAM, the WR line (which is also used by SEMC->SDRAM (MEM_ADDR[11]) needs to be in an inactive (high) state prior to CS going active; but as best we can see, there's a few nanoseconds where CS is active, but WR is still low; hence on the rising edge of WR (with CS active) a spurious edge-triggered write can occur.  Seems that WR needs to go inactive prior to CS going active, but that's not what we're seeing.  If anyone has a solution for this, I'd like to hear it.  

HTH,

[nickwallis]

Hi @EdSutter 

I am seeing the same behaviour as your number (2) - multiple bursts on chip select and output enable for a single access. Unfortunately changing the mapped address did not fix it for me.

Did you ever get an explanation for this behaviour? Did you have any other ideas what might be causing it?

thanks and regards

Nick

[jg_bds]

We're still trying to figure out this chip, so take this with a grain of salt...

We determined that an unexpected, long string of bus transaction over our "SRAM"-configured SEMC interface was due to data caching.

We executed software that attempted to read a single word from the SEMC, and it resulted in 16 consecutive read bus transactions. Subsequent read attempts to the same SEMC address resulted in NO additional external bus transactions. If we executed additional reads from addresses beyond a prior 'cache line', another 'burst' of transactions happened on the external bus.

When we simply disabled the data cache (which didn't matter for us, because the interface is only used to access registers within an FPGA), the long sequence of transactions disappeared, and multiple reads to the same address all compelled external bus transactions.

-Joe G.

[EdSutter]

Nick,

Unfortunately, I didn't get an explanation.

I didn't pursue it because the address change cleaned it up.  I don't fully understand that; except to say that it is apparently a bit of a clash between the core ARM-M7 stuff and the periphery added by NXP.

Ed

[jeremyzhou]

Hi Ed,

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
Firstly, the SECM module supports to connect with multiple memory devices, however, it doesn't support to access too multiple memory devices simultaneously.
Then, I don't know the memory device access sequence in your demo, but you should avoid access difference memory devices simultaneously, does the code access the FPGA successful when not attempting to access the SDRAM?

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[EdSutter]

Ok another update...

I enable all interrupts in the INTEN register of the SEMC, then in my hard-fault handler I check the INTR register and the AXIBUSERR bit is set.

Looking at that bit definition, it states that one cause for an AXIBUSERR is writing to NOR flash...

That's exactly what I'm doing.

So I guess I have to understand why writing to NOR flash causes this error.  Any pointers would be appreciated.

[jeremyzhou]

Hi Ed,
Thanks for your reply.
I'd like to confirm with you about below inquires.
1) When running the code in the SDRAM, which shares the same SEMC port with the PSRAM and NOR, the code can access the PSRAM and NOR successful except FOR writing to the NOR, isn't right?
2) Does the writing NOR issue still happen when code running the internal RAM instead of the external SDRAM?
3) Does this issue happen when only NOR connecting to the SEMC port?
4) Did you ever try to write the NOR via IP command? If not, please give a try.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[EdSutter]

Hi Jeremy,

1) When running the code in the SDRAM, which shares the same SEMC port with the PSRAM and NOR, the code can access the PSRAM and NOR successful except FOR writing to the NOR, isn't right?

CORRECT

2) Does the writing NOR issue still happen when code running the internal RAM instead of the external SDRAM?

YES

3) Does this issue happen when only NOR connecting to the SEMC port?

YES

4) Did you ever try to write the NOR via IP command? If not, please give a try.

I tried that last night (after realizing that an AXIBUSERR was occurring), and that doesn't cause a hard-fault and I do see the proper chip-select and write line toggle as they should.  I have not confirmed that the data is valid, but my guess is that it will be.

So, I spent almost a week on this...

Where is there documentation on this?  As best I can tell there is nothing that states that writing to SEMC NOR directly is illegal (aside from the AXIBUSERR bit description in INTR).  Section 25.5.5 mentions that a device could be accessed using IP command, but that's about it.  Certainly nothing gave me a hint that direct write of NOR address space would cause a hard-fault exception.

Step further down to section 25.5.8 "NOR Flash Controller Operations" and it appears that this section was just cut-n-pasted from previous sections and never properly updated.  For example, how does Figure 25-51 represent NOR Flash Address Map?  Makes no sense to apply ROW/COL to NOR or PSRAM (section 25.5.9.1) for that matter.  

It would be nice to get those sections of the reference manual updated.

UPDATE (more questions):

What is the purpose of IPCR2 and IPCR1 when using SEMC->NOR?  Since we have to run in 16-bit mode, is IPCR1[DATASZ] set to 2 and IPCR2[BM0-3] set to 1100?

Ed

[jeremyzhou]

Hi Ed,

Thanks for your reply and clarification.
Whether you can share the schematic about connecting the Nor Flash, and share the code of your demo code, also the flash's part num, as it can help me to figure it out.
Regarding the use of the IP command to access flash, please refer to the related API in the fsl_semc.c in the SDK library.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[EdSutter]

Jeremy, 

Thanks for your reply, but the problem has nothing to do with an actual flash device (refer to my initial post at the top of this).  I'm using the NOR interface to pump an FPGA.  I've empirically concluded that the SEMC does not allow direct writes to the SEMC->NOR memory space (hence the AXIBUSERR bit in the INTEN register), and I have to use IPCMD.  That's fine, but it was painful coming to this conclusion.

The fundamental problem is that the reference manual documentation is confusing and limited, and instead of updating the manual with proper guidelines, we're pointed to the SDK, which itself is over-complicated.

I'd really like to see a reference manual for this device that is more complete.  For example, referring to the SEMC chapter's functional description 25.5.8.1 on "NOR Flash address map"... the fields of NORCR0 register mention ROW/COL settings!  That makes no sense for NOR flash, so then the reader has to wonder if any of the timing diagrams are correct as well...

It sure would be nice if NXP could beef up their documentation.

[EdSutter]

Hi,

I have been narrowing down my problem since the original post (one critical point I neglected to mention, this only occurs on a write attempt to the NOR space).  Here are the things I've done to simplify my problem...

1. I rebuilt my application to run out of internal memory, and I've disabled the SDRAM interface (valid bit = 0) in SEMC.  So now I just have PSRAM and NOR active in SEMC.  The hard-fault still occurs.
2. I disabled the PSRAM region in SEMC, and I still get the hard-fault.
3. Finally, I swapped the chip-select used between PSRAM and NOR and STILL get the hard-fault.

So, my problem MUST have something to do with the way I am interfacing to (or configuring) the NOR region.  Note again that I can read from this space, its only writes that cause the hard-fault.

Any additional thoughts would sure be appreciated.  It.s gotta be something simple I'm just overlooking.

UPDATE: this is with reference to an iMXRT1062 design.

Thanks

[EdSutter]

Right now I have SDRAM, NOR and PSRAM regions configured in the SEMC.  I am executing out of SDRAM and I can read and write from the PSRAM space, plus I can read from the NOR space; but when I attempt to write to the NOR space I always take a hard-fault exception.

Certainly, the SDRAM interface works fine (I'm executing out of it), and I know the successful accesses are working because I have the control lines on a scope.  The only interface giving me trouble is writing to NOR.

I've tried executing out of internal memory while accessing NOR/PSRAM, and I get the same result.  What are the limits regarding use of multiple SEMC interfaces?  I've not seen anything in the documentation that indicates that I can't use multiple interfaces in a single design.

UPDATE:

Hopefully its clear that I didn't literally mean "simultaneous" access of multiple SEMC peripherals.  I simply mean that I am executing out of SDRAM while trying to also use the SEMC->NOR and SEMC->PSRAM spaces.