This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5739 + CC3000 DataLogger Application.

Other Parts Discussed in Thread: MSP430FR5739

I am working with the MSP430FR5739 with the CC3000 DataLogger Application and am confused about the FRAM memory allocation.  In the lnk_msp430fr5739.cmd file, the memory is mapped as:

MEMORY
{
SFR : origin = 0x0000, length = 0x0010
PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
RAM : origin = 0x1C00, length = 0x0400
INFOA : origin = 0x1880, length = 0x0080
INFOB : origin = 0x1800, length = 0x0080
//FRAM : origin = 0xC200, length = 0x3D80
FRAM : origin = 0xC200, length = 0x2800
FRAM_DATA_LOG : origin = 0xEA00, length = 0x0600
FRAM_DATA : origin = 0xF000, length = 0x0EA0
INT00 : origin = 0xFF80, length = 0x0002

Which I understood to mean that the memory reserved for the data logging is from 0xEA00 to 0xEFFF.  However, the code for the datalogger seems to indicate otherwise, in main.c:

// FRAM Data logger Mem Map
#define SHORT_TERM_BUFFER_SIZE 60
#define LONG_TERM_BUFFER_SIZE 1440
// We don't use the linker here to define the
// the data log memory in FRAM but we do use the
// linker to ensure that we reserve enough
// space. The linker section is called "FRAM_DATA_LOG"
// Define the end to be even otherwise byte packing wont align
// CSTACK starts at 0xFE00 so we subtract to just to be safe.
// Each buffer has 2 16-bit headers reserved for the Length and the
// index of the T=0 data
#define LONG_TERM_END_ADD (0xF0A0)
// We find the start address based off the end address
#define LONG_TERM_START_ADD (LONG_TERM_END_ADD - LONG_TERM_BUFFER_SIZE)
// We reserve two more 16-bit values to store the Length and T=0 position
// This information is sent in the WiFi packet as a header
#define LONG_TERM_HEADER_ADD (LONG_TERM_START_ADD - (2*sizeof(short)))

// Now we repeat the definitions for the short term buffer.
#define SHORT_TERM_END_ADD (LONG_TERM_HEADER_ADD)
#define SHORT_TERM_START_ADD (SHORT_TERM_END_ADD - SHORT_TERM_BUFFER_SIZE)
#define SHORT_TERM_HEADER_ADD (SHORT_TERM_START_ADD - (2*sizeof(short)))

// Stores the pointers to the above buffers
#define FRAM_PTR_SHORT_TERM_LOC (SHORT_TERM_HEADER_ADD - sizeof(short))
#define FRAM_PTR_LONG_TERM_LOC (FRAM_PTR_SHORT_TERM_LOC - sizeof(short))

The above code seems to indicate that the end of the buffer falls within FRAM_DATA, and not within FRAM_DATA_LOG.  Am I interpreting this wrong?

Thanks,

Ryan

  • Hi Ryan,

    Yes, your interpretation is correct. Practically it should not be a concern, as we are making use of the available memory. When we try to accommodate the buffer size of 1440, we do end up in the FRAM_DATA section after making way for sufficient gaps.

    You are welcome to make changes here. And a buffer size of 1280 should align you within the boundary.

    Thanks & Regards,

    Raghavendra