Hi Everyone,
I've connected a 64Mbit NOR flash to the EMIF (using CS0), this device needs to be programmed before any data can be written to its addresses, looking at the data sheet and TMR the EMIF should be able to handle this via the use of specially written functions.
However I need to be sure the TMS570 will not try and access this address range in any of its background routines (or as a result of array generation from my code) as data can not be stored at these addresses with out preparing the NOR flash.
Can you confirm that the TMS570 will not try and do this or alternatively indicate how the TMS570 can be set up to have this address range protected or access restricted?
Thanks in advance
Alex
Alex,
You are right for the address. Are you using 16 bit or 8 bit mode? This EMIf supports 16 bit mode.
Thanks and regards,
Zhaohong
Hi,
Yes I am using 16bit mode.
Hi Zhaohong,
This current situation does not make any sense, I've retested the the output from the TMS570 and can reconfirm the following:
Firstly, when a write is tried at 0x60000AAA, the NOR pins A[0:21] observe 0x00555.
Secondly, when a write is tried at 0x554, the NOR pins A[0:21] observe 0x002AB.
Now, this brings a few questions to mind:
If the NOR's A0 is meant to be connected to EMIF BA1, then why does the first write show the address 0x000555? If the TMS570 was outputting on the pins EMIF BA1 and EMIF A[0:20], then the address observed by the NOR would be 0x0002AA.
This goes for the second write too, the NOR should observe 0x000155, rather than the 0x0002AB that it currently observes.
In addition it looks like the pin A0 is constantly pulled high, this is at all the addresses I've tried, I've checked and made sure it is not shorted to 3V3 or any of the other possible connections as well as making sure it is connected to the EMIF A0 pin. I've also tested the address seen by the NOR chip when the TMS570 writes to 0x60000000, the output is 0x000001.
Why would the TMS570 be keeping EMIF A0 high?
Regards,
If you can send your complete norflash test, I can re-run the test as is on a board with external async SRAM. I can check check the contents in RAM at locations you tried to write.
Zhaoohong
Here is my up-to-date project files.
0702.EB-EMIF-TI.zip
Cheers,
While experimenting with the code I have found scenarios where A0 is in the logic low state, but this only occurs when there is a malfunction with the EMIF, where it constantly outputs 0x00016A no matter what TMS570 address I write too.
Would you please reorganize the project? There is one include path "D:\PhD\TI\Global Inculde" missing.
Sure, this is much appreciated, the missing files are the files I borrowed from your example.
Here is the self contained project.
3554.EB-EMIF-TI.zip
Kind regards,
It seems that there is something wrong with your software. It does not write into external memory in my test board. I need to debug at assembly level. I hope to find more details next week.
I had a look at my code and yes there was something wrong with it, I've now corrected it, the project I'm now attaching shows the behaviour described in the previous posts. I've tested the NOR but starting the address at 0x60000000 (0x000000) and incrementing it from there. It shows that the BA1 pin is being toggled, or at least I assume so, the NOR does not observe a pin change until the address 0x60000004.
In one instance of testing the NOR flash (from a "Restart" in CCS) the address A0 became active (i.e as per the address accessed the pin showed either a 0 or 1), however after another "Restart" (with no change in code, break points or any other feature) the address became unresponsive once more and has remained so despite many "Restarts" since.
4774.EB-EMIF-TI.zip
"Restart" only sets PC to the location of "c_int00". To make the code execution repeatable, you need to have a clean start every time. I would suggest you always do an "advanced system reset" followed by a "CPU" reset. If your code is already programmed into Flash, you do not need to load it any more.
Ok, I will use that procedure from now on.
To look closer at the function of the EMIF I've used the following project where I've either run NOR_READ or NOR_WRITE independently.
8400.EB-EMIF-TI (NOR_WR).zip
To add to the picture here are some shots of the oscilloscope. The following image is for NOR_WRITE, where Blue = CE, Green = WE, Red = A0 and Yellow = A1, all signals have been moved on the voltage scale to allow for easier viewing and reducing the risk of one signal masking the other (eg CE and WE), while the noise on the yellow line is due to the probe.
I've also tested with Green = OE, just to see if anything was happening.
The following image is for NOR_READ, where Blue = CE, Green = OE, Red = A0 and Yellow = A1
Again I checked WE, Green = WE:
In all, the pins WE and OE are not functional (though I'm sure that at on point in this project they were). For NOR_READ the CE is operating as expected, 2 cycles per A0 cycle. While for the NOR_WRITE there is no logical reason for the asymmetrical behaviour of the CE pin, especially as the code is identical to NOR_READ.
I have tried the software you sent in the early morning. It can write to the external memory in my test board correctly. I wonder if there is a connection problem on WE between TMS570 and Norflash on your board. EMIF OE is a input signal. Norflash drives it to indicate data readiness during read operation. You should not see OE toggling during write operation.
Yes, the OE should not toggle during write operations or vise versa, but as the TMS570 is not operating as expected I'm prepared to explore every avenue.
On the NOR flash the OE pin is an input. The TMS570 datasheet shows the OE pin as an I/O how can I turn it into an output and use it as one?
The WE connection has been tested as far as possible, with it confirmed form NOR pin to the fanout VIA before connection to the ball within the FBGA, the reflowed FBGA/PCB has also been x-rayed and there is no sign of any abnormality at that connection or those around it (which all function correctly). The connection has also been confirmed pad to pad on non-populated boards.
Well there has been progress. There's no reason for the progress (no change in settings), so I wont be surprised if it does not work when I boot it up tomorrow. However I'm going to live in hope.
Out of curiosity I downloaded and tried to run the project I posted this morning, it now works, without any changes. In case it helps, to load a project I set it as "Active Project" then right click once more and select "Debug As" then "Debug Session". Is the TMS570/ XDS100v2 @ 1MHZ a possible cause of the erratic TMS570 behaviour?
Anyway there are still issues with the signalling so here is the new project:
2642.EB-EMIF-TI - 21.zip
Here is an image of the signals for writing to the addresses 0x60001554, 0x60000AA8 and 0x60001554 (these are the program addresses (555,2AA and 555))
and the first read at 0x60000000
where Blue = CE, Red = A0, Green = WE and Yellow = OE
As you can see OE is perfect while WE is triggered 3 times per CE cycle with the last one occurring after A0 has changed, also 555 and 2AA are identical despite A0 should be 1 for 555 and 0 for 2AA. Why is A0 changing mid write?