External Memory Byte Access

[MSilv.1]

I have a board with the STM32F407ZGTx, which has space for an SRAM/PSRAM expansion, using IS62WV51216BLL-55TLI. I installed it, everything was fine.

I worked with the old 68000 processor, which had 2 signals, UBS and LBS if I'm not mistaken. Upper Byte and Lower Byte. It was 16 bits too... and I could create a char* variable (C++) in memory, and it would write normally to even and odd addresses (even addresses were d8-d15 and odd addresses were d0-d7). Well, here, on the STM32, it seems that the NBL[0-1] signals are useless. I set byte access (as in the images), configured everything, and it only writes 16 bits.

I made a small test program below, and it doesn't work. It seems that it always writes 16 bits. Could someone help me?

I want to do the basics. A char* variable, write sequentially, and read later in the same way. I thought the FSMC did the same thing as the 68000, since it works with memory.

I even looked and searched on the NET, even in an Article, like the one attached, and the explanation is minimal of how byte mode NBL[0-1] works, that's why I'm asking for help:

Using the high-density STM32F10xxx FSMC peripheral to drive external memories

 

 

 char* xaddress = (char*)0x68000000;

 *(xaddress) = 'H';
 *(xaddress + 1) = 'E';
 *(xaddress + 2) = 'L';
 *(xaddress + 3) = 'O';
 *(xaddress + 4) = '\0';

 printf("%s",xaddress);

 

 

What he is writing on the LCD so you can understand my doubt:

EO

In other words, it seems that the 'H' and 'L' are from d8-d15, he is only bringing what is in d0-d7

[TDK]

Are you monitoring the actual NBL signals themselves or just inferring behavior based on what the program prints out?

 

Do things work correctly if addressed as a uint16_t?

volatile uint16_t* ptr = (volatile uint16_t*)0x68000000;
ptr[0] = 0x0102;
ptr[1] = 0x0304;
if (ptr[0] != 0x0102) {
 // error
 while (1);
}
if (ptr[1] != 0x0304) {
 // error
 while (1);
}

 

[MSilv.1]

Thanks for the reply. No, I don't have an oscilloscope to monitor, and I can't think of another method to monitor these 2 signals. But I checked the soldering, checked if each pin is connected to the STM32F407 pins, and everything is OK.

In the test you sent me, from 0x0102, it returned 0x0100, that is, since this MCU is little endian, the problem must be in D0-D7 and in NBL0. And that makes sense, because it only gives me the E and O of the strings that I put in my test.

I think I already bought the bad SRAM. I don't think it's a problem with the STM32F4....

Thanks for the help, I'll do some more tests, but I think it must be the bad chip.. I was unlucky..

PS: I also have the NE4 which is the LCD, and the warning message I attached appears. But I'm ignoring it, since they share pin resources, and won't be working on the same pins at the same time. What makes me suspicious now is that the LCD only uses D0 - D7, but since it's not selected, its pins are in 3-state. I don't think that's it.

[MSilv.1]

Guys, I've been burning my brain here, and after I posted the last message, I remembered: The TFT LCD may be interfering, it also uses FSMC and NE4. So I removed everything from the project, tested it with a clean board and... voilà, everything worked... The memory is 100%... I tested it all... it's just the TFT LCD...

Now I need to know if it's the driver, or if it's the LCD itself.

[MSilv.1]

The problem, as incredible as it may seem, and in case anyone else has the same problem, was the LCD. I'm using that MCUFRIEND LCD with pins compatible with Arduino. I got some code and adapted it for my project and it worked 100% using FSMC NE4. However, this LCD doesn't have 3-state on the data pins when it has CS = 1. It must be because the touchscreen also uses 4 of its pins for this.

So I put a 74LS245 and everything was solved (Yes, I know it was designed for 5V, but the STM32F407 data pins are designed to be 5V tolerant, and even so, at the output, it doesn't reach that much.