NOR flash test not working on Spectrum 816x/389x EVM

Hello,

We will take a look at this and get back to you as soon as possible.

Regards,
Marc

Hello,

I have a few questions about your setup and suggestions to try:

Can you tell us which revision of Base EVM and IO Daughter Board you have?

Did you look at the NOR memory range to see if the memory is accessible and if it is all 0xFF (which would indicate that it is in the erased state)?

Here are a few things to verify:

On the Main EVM, SW4 needs to be set correctly so that NAND is disabled in order to access NOR.

On the IO Dcard, SW1 needs to be set correctly as described in the PSP User Guide or Flash Tools Wiki.

We tested the NOR Flash on a Rev C EVM board and Rev A of the IO Dcard and it worked fine.

Regards,
Marc

Hi Marc,

After I set the SW1 switch, the test is now working.  Thanks for your help.  We were asked to run the test because on our board, we have a 32K NVRAM, 8 bit, non-multiplex device that we hang on to GPMC at CS1 and we only able to access the first 2K.  Address line A11-A14 doesn't toggle.   The link to this issue in e2e is below.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/143022/518550.aspx#518550

The NOR device on the EVM is 16 bit multiplex device.  Do you think you can try the NOR test on an 8 bit non multiplex device and see if address A11-A14 would toggle?

Do you know if I need to modify the pin Mux in Uboot as well for my device to work?  As of now, I only set the pin mux in Linux.

Thanks,

Tri

Tri,

Here is some feedback on your questions:

We do not have a platform with 8 bit NOR - all we have are the EVM daughtercards so we would not be able to test an 8-bit device.
The first 4 Kb of NOR should be visible [a0-a11], so we are not sure why you would only be able to access the first 2Kb (i.e a0-a10).  Is pin a11 stuck low?

We typically do the NOR pinmux config in u-boot because it is used to boot.  If NOR is not the boot medium than doing the required pin mux in Linux only should be fine if you only need access to the NVRAM from Linux.

Some additional info on the upper address lines:
The upper address pins are not configured by the ROM code, and are left at the power-on defaults. Specifically, external logic is needed to isolate the upper address lines (a12-a27) of the NOR flash from the device pins and drive them low during boot. Once the Initial Software starts running, it can configure the mux setting appropriately for the lines and remove the isolation to allow gpmc to drive all the address lines.

Regards,
Marc

MarcPyne said:

Specifically, external logic is needed to isolate the upper address lines (a12-a27) of the NOR flash from the device pins and drive them low during boot. 

Marc,

Would you please elaborate on the above quote?  Instead of using GPMC_A11-GPMC_A14, I reconfigured these lines as GPIOs and was able to raised them in order to read the upper address in memory, so the lines are not stuck low.

Thanks,

Tri

Tri,

The point is that these pins need to be driven low during boot. Once the Initial Software starts running, it can configure the mux setting appropriately for the lines and remove the isolation to allow gpmc to drive all the address lines.

Regards,
Marc

Marc,

We do not have any isolation logic for these pins.  They are connected directly from CPU to the device's address line.  When the kernel boots, it configure these lines as GPMC address lines.   Our device is a simple RTC device - http://pdfserv.maxim-ic.com/en/ds/DS1744-DS1744P.pdf

We do not access the device until after the kernel configured the GPMC.  Would there be a problem when we don't have the isolation logic and these pins allow to be at whatever CPU has at reset state?

Thanks,

Tri

Hi Marc,

Problem solved.  What needs to be done was setting pull up for all the GPMC address line.

Thanks,

Tri

That was a little premature.   Now the GPMC address lines 11-14 stuck high and won't go low.  It seems the CPU is not driving these lines.  The range of GPMC CS is 16M granularity.  My device only has 4K.   Not sure if there's a wrong setting in a register somewhere or the chip doesn't work with 8 bit non-mux device.

Tri,

Thanks for providing an update on your solution.  We will look at what needs to be added to the TRM.

Thanks,
Marc