MSP430 Ram Overflow

0
votes

The MSP430G2553 only has 512 Bytes of RAM but 16KB of FLASH memory. On this microcontroller, all static/global variables are assigned in RAM under .bss section. All local variables are assigned in RAM under .stack section. All dynamically allocated memory variables (malloc) are assigned in RAM under .sysmem section.

I have a need for this MSP430 to keep track of connected devices via wifi. I have a struct as such:

struct dev
{
    char type[20];
    char ipAddress[13];
    char name[20];
    char status[1];
};

This struct takes up 54 bytes of memory for each device. I am planning on having 20+ devices connected that this MSP430 and need to have 20 of these structs. 20 x 54 bytes = 1080 bytes. This is obviously too big for the 512 bytes of ram.

Is there any way to write these structs into FLASH since I have 16KB of memory to use? My understanding of FLASH is variables that are only read-only. These structs will obviously be getting assigned so it is read-write and I am not sure if it is possible.

I don't quite understand why TI would make a device which has 16 KB FLASH and only 512 Bytes of RAM, when all variables requiring read-write operations are stored in RAM. Seems like it is a waste of space.

I have tried to change these sections .bss/.stack/.sysmem to FLASH in the linker file and the MSP430 will not run like this. I have also tried to change the size of the RAM and in linker file and change the memory locations adding another 512 Bytes, but it will not run like this either.

Do I have any options here?

4
cflashmemorystructmsp430
Encode everything, you don't have to save everything as strings, except the name. - user3528438
Why do you need 20 bytes to define the type? The char type can reference 256 different types, which can be detailed in ROM (or FLASH code), but you should place the field next to the status field, or pack the struct. Anyway what is the point of char status[1]? - Weather Vane
@Olaf the same person who uses char status[1]; - Weather Vane
@WeatherVane: Fair enough :-}. PC programmers gone bare-metal. - too honest for this site
... or who does not figure out his system requirements ahead of specifying the chip. - Weather Vane

4 Answers

2
votes

Yes, you can write data into the flash memory. The only problem arises when you want to change the data. You can only erase sectors, which have a size of 512 bytes. So you could take two flash sectors from the flash and store data for 10 devices in each sector. The flash can be read like RAM though, so you don't need some kind of swapping code, you just address each device entry with a pointer. The last problem is that flash memory has a limit of erase cycles, here around 10000 cycles. So you might also have to write code to distribute the data to different sectors over time, depending on the amount of expected changes and the desired service durability.

2
votes

You can store a constant data in the flash/program memory. If you know that some variables/arrays are actually not changing once initialized, you can declare them as static const in your code and the compiler will place them in the .text section, which is usually going to the FLASH memory. If you have dynamic data that doesn't fit in the memory.. well. You are screwed, unless you can think of optimization (like reusing the same space for different things at different times..). Of course there is a possibility to implement some kind of "swapping" functionality with FLASH, if your part has a programmatic access to the FLASH writing. But it is really not that simple.

And for this:

I don't quite understand why TI would make a device which has 16 KB FLASH and only 512 Bytes of RAM, when all variables requiring read-write operations are stored in RAM. Seems like it is a waste of space.

You are getting what you are paying for. Every micro has a specific range of applications it is intended for. If this specific micro is not good for your application, probably it is not in that range.

1
votes

There's a good bit of extra room you can free up in this struct.

Type type field probably doesn't need to be a char array. You can use a set of symbolic constants with all the possible types.

The IP address also doesn't need to be stored as a string. Assuming IPv4, you only need four bytes.

status doesn't need to be an array of size 1. A simple char will suffice.

So now you have something like this:

struct dev
{
    uint32_t ipAddress;   // 4 bytes
    char name[20];        // 20 bytes
    char type;            // 1 byte
    char status;          // 1 byte
};                        // 2 bytes padding, total = 28 bytes

It's still not quite enough to fit 20 of these into 512 bytes of memory, but it's better that what you had.

0
votes

Honestly, your best option is probably to switch to a more capable chipset. The MSP430 G-line is really meant for extremely low power and low performance applications, Ethernet being neither of those (and certainly not multiple TCP/IP connections at the same time!).

As for why they'd make a chip with a huge Flash space and tiny SRAM, well, Flash is cheap and compact, where SRAM is space-expensive on the die, so TI had to make compromises to deliver that MCU for less than $1. As some of the other answers alluded to, you can use that large amount of Flash to write more code, that can encode/compress/decode/decompress data to/from SRAM.

Another option is to use one of the "Wolverine" series of MSP430 chips. Those use a unified FRAM bank rather than separate Flash and SRAM banks.