MSP430 bootstrap loader's even parity

Parity (even or odd) is redundant. You can strip (discard) the parity bit and give only the data bits to the Bluetooth module. When you receive the data bits from the Bluetooth module, you can generate and add the parity bit (based on the data bits received).

Alternatively, you could modify the BSL code on both side (PC and chip) so that parity is not used.

Yes, I'd like to modify the BSL code but where is the source code? I couldn't find it.

The BSL wiki page might be a good starting point.

Also SLAU319 and SLAA450. You can find the source code of the BSL here.

Katie,

For MSP430FR5xx, I think the “Flash-based” BSL-ROM has a portal with the password “DEADBEEF”. This portal enables code reside in Main-Flash to access subroutines residing inside BSL-ROM.

Is there any TI document about this portal?

--OCY

Hi old_cow_yellow,

I haven't heard of this before, and I'm not sure if I understand your meaning. Could you give me more information and I will look into it? Feel free to send me a private message if that would be easier.

Regards,

Katie

Hi old_cow_yellow,

The FR5xx devices have a BSL that is in ROM, not Flash or FRAM and cannot be modified. All you can do is jump into it from main application by jumping to 0x1000 (address pointing to the beginning of the BSL area). It is not modifiable.

Taking a stab at what I think you might be thinking of, which is something on devices with Flash, not ROM BSL:

The Flash based (non FRAM) F5xx/6xx devices have published source code that goes with SLAA450. (Note that this does not include source for FR5xx/6xx ROM BSLs, though they should be similar). In this source you can see in BSL430_Low_Level_Init.s43 the function BSL_ACTION0, which is located in the Z-Area. The Z-area, documented in SLAA450 section 1.1.1, can be used to provide some publicly accessible functions, and one of the things that is checked is that two registers contain DEAD BEEF, and then a third register corresponds to a function ID that you can define. However, by default there aren't any publicly accessible functions in this area, they are something you would have to add yourself. Since this is the case, on a ROM BSL there isn't anything you can do because you can't modify the ROM BSL.

Regards,

Katie

Katie,
You are right about FR5xx have BSL in ROM that cannot be modified. The disassembled X-area of this BSL-ROM is as follows:
1000    3C09            RomBsl: jmp     bsl
1002    3C12            Portal: jmp     access
1004    3FFF                    jmp     $
1006    3FFF                    jmp     $
1008    3FFF                    jmp     $
100A    3FFF                    jmp     $
100C    3FFF                    jmp     $
100E    3FFF                    jmp     $
1010    0600            ver:    dw      0x0600
1012    7231                    dw      0x7231
Where the Portal at 0x1002 does the following:
1028    903D DEAD       access: cmp.w   #0xDEAD,R13
102C    2004                    jne     bad
102E    903E BEEF               cmp.w   #0xBEEF,R14
1032    2001                    jne     bad
1034    3C03                    jmp     good
1036    430C            bad:    clr.w   R12
1038    430D                    clr.w   R13
103A    0110                    reta
103C    413C            good:   pop.w   R12
103E    413D                    pop.w   R13
1040    0110                    reta
Thus the main application can use this X-area Portal to indirectly jump to or call any existing code in the protected non-Z-area of this BSL-ROM. Here is a procedure for the main application to achieve this:
; Load R15 with the address of the destination in ROM-BSL
; And jump or call (using calla) this routine
Dead_Beef_Portal:
        push.w  #0
        push.w  R15
        push.w  R13
        push.w  R12
        mov.w   #0xDEAD,R13
        mov.w   #0xBEEF,R14
        br      #0x1002
The BSL in ROM consists of a very short init and loop to accept-execute commands. Here is the disassembled bsl, init, and loop:
1014    4031 2000       bsl:    mov.w   #0x2000,SP
1018    13B0 16BC               calla   #Fill_RAM
101C    930C                    tst.w   R12
101E    2400                    jeq     quit
1020    13B0 16A0               calla   #init
1024    13B0 1772       quit:   calla   #deadend
    ....                    
16A0    120A            init:   push.w  R10
16A2    434A                    clr.b   R10
16A4    13B0 170C               calla   #Init_FR
16A8    13B0 15B6               calla   #Init_CS_UART
16AC    13B0 113C       loop:   calla   #Get_Cmd
16B0    4C4A                    mov.b   R12,R10
16B2    B35A                    bit.b   #0x1,R10
16B4    2BFB                    jnc     loop
16B6    13B0 1042               calla   #Exec_Cmd
16BA    3FF8                    jmp     loop
They call various subroutines elsewhere in this ROM-BSL. Hence it very easy to write a similar BSL in Main-Flash and call the same subroutines via the Dead_Beef_Portal.
For example, to change the Even-Parity of the original spec., one only needs to add a few lines of code after calling Init_CS_UART (0x15B6). Another example is, you can add a filter after calling Get_Cmd (0x113C) and before calling Exec_Cmd (0x1042).
Yes, you cannot change the BSL-ROM, But you can make use of the code in BSL-ROM to do what you want to do through the access portal.

--OCY

Thank you for that.

If I understand you correctly, though, that can't be done by performing the /RST-TEST entry sequence.

The reason I would like to enter the BSL is because if the  FRAM code is corrupted, I would be able to 

enter the BSL and completely reload the firmware from scratch.

Your understanding is 100% correct. The remaining questions are:

(1) How do we enter this BSL if the main application does not initiate this BSL -- due to any reason? The answer may be using one of otherwise unused pin, or a special power-up condition of the BSL TXD signal from the PC.

(2) How do we protect this BSL from being altered unintentionally by the main application? The answer may be partition the FRAM and use the MPU to provide some protection of this BSL.