- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Hi. I want to perform a test to check if the memory in MSP430FR5969 is working correctly.
I have a simple function that has a local array and two loops. The first loop assigns loop index to each element of the array. The second loop checks if each element of the array is equal to the loop index. I assume the array is allocated in stack section in RAM. When I change the size of the the local array, "Memory Allocation" panel in TI CCS still reports same RAM and stack usage, and reported FRAM and FRAM2 usage doesn't change either. If I change the size of the array to a value as large as the RAM size of the microcontroller, I receive no warning for this from TI CCS but the microcontroller resets every time the RAM test function is called. TI CCS generates an "array is too large" only if I change the size of the local array to a size larger than combined SRAM and FRAM size of the microcontroller. Why doesn't CCS generate this error reliably? What am I missing? How can I make sure that I don't run into allocation problems?
I looked into the linker file of the microcontroller for memory section addresses. In there, RAM origin is 0x1C00 and length is 0x0800. So assumably, first address of the RAM section is 0x1C00 and the last address is 0x23FF. When I debug the function described above, the local array has elements with addresses out of RAM range as expected. But I also noticed that the sections and their addresses are not continous, there are some unused addresses between memory sections. The memory is mapped as below in the table, starting from the lowest memory address to the highest, and I also included the memory map specification section from the linker file. I don't know how to read the linker file, therefore I want to ask if my interpretation is correct or wrong, if there are unmapped ranges in memory. If there are actually unmapped ranges, do they exist in the chip, even though they are not mapped? If they exist, what are they used for?
I also want to perform an instruction integrity check with a checksum algorithm or CRC module. How can I know at which address the instructions reside? Can I use the information in the .map file generated in the project folder? Or would you have a different recommendation?
Thanks.
| Start address | End address | |
| SFR | 0x0000 | 0x000F |
| PERIPHERALS_8BIT | 0x0010 | 0x00FF |
| PERIPHERALS_16BIT | 0x0100 | 0x01FF |
| unmapped range | 0x0200 | 0x17FF |
| INFOD | 0x1800 | 0x187F |
| INFOC | 0x1880 | 0x18FF |
| INFOB | 0x1900 | 0x197F |
| INFOA | 0x1980 | 0x19FF |
| unmapped range | 0x1A00 | 0x1BFF |
| RAM | 0x1C00 | 0x23FF |
| unmapped range | 0x2400 | 0x43FF |
| FRAM | 0x4400 | 0xFF7F |
| signatures and interrupt vectors | 0xFF80 | 0xFFFF |
| FRAM2 | 0x10000 | 0x13FF7 |
Hi Andy,
Those "unmapped" regions will typically not exist at all, the hardware addresses are locations so the CPU knows how to access the non-volatile memory or RAM regions, the addresses be sequential from FRAM to Peripheral Addresses to Interrupt addresses etc. Have large breaks protects against any overflow as well to prevent unexpected "valid" access to a region.
Do you have optimization in your code? That could be a potential cause to why you don't get allocation issues until you actually overflow the total available memory.
To read the linker, you are correct it is the Origin + Length = End Address.
Regards,
Luke
**Attention** This is a public forum
