Adding external SRAM to STM32

Hi!

I'm currently working on a project involving an STM32H743BI microcontroller. I've decided that I should add an external SRAM chip so I can try out some interesting things. I want some advices about the pinout of the SRAM chip (or you can even recommend better value chips)

The SRAM IC

In the datasheet I don't see any numbering on the data and address pins (except A0 and A1). Does this mean that I can connect whatever I want, wherever I want?

All the pins labeled “A” are address pins. Actual numbering is irrelevant.
This is probably NOT the sort of SRAM that you want to connect to a microcontroller.

westfw:
This is probably NOT the sort of SRAM that you want to connect to a microcontroller.

What should I look for instead then? I was thinking about plain old SDRAM but I could not find any information about the handling of ECC. I needed something that has a minimal chance of bit flip while being relatively fast, that's why I looked for an SRAM chip with a parallel interface and this was the best I could find.

Perhaps you can elaborate on your "interesting things"?

You mentioned that you wanted something relatively fast and a parallel interface.

If you could indicate how much SRAM you think you would need and how fast you need to access it, then maybe there are alternative solutions out there .....

markd833:
Perhaps you can elaborate on your "interesting things"?

You mentioned that you wanted something relatively fast and a parallel interface.

Not so long ago, I tried out Node-Red and I loved the way i could make programs quite fast and intuitively. I'm working with other students in the university to make something similar for microcontrollers (not quite an IDE, just a visual code organization software for easier event based programming) but all the IPs we are planning to use (TCP/IP, mDNS, custom serial communication protocols, FATfs, etc...) are expected to exceed the 1MB of the MCU's internal SRAM. So we figured out that as big part of the communications handling just comes down to moving data around and we can handle is quite effectively with DMA and a basic task scheduler. In the future, we can probably live without the SRAM but first we just want to make things happen and we rather spend a bit more on hardware than spend time optimizing the code before making it work. (And if it works, then we optimize it)
We need at least 2MB of 32bit RAM, mainly to store relatively large chunks of data.

Have you already had a look at FORTH?

DrDiettrich:
Have you already had a look at FORTH?

I looked at it, it's nat really what I have in mind. My focus is not really on the programming language, but rather a visual tool that gives an overview for event based C/C++ applications.
But my focus is not on the event based part but rather the high ram usage that will be caused by the TCP/IP stack, the mDNS and our own libraries, not to mention the influx of sensor data. I'm just looking for a suitable SRAM chip :smiley:

I don’t see any numbering on the data and address pins (except A0 and A1). Does this mean that I can connect whatever I want, wherever I want?

The chip might be OK, after all. I’m not sure how “Sync Burst” plays into anything. I was expecting the ST chip to have interfaces for particular types of memory (it does, but one of them looks like a straight parallel static RAM. So that’s OK, as long as you don’t mind giving up the 45-odd pins and figuring out the PCB.)
Yes, you can connect whichever address and data lines you want, as convenient for your PCB. That’s actually always been true for SRAM - it’s interesting to see a datasheet that acknowledges it!

Are you sure you wouldn’t rather use a microprocessor setup that already has lots of RAM (x86 SBC, Beagle board, Raspberry Pi, etc.)?

westfw:
The chip might be OK, after all. I'm not sure how "Sync Burst" plays into anything. I was expecting the ST chip to have interfaces for particular types of memory (it does, but one of them looks like a straight parallel static RAM. So that's OK, as long as you don't mind giving up the 45-odd pins and figuring out the PCB.)
Yes, you can connect whichever address and data lines you want, as convenient for your PCB. That's actually always been true for SRAM - it's interesting to see a datasheet that acknowledges it!

It's good to know it. Although i found SRAM a bit expensive, so I think I'm going for some higher capacity SDRAM. It would be nice to have ECC or something like that but I can keep all critical data in the internal memory. By the way, is it possible to mix the data pins on an SDRAM chip? Considering I don't use the byte enable pins separately, can I mix data lines from different byte groups?

westfw:
Are you sure you wouldn't rather use a microprocessor setup that already has lots of RAM (x86 SBC, Beagle board, Raspberry Pi, etc.)?

I want this stuff to install in my house and run for years as intended. No internet connection, no wireless (except for maybe some tricky Bluetooth or NFC implementations in the future), just stable and constant operation. The external ram needs to be here for a few reasons:

  1. I want to actually design some more advanced piece of hardware as I have a lot of knowledge, but no experience
  2. I'd like to try running some non-essential but cool algorithms (something like lightweight machine learning) which may need more significant amount of memory.
    The reasons for not choosing some SBC is because hobby level ones just aren't reliable enough for me and don't have many interfacing options like multiple RS485, SPI, I2C ports. I am still thinking about making a prototype around a raspberry pi. I might just give up on the MCU based design but I need to find a reliable mini PC with reasonable pricing.

RAM risks to loose contents with every power fail.

DrDiettrich:
RAM risks to loose contents with every power fail.

I know, a QSPI flash would be provided as non-volatile storage. And to further improve reliability, the module would contain a built in uninterrupted power supply.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.