How to program an 16-bit NOR Flash in 25-bit addressing (CS0) - LS1021A silicon rev. 2.0

[dparol]

Hi everyone,

this question relates to other one solved already several months ago by us with use of LS1021A silicon rev 1.x:

How to program an 16-bit NOR Flash in 25-bit addressing (CS0)

As we moved with our design and put LS1021A rev. 2.0 to our custom board, we have noticed changes in processor behavior. The 25-bit IFC mode for CS0 seems not working anymore.

This is our setup:

1. We use custom board with LS1021A silicon rev 2.0

2. We use BDI3000 for initial board bring-up

3. Using BDI tool we are able to provide hard-coded RCW to the processor and make it coming out of reset, that is we are able to get to BDI CLI and read processor registers, we can even access DDR after configuring it in BDI configuration file.

4. But we are not able to communicate with NOR flash in 25-bit IFC mode (the BDI configuration is correct and same as for previous design) - the measurements made with use of scope show, that access on the IFC bus is forced by the processor somehow to be 28-bit

5. how we initially program NOR:

     a. We are overwriting hard-coded RCW via JTag

     b. We are providing appropriate RCW source externally by CPLD (25-bit IFC mode, 16-bit nor flash etc.)

     c. We are configuring IFC CS0 in BDI configuration file for correct CS addressing and timings

     d. This setup works well with earlier processor revision and we can easily program NOR flash with RCW, bootloader etc. but this does not work with latest processor rev 2.0

Any response would be appreciated much.

Regards,

Damian

[r8070z]

Have a great day,

Some hardware issues were fixed on the rev 2.0. I have checked available LS1021A documentation including the erratum and could not see that LS1021A silicon  rev. 2.0 has problem with NOR flash or IFC_A[25:27] muxing. Because some documentation is not public it is better to discuss that in the service request. Please see How I could create a Service Request?

I was confused by sequence a. b. c. in the item 5. It is not clear are a. and b. alternative or sequence. What for has been configured IFC CS0. Please in the service request describe CPLD and NOR flash connections to the LS1021A, provide the RCW values you used and how you ensured that IFC is in 28-bit address mode. Check please if there is any other difference besides silicon revisions.

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

[dparol]

Hi Serguei,

thank you for your answer.

Regarding your a+b confusion - my understanding was, that external RCW source (strapping pins) can overwrite any respective setting form the RCW itself (512 bytes of configuration data). Speaking of IFC mode, if you set different IFC mode in RCW, and different in RCW source, the one for RCW source matters. So I was assuming, that providing the hard-coded RCW to the core, you can still overwrite some of the respective options by means of external RCW source (like already mentioned IFC mode). The hard-coded RCW consists of many default values - mostly zeros. In our previous setup it clearly looked like the IFC mode could be overwritten by providing the correct RCW source signals externally (setting for 25b addressing scheme for CS0). It works and we have already running system with this setup.

Answering your another question - the CS0 has been configured for accessing it by the BDI by means of core access. For programming we are using internal processor cache as a buffer and the core has to be also aware of the external interface in order to access it. It's different approach than simple bit-banging on the boundary register.... much faster.

In 25b IFC mode the A23 bit should be changing its state when accessing every ...000, ...002, ...004 etc. (HEX) addresses. At the moment we can see that it changes its state first time at ...010 etc. (HEX) address. That clearly indicates the IFC is in 28b mode, even if external RCW source points to 25b, and correct hard-coded RCW has been loaded (the core is out of reset). Exact setup with rev1.0 works as expected.

What's confusing to me is, that there is clearly a difference in the processor behavior when transition from rev1.0 to rev2.0, but nothing of above is mentioned in the silicon errata. We went for rev2.0 especially because some of significant bugs were meant to be solved there, but no one was expecting additional changes in completely different area.

We already contacted our FAE and waiting for confirmation. We will try to program the NOR flash with the ordinary (boundary scan flash programmer) way and then try to access the core via our tools for initial bring-up and further debugging.

Best regards,

Damian