MSP430 FR5969 - Increasing Frame Buffer for Larger Sharp Memory LCD Displays

Ryan Brown2

Other Parts Discussed in Thread: MSP-EXP430FR5969, MSP430WARE, MSP430FR5969, MSP430G2553

I received my FR5969 demo board with Sharp LCD yesterday!

Its amazing how long the processor and display can run the clock app off just the capacitor. Its been showing time for 17 hours straight now.

I loaded the MSP-EXP430FR5969 with Graphics Library from MSP430ware in Code Composer Studio.

I then found the HAL_MSP-EXP430FR5969_Sharp96x96.h file and changed the Pixel x Pixel data to 128 x 128 pixels. Next I'll try the 400 x 240 pixels for the 2.7 inch screen.

Looks like they are using a frame buffer in the demo code above.

So the they are using Frame Buffer for in the example code in MSP430ware which should also allow me to use the 400x240 pixel Sharp Memory Display but when I try to use 400 horizontal x 240 vertical pixels and then built it I get over size errors like this:

error #10324-D: BOUND section ".TI.bound:DisplayBuffer" spans the boundary of an existing memory range FRAM

>> Compilation failure

error #10099-D: program will not fit into available memory. run placement with alignment fails for section ".TI.bound:DisplayBuffer" size 0x3520

error #10010: errors encountered during linking; "MSP-EXP430FR5969_Grlib_Example.out" not built

gmake: *** [MSP-EXP430FR5969_Grlib_Example.out] Error 1

gmake: Target `all' not remade because of errors.

**** Build Finished ****

So I'm sure something needs to be changed in the display buffer size setting to get it working.

I think something needs to be changed in the code below to work with the 400 x 240 pixel size possibly. Take a look.

//*****************************************************************************

// IMPORTANT NOTE: The following driver file supports using either RAM or

// non-volatile memory(Flash or FRAM) to store the LCD DisplayBuffer.

//*****************************************************************************

// Sharp96x96.c

//*****************************************************************************

//! \addtogroup display_api

//! @{

//*****************************************************************************

#include "grlib.h"

#include "Sharp96x96.h"

#include <msp430.h>

#ifdef __MSP430FR5969

#include "HAL_MSP-EXP430FR5969_Sharp96x96.h"

#include "driverlib.h"

#elif defined(__MSP430G2553)

#include "HAL_MSP-EXP430G2_Sharp96x96.h"

#endif

#include <stdint.h>

static void Sharp96x96_InitializeDisplayBuffer(void *pvDisplayData, uint8_t ucValue);

//*****************************************************************************

// If flash is used as non-volatile memory, the DisplayBuffer will have 32 extra

// vertical lines to create a buffer size which is a multiple of 512 Byte

// (this is the default size of flash memory segments in MSP430 device). It is

// required that the display buffer is a multiple of 512 Bytes to be able to

// initialize the buffer using the FLASH segment erase feature of the FLASH

// controller.

//*****************************************************************************

#ifdef NON_VOLATILE_MEMORY_BUFFER

#pragma location=NON_VOLATILE_MEMORY_ADDRESS

#endif

#ifndef NON_VOLATILE_MEMORY_BUFFER

uint8_t DisplayBuffer[LCD_VERTICAL_MAX][LCD_HORIZONTAL_MAX/8];

#else

#ifdef __ICC430__

__no_init uint8_t DisplayBuffer[LCD_VERTICAL_MAX +32][LCD_HORIZONTAL_MAX/8];

#else

uint8_t DisplayBuffer[LCD_VERTICAL_MAX +32][LCD_HORIZONTAL_MAX/8];

#endif //__ICC430__

#endif //NON_VOLATILE_MEMORY_BUFFER

uint8_t VCOMbit= 0x40;

uint8_t flagSendToggleVCOMCommand = 0;

****************************************************************************************************************************************

Any ideas?

over 12 years ago

0 Michael_M over 12 years ago

Intellectual 740 points

I'm planning to order myself one of those boards, too. Maybe I'll have a look at the complete source code later.

The buffer is too large to fit into the normal SRAM, so you have to go with the FRAM. Judging by the requested size this is already done, as NON_VOLATILE_MEMORY_BUFFER is set, otherwise you wouldn't get a buffer size of 0x3520 = 13600 = 400*(240+32)/8. Your problem has to be the placement in your FRAM itself. Normally you can force it by adding #pragma location=<address> (some value less than 0x10000 so the whole buffer fits in) right before declaring your display buffer, but maybe it would be a better idea to check the map in your .cmd file. So far I've got no experience with FRAM. As I said, you should check the current allocation anyway to get an idea regarding the start address.

0 Jens-Michael Gross over 12 years ago

Guru 227245 points

The 96x96 pixel frame buffer required 1152 bytes. 128x128 pixels are 2k. I’d expect problems here already, as this will use all of this MSP’s 2k sram and leave no space for stack and other variables.

However, the buffer is likely put into FRAM instead. Now 400x240 requires almost 12k of memory. (0x2ee0). It is possible that the part of FRAM that is set aside for variables (and the buffer, as it is treated like a variable too) is only 8k. In this case, the distribution of FRAM for code and data has to be change in the linker script.

Unfortunately, the linker does not support dynamically splitting FRAM for code and data usage. It is a fixed split and the memory protection unit is programmed according to this split.

I don’t have any further details, but a closer look at the linker command file will tell you the default configuration.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430 FR5969 - Increasing Frame Buffer for Larger Sharp Memory LCD Displays