MSP430F6779A: MSPBoot multiple image using large code model

Hi Jorge,

An update is planned for the original MSPBoot resources but work has not yet started on it due to other priorities. Therefore no release date has been set or should be expected for the near future. This update will also most likely only support the CCS IDE. You might want to consider using a custom BSL (SLAA450) since you are using a flash-based BSL device: www.ti.com/.../slaa450d.pdf

If continuing down this path my suggestion is that you combine the flash code from MSPBoot and large-memory model support from MSP430FRBoot to create your own main memory large memory model bootloader. Your memory organization appears to be correct so far.

Regards,
Ryan

Hi Ryan.

I have to continue down this path. Thanks for your inputs.

Are the assumptions I made regarding the vector redirect to RAM correct or did I miss something?

Regards,
Jorge

My apologies for not addressing that question, as stated in Section 2.2.3/4 of the MSPBoot application report you can redirect vectors to RAM in hardware (SYSRIVECT). This can be done in place of the proxy table.

Regards,
Ryan

Hi Ryan.

I've made some progress but I still need your help with some issues.

I decided to start developing using just a dual app approach.

	Start	End	Size	512 B sectors
App area	0x0C000	0x0EFFF	0x3000	24
Boot area	0x0F000	0x0FFFF	0x1000	8
Download area	0x10000	0x12FFF	0x3000	24
		Total	0x7000	56

Vector redirection to RAM is working great.

To achieve this I changed the application linker file to place the interrupt vectors at a fixed location (0xEF80 - 0xEFFF) just below my bootloader.

	Start	End	Size
App reset	0x0EFFE	0x0EFFF	0x00002
App interrupt vector	0x0EF80	0x0EFFD	0x0007E
		Total	0x00080

And on bootloader and application linker I reserved the top of RAM. 

//////////////////////// RAM ADDRESSES ///////////////////////////////
//
// Start address of Available RAM
-D_AVAILABLE_RAM_START=_RAM_START
// Address of Reserved Space for RAM Int Vectors - 64 vectors
-D_RAM_RESERVED=80
// End address of Available RAM
-D_AVAILABLE_RAM_END=(_RAM_END-_RAM_RESERVED)
// Start of Reserved RAM
-D_RAM_RESERVED_START=(_AVAILABLE_RAM_END+1)
////////////////////////////////////////////////////////////////////////////////

// -----------------------------------------------
// Read/write memory
//
-Z(DATA)DATA16_I,DATA16_Z,DATA16_N,TLS16_I=_AVAILABLE_RAM_START-_AVAILABLE_RAM_END
-Z(DATA)DATA16_HEAP+_DATA16_HEAP_SIZE
-Z(DATA)CODE_I
-Z(DATA)DATA20_I,DATA20_Z,DATA20_N
-Z(DATA)CSTACK+_STACK_SIZE#

At application start I copy the vectors to the reserved RAM and set SYSRIVECT.

extern uint16_t _App_Vectors_Start;
extern uint16_t _App_End;
extern uint16_t _RAM_RESERVED_START;

memcpy((void*)(&_RAM_RESERVED_START),(const void*)(&_App_Vectors_Start), (((uint16_t)&_App_End)-((uint16_t)&_App_Vectors_Start) + 1));
SYSCTL |= SYSRIVECT;

I tested using a small app that uses a timer interrupt to toggle a led. This is working great.

First tests with the bootloader were with app and download areas below 64kB, this worked ok. I started with a dual image example from MSPBoot for IAR. But because I need to use space over 64kB I started changing code based on MSPFRBoot.

I have a couple of problems:

• In TI_MSPBoot_MI.h

When I use: 

extern uint32_t _AppChecksumDown;           /*! Download Checksum Address */
extern uint32_t _App_EndDown;               /*! Download End Address */

/*! Download area start address (from linker file) */
#define DOWN_START_ADDR          ((uint32_t)&_AppChecksumDown)
/*! Download area end address (from linker file) */
#define DOWN_END_ADDR            ((uint32_t)&_App_EndDown)

For DOWN_START_ADDR I get 0x0 instead of 0x10000 and for DOWN_END_ADDR I get 0x2FFF instead of 0x12FFF, somehow the address is being truncated, because during debug I can see that the _AppChecksumDown and _App_EndDown are correct.

If i use: 

/*! Download area start address (from linker file) */
#define DOWN_START_ADDR          (0x10000+(uint32_t)&_AppChecksumDown)
/*! Download area end address (from linker file) */
#define DOWN_END_ADDR            (0x10000+(uint32_t)&_App_EndDown)

I get the correct address.

Is there any error on my part on doing the cast to uint32_t of the address in upper memory? I'm using large code model. This is done the same way in MSPFRBoot although in CCS.

• In TI_MSPBoot_AppMgrDualImg.c

I have problems calculating the CRC.

On MSPFRBoot:

CRCINIRES = 0xFFFF;
data_ptr = (uint8_t*) &_Down_Start_Memory;

for(i = 0 ; i < (uint32_t) &_Down_CRC_Size1 ; i++)
CRCDIRB_L = *data_ptr++;

if ((uint32_t) &_Flex_Start != 0x10000)
{
data_ptr = (uint8_t*) 0x10000;
	for(i = 0 ; i < (uint32_t) &_Down_CRC_Size2 ; i++) 
        CRCDIRB_L = *data_ptr++;
}
result = CRCINIRES;

if (result != __data20_read_short((unsigned long)&_Down_Checksum))
return FALSE_t;
else
return TRUE_t;

In MSPFRBoot example the _Down_Start_Memory is below 64kB.

If I use my memory distribution, placing download area starting at 0x10000:

extern uint32_t _AppChecksumDown;   // Address of Download area checksum
extern uint32_t _App_StartDown;     // Address of Download area start
extern uint32_t _App_CRCDown_Size;  // Address of Download area calculated

CRCINIRES = 0xFFFF;
data_ptr =(uint8_t*) &_App_StartDown;

for(i = 0 ; i < (uint32_t) &_App_CRCDown_Size; i++)
CRCDIRB_L = *data_ptr++;

result = CRCINIRES;
  
if (result != __data20_read_short((unsigned long)&_AppChecksumDown))
return FALSE_t;
else
return TRUE_t;

I get the following error:

Error[e18]: Range error,
Number out of range. Valid range is -32768 (-0x8000) to 65535 (0xFFFF).
File: C:\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\Src\MSPBoot\AppMgr\TI_MSPBoot_AppMgrDualImg.c, Line: 119
Source: MOV.W #_App_StartDown, R13
Where $ = TI_MSPBoot_AppMgr_AppisValid + 0xF282 [0xF282]
in module "TI_MSPBoot_AppMgrDualImg" (C:\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\IAR\MSPBoot\BSLBased_DualImg\Obj\TI_MSPBoot_AppMgrDualImg.r43),
offset 0x24 in segment part 7, segment CODE
What: _App_StartDown [0x10003]
Allowed range: 0xFFFF8000 - 0xFFFF
Operand: _App_StartDown [0x10003]
in module ?ABS_ENTRY_MOD (),
this is absolute code

This seems to be due to addresses being on the upper 64kB.

If I hard code the download start address, like it was done in MSPFRBoot when download is divided into two regions:

data_ptr =(uint8_t*) 0x10000;

I get:

Warning[Pe1053]: conversion from integer to smaller pointer C:\Users\JCunha\Documents\IAR Embedded Workbench\Bootloader\Src\MSPBoot\AppMgr\TI_MSPBoot_AppMgrDualImg.c 119

And still the range error for the other upper memory addresses.

What am I missing?

Can you help me?

Regards,

Jorge

TI_MSPBoot_MI.h issue: I'm not quite sure why ((uint32_t)&_AppChecksumDown) or otherwise is returning a 16-bit value, all of my work was done in CCS for which there was no issue. This may be a better question to ask an IAR compiler team, meanwhile you do have a workaround.

TI_MSPBoot_AppMgrDualImg.c issue: This once again appears to be a difference between the CCS and IAR compilers. The logic is correct but the compiler is expecting a variable that is a pointer and not an integer value that has the address, therefore creating the warnings. What I don't get is why the error message suggests a signed value (-32768 to 65535 and 0xFFFF8000 - 0xFFFF) when you clearly use uint32_t, this doesn't look like a large memory code setup (I've never used this model in IAR). Perhaps there is a better way to declare these variables in your compiler, like extern unsigned long _App_StartDown;? No doubt IAR is confused about the usable memory space allowed.

Apologies for not being of much help in this regard,
Ryan

Hello Ryan.

Sorry for the late update.

I got in touch with IAR support and it seems in IAR for using large pointers it's necessary to change not only code model to large but also data model.

Now I solved one part of my problem, bootloader is working great.

My bootloader will use large code and data models, but my application, due to library restrictions cannot use large data model, so in my application I will have to use some workaround (like I suggested before) to retrieve variables from linker file.

I think I shouldn't have any issue in using large data model in bootloader and small data model in application (both will use large code model).

Regards,

Jorge Cunha

Hello Ryan.

I have another question, if you can help me.

Is there any way I can, for debug, force my app to be placed in my download area?

I tried download an extra image with an offset, but because my application uses space from below and over the bootloader area the extra image download takes this into account. So the high memory part of app is offset by the size of bootloader.

Other option was using --input for the binary raw, but this also takes the same issue into account.

Is there any way I can implement this?

Regards,

Jorge

Hello Jorge,

I don't quite understand what you are attempting, however I do not know of a formal or correct way of debugging an application installed by the custom bootloader code. Once the application is operational you could try debugging a running target using the program symbols from the application project. The best option may be to fully debug the bootloader and application (with the default command linker file) code separately before customizing it and adding the other necessary files required for MSPBoot.

Regards,
Ryan

Hello Ryan.

I was trying to merge both app and bootloader, but forcing app placement in download area.

But because my app (uses both low and high memory) is wrapped around bootloader, this does not work.

I cannot simply set an offset because for this I would need an offset for the low memory part of app and another for the high memory part.

This seems a no go option.

Regards,

Jorge

Hello Jorge,

If the wraparound/offset is the issue then would you benefit from not using the lower memory (0xC000 to 0xEFFF) and restricting the app and download areas to >0x10000? I know this isn't ideal but it may be a simple workaround for your debugging.

Regards,
Ryan