I have been stumped on this for a long time. My board is a Nucleo F767ZI, and my LCD is an ILI9341 8080 interface. The AN2790 note gives the following equations for asynchronous SRAM:And the example they give for an SRAM with 100ns write cycle time:These are the 8080 timing constrains from the ILI9341 datasheet:And here are the tsu(Data_NE) and tv(A_NE) ranges given for the F76xx series for asynchronous SRAM:What's really throwing me off is tACC. The ILI9341 only lists data on max read access times, but I'm only concerned with write operations right now. And using the max frame access time gives me serious troubles:Using an HCLK of 72MHz, and setting tv(A_NE) = 0 (If max is 0.5ns then I assumed I could set this to anything lower?):(DATAST + ADDSET + 2)*(13.8ns) = 66ns (min write cycle time for LCD)DATAST*13.8 = 15ns (min low pulse write width for LCD)DATAST = (340ns + 10ns + 13.8ns - 1)/13.8ns - 4 - ADDSET ------> DATAST = 22 - ADDSET ???Please help me understand where I'm messing up? I would appreciate any answers to these questions:are these equations still applicable to the F7 series? I don't see any application notes for my board specificallywhat value would I use for tACC here? 340 ns (frame memory)? 40 ns? Neither? are all three equations supposed to actually be equivalents, or are they limits? For example, are ((DATASET + 1) + (ADDSET + 1))*tHCLK actually supposed to be as close as possible to 66ns, or do they just need to be at least 66 ns? Same question especially for equation 3, which is screwing me up the most because of the very high access time.

Associate III

Solved

Please help me out with my FMC timing computations?

Forum|Forum|6 years ago
May 19, 2020
3 replies
3900 views

I have been stumped on this for a long time. My board is a Nucleo F767ZI, and my LCD is an ILI9341 8080 interface. The AN2790 note gives the following equations for asynchronous SRAM:

And the example they give for an SRAM with 100ns write cycle time:

These are the 8080 timing constrains from the ILI9341 datasheet:

And here are the tsu(Data_NE) and tv(A_NE) ranges given for the F76xx series for asynchronous SRAM:

What's really throwing me off is tACC. The ILI9341 only lists data on max read access times, but I'm only concerned with write operations right now. And using the max frame access time gives me serious troubles:

Using an HCLK of 72MHz, and setting tv(A_NE) = 0 (If max is 0.5ns then I assumed I could set this to anything lower?):

(DATAST + ADDSET + 2)*(13.8ns) = 66ns (min write cycle time for LCD)
DATAST*13.8 = 15ns (min low pulse write width for LCD)
DATAST = (340ns + 10ns + 13.8ns - 1)/13.8ns - 4 - ADDSET ------> DATAST = 22 - ADDSET ???

Please help me understand where I'm messing up? I would appreciate any answers to these questions:

are these equations still applicable to the F7 series? I don't see any application notes for my board specifically
what value would I use for tACC here? 340 ns (frame memory)? 40 ns? Neither?
are all three equations supposed to actually be equivalents, or are they limits? For example, are ((DATASET + 1) + (ADDSET + 1))*tHCLK actually supposed to be as close as possible to 66ns, or do they just need to be at least 66 ns? Same question especially for equation 3, which is screwing me up the most because of the very high access time.

This topic has been closed for replies.

Best answer by NNagy.1

I at least was able to solve the noise and missing writes in my code!

I used this thread's suggestion: https://community.st.com/s/question/0D50X00009XkWQESA3/stm32h743ii-fmc-8080-lcd-spurious-writes

In my library the call was

HAL_EnableFMCMemorySwapping();

which I added to the end of HAL_FMC_Init(). And then I changed my command and data funcs to:

//1. Write Command to LCD
void ILI9341_SendCommand(uint8_t com)
{
	*(__IO uint8_t *)(0xC0000000) = com;
}
 
//2. Write data to LCD
void ILI9341_SendData(uint8_t data)
{
	*(__IO uint8_t *)(0xC0040000) = data;
}

Here's my new waveform when I call sendData(1); sendData(2); sendData(1); Hal_Delay(1);

(D0 is orange, D1 is yellow, NWE is blue, NE1 is green).

It still gets a little noise between the delays (not pictured), but not during the write signals, which is all I am concerned about.

I still haven't found the perfect configs to match the 3 equations, but the error might have been due to the missing data/writes the whole time.

waclawek.jan

Super User

The best thing you can do is hook up a logic analyzer and experiment, observing impact of individual setting field, and match it to the LCD controller's waveforms.

JW

NNagy.1Author

Associate III

So I tried this out and it brought up a new question.

First of all, the ADDSET and DATAST seem to work correctly (purple = SYSCLK = HCLK = 24MHz, green = NE1, blue = NWE, orange = D0, and I have ADDSET=7, DATAST=2).

However, this was the code I was running:

while (1) {
 *(__IO uint8_t *)(0x60040000) = 0;
 *(__IO uint8_t *)(0x60040000) = 1;
 HAL_Delay(10);
}

And here is a wider view of the results:

The write signal only goes low once between every delay -- and I don't know what's going on with the D0 signal at the end. This is consistent across every iteration of the while loop, as far as I can tell.

So a question this brings up for me: I have my AHB prescaler set to 1 (ie, HCLK == SYSCLK). Is the program instructions / instruction pointer running off of the SYSCLK? Is the fact that I'm only seeing one write signal triggered a consequence that the FMC is running at the same speed, but that overall the write cycle is 7 or 8 SYSCLK cycles? Can the FMC not run at the same rate as SYSCLK?

Or, if that's not the source of the issue I am seeing, would you know what would be?

NNagy.1Author

Associate III

So I tried testing by setting the HCLK much lower than the SYSCLK but had essentially the same result. I also realized that my ADDSET and DATAST in the example above violated equation 3, but after changing ADDSET to 1 and DATAST to 5 I am still seeing the same issues.

The first two equations are intuitive to me. It makes sense that ADDSET and DATAST need to span the write cycle, and as you increase the frequency of the HCLK (and decrease its period), the more HCLK cycles you'll need to hold ADDSET and DATAST for to match the cycle time. And therefore I understand that the actual equation is

(ADDSET + DATAST + 2)*tHCLK >= tCYC

Instead of "equal to". However, I still have yet to fully understand equation 3 with the same intuition.

NNagy.1AuthorBest answer

Associate III

I at least was able to solve the noise and missing writes in my code!

I used this thread's suggestion: https://community.st.com/s/question/0D50X00009XkWQESA3/stm32h743ii-fmc-8080-lcd-spurious-writes

In my library the call was

HAL_EnableFMCMemorySwapping();

which I added to the end of HAL_FMC_Init(). And then I changed my command and data funcs to:

//1. Write Command to LCD
void ILI9341_SendCommand(uint8_t com)
{
	*(__IO uint8_t *)(0xC0000000) = com;
}
 
//2. Write data to LCD
void ILI9341_SendData(uint8_t data)
{
	*(__IO uint8_t *)(0xC0040000) = data;
}

Here's my new waveform when I call sendData(1); sendData(2); sendData(1); Hal_Delay(1);

(D0 is orange, D1 is yellow, NWE is blue, NE1 is green).

It still gets a little noise between the delays (not pictured), but not during the write signals, which is all I am concerned about.

I still haven't found the perfect configs to match the 3 equations, but the error might have been due to the missing data/writes the whole time.

waclawek.jan

Super User

> It still gets a little noise

Data go threestate (floating), generally they tend to float towards zero (there's some leakage that way) so what you see as digital noise is the effect of your LA input being driven at around its decision level.

In 'F7 you see the caching effects until you do what you did in the last step, which is effectively setting the FMC as Device.

I don't intend to delve deep into what those formulas might mean, if you achieve the required waveforms with both single writes and sustained writes (also to alternating addresses, as you'll probably need that) you should be good. to go.

There are minor differences in the FMC/FSMC incarnations in various STM32 models, quite poorly documented, which sometimes do make a difference in the behaviour at a particular combination of events (e.g. when alternatively accessing different banks, which is probably not your case).

https://community.st.com/s/question/0D50X0000C23GN6SQM/f427-fmc-vs-f407-fsmc-different-behaviour-for-backtoback-writes-to-the-same-sram-bank

JW

NNagy.1Author

Associate III

I just re-uploaded with the changes in my most recent comment with the LCD board hooked back up in place of the LA, and the interface is successfully running now!

Thank you for your help!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded