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
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?
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.
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,
Please answer the following questions so that we can narrow down the cause of the problem:
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
2. What software are you using?
3. What board are you using to program the MSP430 (TI Board or custom design)?
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
5. Can the code be downloaded using the JTAG interface?
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.
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?
Regards,Brandon
DCAT - MSP430 ApplicationsTexas Instruments
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.
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.> I have no problems with NAK's - all BSL commands ACK back properly, and commands that get data back (like TX DATA BLOCK) also work fine
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,
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
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,
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 #0x40E8exit: 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 #mainmain: 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 #exitmemcpy: 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 retabort: 40F2: 4303 nop 40F4: 3FFF jmp 0x40F4_nop: 40F6: 4130 retcinit: 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
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?
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
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.
That did not make a difference - loading PC of 0x40ae did not make the LEDS blink, and a power-cycle didn't help eitherPerhaps i should just JTAG step this to figure out what those instructions are doing
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,0x40exit: 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,0x40main: 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,0x40memcpy: 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,0x41abort: db 0x03,0x43,0xFF,0x3F_nop: db 0x30,0x41cinit: 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
ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.
Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.