BSL Programming not persisting...

JerryJohns

Other Parts Discussed in Thread: MSP430F249, MSP430F248

Hello all,
I have an MSP430F249 chip that i've trying to program using the BSL ROM method - As a test, I've compiled the sample LED blinking code (msp430x2xx_fet_1.c) as a way to verify that i've downloaded the program correctly. Thus far, I've been able to communicate with the BSL, do a MASS ERASE, then RX PASSWORD and then finally the RX BLOCK. I've even done a TX BLOCK and can see the contents in memory matching my app.

When i finally do the LOAD PC call, I haven't been able to get the LEDs to start blinking; setting it to 0x4000, or even 0xfffe didn't help. Power cycling the MSP also didn't help. The LEDS only started blinking when i set the LOAD PC to 0x406a (where __main is). However, power cycling caused it to stop blinking.

Is there a reason why the MSP is behaving weirdly like this?

Any solutions will be much appreciated,

Thank you,

Jerry

over 16 years ago

0 old_cow_yellow over 16 years ago

Guru 58965 points

Sounds like your code is written in c and you do not know what BSL is loading into the Flash.

What are the contents of 0x4000 to 0x4069 and 0xFFFE to 0xFFFF?

0 JerryJohns over 16 years ago in reply to old_cow_yellow

Intellectual 650 points

I've put the TI-TXT version of the final binary file, as well as the output MAP file here in pastebin:
http://pastebin.com/m2f757d60

0x4000 contains the .text code section, while the reset_vector is located at 0xfffe.

Jerry

0 JerryJohns over 16 years ago in reply to JerryJohns

Intellectual 650 points

Can anyone please assist? I'm sure others must have run into a similar problem when doing the BSL ROM flashing method.

Thank you kindly,

Jerry

0 Brandon08 over 16 years ago in reply to JerryJohns

TI__Mastermind 24390 points

Please answer the following questions so that we can narrow down the cause of the problem:

2. What software are you using?

3. What board are you using to program the MSP430 (TI Board or custom design)?

5. Can the code be downloaded using the JTAG interface?

7. Apparently after entering the BSL, sometimes PC software does not maintain the RTS signal in its last state (because the PC comm port is being reset). And this interferes with further communications and causes subsequent valid BSL commands to NAK. If this is the case and you remove the port-reset, your target may began responding to all the BSL commands as expected.

8. Also see the two files on my profile. There is a script file and a hex file. Are you able to program using these files?

0 JerryJohns over 16 years ago in reply to Brandon08

Intellectual 650 points

1. Which BSL programmer are you using? Is it based of TI schematic and layout in SLAU265? Is it an off-the shelf product bought from one of the 3rd parties (like Elprotronic), or your own custom built programmer? Elprotronic MSP430 programmers
> It's a custom BSL programmer that we've designed - It involves UART TX, RX and a connection to the RESET and TCK lines of the MSP so that i can bring it into BSL ROM mode. All of this is verified functional, as I can communicate using BSL ROM without any issues (all commands work)

2. What software are you using?
> Custom SW running on an OMAP3 that talks via UART to the MSP

3. What board are you using to program the MSP430 (TI Board or custom design)?
> OMAP3EVM

4. Can this problem be reproduced using a simple blinking LED code example (converted to a .txt file)? This example can be found on this page, depending on device and software tool: www.ti.com/msp430codeexamples
> Like i mentioned before, once I've uploaded the code over BSL, branched to __main, i can get the blinking to start. Its after a power cycle that it fails to persist.

5. Can the code be downloaded using the JTAG interface?
> Using the FET tool, yes I am able to program it over JTAG. The LEDS still keep blinking even after a power cycle.

6. Can you reproduce the issue by using another MSP430 as a BSL replicator to program your device, like described in SLAU265 app report? This will eliminate BSL hardware and software issues. Please see chapter 9 of the application note at the link above.
> I have not tried this yet, but this only exercises the JTAG method which is not a problem in my tests.

8. Also see the two files on my profile. There is a script file and a hex file. Are you able to program using these files?
> Will try this today

Thank you Brandon,

Jerry

0 old_cow_yellow over 16 years ago in reply to JerryJohns

Guru 58965 points

According to your TI-TXT file, the Reset Vector (located at 0xFFFE to 0xFFFF) is 0x40AE. Thus when you do the LOAD PC call, you should have told it to go to 0x40AE. Not 0x4000, not 0xFFFE.

Did you use TX BLOCK to check if the entire TI-TXT file are programmed correctly in Flash? That is, all the bytes from location 0x4000 to 0x4113 and location 0xFFFE to 0xFFFF ?

You are using c with rts430.lib thus the TI-TXT file included lots of unnecessary code. But the instruction MOV #0x2100,SP (located at 0x40AE to 0x40B1) is essential. Your main is located at 0x408C to 0x40AB will not work if SP is not pointed to RAM.

--OCY

0 JerryJohns over 16 years ago in reply to old_cow_yellow

Intellectual 650 points

I tried 0x40ae (as is the branch location at the reset vector) and loaded that into the PC - no avail. The LEDS defn didn't blink, and a reboot didn't help either.

HOWEVER, I instead modified the reset vector to hold 0x406a (instead of 0x40ae) and then restarted the board, and voila! the LEDS blink! and they blink every time i power cycle! :)

This confirms that the flash is holding its contents after every power cycle and that the problem had been with a faulty reset vector. Now, why is the reset vector faulty? This is my MAP file:

.text 0 00004000 000000f8
   00004000 00000040 rts430.lib : autoinit.obj (.text:_auto_init)
   00004040 0000002a : exit.obj (.text:exit)
   0000406a 00000022 : args_main.obj (.text:_args_main)
   0000408c 00000022 msp430x2xx_fet_1.obj (.text:main)
   000040ae 0000001e rts430.lib : boot.obj (.text:_c_int00)
   000040cc 00000012 : memcpy.obj (.text:memcpy)
   000040de 00000010 : epilog.obj (.text)
   000040ee 00000004 : pre_init.obj (.text:_system_pre_init)
   000040f2 00000004 : exit.obj (.text:abort)
   000040f6 00000002 : _lock.obj (.text:_nop)

.cinit 0 000040f8 0000001c
   000040f8 0000000c rts430.lib : _lock.obj (.cinit)
   00004104 0000000c : exit.obj (.cinit)
   00004110 00000004 --HOLE-- [fill = 0]

.reset 0 0000fffe 00000002
   0000fffe 00000002 rts430.lib : boot.obj (.reset)

Why is it calculating the wrong reset vector? The compiler seems to be trying to branch to 0x40ae, but why does that not work?

Any help is appreciated,

Thank you,

Jerry

0 old_cow_yellow over 16 years ago in reply to JerryJohns

Guru 58965 points

Does the MSP430 chip you use have 4KB of RAM located at 0x1100 to 0x20FF?

From the TI-TXT you showed us, the c-compliler/linker generated 276 bytes of code/constant located at 0x4000 to 0x4113 and a 2-byte Reset Vector located at 0xFFFE to 0xFFFF.

Out of the 276 bytes, only 34 bytes (located at 0x408C to 0x40AD) are produced by your main(). The other 242 bytes are the overhead from rts library. If you do have RAM from 0x1100 to 0x20FF, those overhead does no harm. But if you if you do not have RAM there, your main() will not work.

#define _lock          0x1100
#define _unlock        0x1102
#define _cleanup_ptr   0x1104
#define _dtors_ptr     0x1106
#define __STACK_END    0x2100

_auto_init:
4000: 120A            push.w R10
4002: 1209            push.w R9
4004: 4C0D            mov.w R12,R13
4006: 933D            cmp.w #0xFFFF,R13
4008: 2410            jeq    0x402A
400A: 3C0C            jmp    0x4024
400C: 128F            call   R15
400E: 532A            incd.w R10
4010: 3C12            jmp    0x4036
4012: 4D3C            mov.w @R13+,R12
4014: 4D0A            mov.w R13,R10
4016: 490E            mov.w R9,R14
4018: 12B0 40CC       call   #memcpy
401C: 590A            add.w R9,R10
401E: 4A0D            mov.w R10,R13
4020: 531D            inc.w R13
4022: C31D            bic.w #0x1,R13
4024: 4D39            mov.w @R13+,R9
4026: 9309            tst.w R9
4028: 23F4            jne    0x4012
402A: 403F FFFF       mov.w #0xFFFF,R15
402E: 933F            cmp.w #0xFFFF,R15
4030: 2405            jeq    0x403C
4032: 403A FFFF       mov.w #0xFFFF,R10
4036: 4A2F            mov.w @R10,R15
4038: 930F            tst.w R15
403A: 23E8            jne    0x400C
403C: 4030 40E8       br     #0x40E8

exit:
4040: 120A            push.w R10
4042: 4C0A            mov.w R12,R10
4044: 1292 1100       call   &_lock
4048: 9382 1106       tst.w &_dtors_ptr
404C: 2403            jeq    0x4054
404E: 4A0C            mov.w R10,R12
4050: 1292 1106       call   &_dtors_ptr
4054: 9382 1104       tst.w &_cleanup_ptr
4058: 2402            jeq    0x405E
405A: 1292 1104       call   &_cleanup_ptr
405E: 1292 1102       call   &_unlock
4062: 12B0 40F2       call   #abort
4066: 413A            pop.w R10
4068: 4130            ret

_args_main:
406A: 403D FFFF       mov.w #0xFFFF,R13
406E: 403F FFFF       mov.w #0xFFFF,R15
4072: 933F            cmp.w #0xFFFF,R15
4074: 2005            jne    0x4080
4076: 933D            cmp.w #0xFFFF,R13
4078: 2003            jne    0x4080
407A: 430C            clr.w R12
407C: 430D            clr.w R13
407E: 3C04            jmp    0x4088
4080: 4D0F            mov.w R13,R15
4082: 4F2C            mov.w @R15,R12
4084: 432D            mov.w #0x2,R13
4086: 5F0D            add.w R15,R13
4088: 4030 408C       br     #main

main:
408C: 8321            decd.w SP
408E: 40B2 5A80 0120 mov.w #0x5A80,&WDTCTL
4094: D3D2 0022       bis.b #0x1,&P1DIR
4098: E3D2 0021       xor.b #0x1,&P1OUT
409C: 40B1 2710 0000 mov.w #0x2710,0x0(SP)
40A2: 8391 0000       dec.w 0x0(SP)
40A6: 9381 0000       tst.w 0x0(SP)
40AA: 23FB            jne    0x40A2
40AC: 3FF5            jmp    0x4098

_c_init00:
40AE: 4031 2100       mov.w #__STACK_END,SP
40B2: 12B0 40EE       call   #_system_pre_init
40B6: 930C            tst.w R12
40B8: 2404            jeq    0x40C2
40BA: 403C 40F8       mov.w #cinit,R12
40BE: 12B0 4000       call   #_auto_init
40C2: 12B0 406A       call   #_args_main
40C6: 431C            mov.w #0x1,R12
40C8: 12B0 4040       call   #exit

memcpy:
40CC: 4C0F            mov.w R12,R15
40CE: 930E            tst.w R14
40D0: 2405            jeq    0x40DC
40D2: 531F            inc.w R15
40D4: 4DFF FFFF       mov.b @R13+,0xFFFF(R15)
40D8: 831E            dec.w R14
40DA: 23FB            jne    0x40D2
40DC: 4130            ret

40DE: 4134            pop.w R4
40E0: 4135            pop.w R5
40E2: 4136            pop.w R6
40E4: 4137            pop.w R7
40E6: 4138            pop.w R8
40E8: 4139            pop.w R9
40EA: 413A            pop.w R10
40EC: 4130            ret

_system_pre_init:
40EE: 431C            mov.w #0x1,R12
40F0: 4130            ret

abort:
40F2: 4303            nop
40F4: 3FFF            jmp    0x40F4

_nop:
40F6: 4130            ret

cinit:
40F8: 0002 1100 40F6 dw     2,_lock,_nop
40FE: 0002 1102 40F6 dw     2,_unlock,_nop
4104: 0002 1104 0000 dw     2,_cleanup_ptr,0
410A: 0002 1106 0000 dw     2,_dtors_ptr,0
4110: 0000 0000

_reset_vector:
FFFE: 40AE            dw     _c_init00

0 JerryJohns over 16 years ago in reply to old_cow_yellow

Intellectual 650 points

Yes, the MSP430F248 (which i'm using) does have 4KB of RAM from 0x1100 to 0x20FF. Perhaps i can add some instructions to skip that cinit section to see if that is the true cause - is there some IRAM initialization that i have to do?

Jerry

0 old_cow_yellow over 16 years ago in reply to JerryJohns

Guru 58965 points

Could you try this.

Change your line #13 of your original TI-TXT file (the one you showed us)

from: 00 21 B0 12 EE 40 0C 93 04 24 3C 40 F8 40 B0 12

to: 00 03 B0 12 EE 40 0C 93 04 24 3C 40 F8 40 B0 12

Do not change anything else and run BSL.

0 JerryJohns over 16 years ago in reply to old_cow_yellow

Intellectual 650 points

That did not make a difference - loading PC of 0x40ae did not make the LEDS blink, and a power-cycle didn't help either
Perhaps i should just JTAG step this to figure out what those instructions are doing

0 old_cow_yellow over 16 years ago in reply to JerryJohns

Guru 58965 points

Please let us know you findings.

Just in case you cannot step from start-up, you can use the following fake "assembly code" which produces the the same Flash image as your TI-TXT file you showed us earlier.

#include "msp430.h"
        ORG     0x4000
_auto_init:
db 0x0A,0x12,0x09,0x12,0x0D,0x4C,0x3D,0x93,0x10,0x24,0x0C,0x3C,0x8F,0x12,0x2A,0x53
db 0x12,0x3C,0x3C,0x4D,0x0A,0x4D,0x0E,0x49,0xB0,0x12,0xCC,0x40,0x0A,0x59,0x0D,0x4A
db 0x1D,0x53,0x1D,0xC3,0x39,0x4D,0x09,0x93,0xF4,0x23,0x3F,0x40,0xFF,0xFF,0x3F,0x93
db 0x05,0x24,0x3A,0x40,0xFF,0xFF,0x2F,0x4A,0x0F,0x93,0xE8,0x23,0x30,0x40,0xE8,0x40
exit:
db 0x0A,0x12,0x0A,0x4C,0x92,0x12,0x00,0x11,0x82,0x93,0x06,0x11,0x03,0x24,0x0C,0x4A
db 0x92,0x12,0x06,0x11,0x82,0x93,0x04,0x11,0x02,0x24,0x92,0x12,0x04,0x11,0x92,0x12
db 0x02,0x11,0xB0,0x12,0xF2,0x40,0x3A,0x41,0x30,0x41
_args_main:
db 0x3D,0x40,0xFF,0xFF,0x3F,0x40
db 0xFF,0xFF,0x3F,0x93,0x05,0x20,0x3D,0x93,0x03,0x20,0x0C,0x43,0x0D,0x43,0x04,0x3C
db 0x0F,0x4D,0x2C,0x4F,0x2D,0x43,0x0D,0x5F,0x30,0x40,0x8C,0x40
main:
db 0x21,0x83,0xB2,0x40
db 0x80,0x5A,0x20,0x01,0xD2,0xD3,0x22,0x00,0xD2,0xE3,0x21,0x00,0xB1,0x40,0x10,0x27
db 0x00,0x00,0x91,0x83,0x00,0x00,0x81,0x93,0x00,0x00,0xFB,0x23,0xF5,0x3F
_c_init00:
db 0x31,0x40
db 0x00,0x21,0xB0,0x12,0xEE,0x40,0x0C,0x93,0x04,0x24,0x3C,0x40,0xF8,0x40,0xB0,0x12
db 0x00,0x40,0xB0,0x12,0x6A,0x40,0x1C,0x43,0xB0,0x12,0x40,0x40
memcpy:
db 0x0F,0x4C,0x0E,0x93
db 0x05,0x24,0x1F,0x53,0xFF,0x4D,0xFF,0xFF,0x1E,0x83,0xFB,0x23,0x30,0x41,0x34,0x41
db 0x35,0x41,0x36,0x41,0x37,0x41,0x38,0x41,0x39,0x41,0x3A,0x41,0x30,0x41
_system_pre_init:
db 0x1C,0x43,0x30,0x41
abort:
db 0x03,0x43,0xFF,0x3F
_nop:
db 0x30,0x41
cinit:
db 0x02,0x00,0x00,0x11,0xF6,0x40,0x02,0x00
db 0x02,0x11,0xF6,0x40,0x02,0x00,0x04,0x11,0x00,0x00,0x02,0x00,0x06,0x11,0x00,0x00
db 0x00,0x00,0x00,0x00,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
db 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF
        ORG     0xFFFE
dw 0x40AE
        END

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

BSL Programming not persisting...