MSP430G2744: MSP430G Software BSL Invocation problem.

I'm not sure about the correct C format, but what's found at 0x0C00 and 0x0C02 are word vectors that point to the BSL starting points.  So you have to treat them as indirect vectors, not as the beginning of executable code.  This won't be exactly the same for your G2744, but here's what's found at 0x0C00 of the G2553:

0c00: 0c06 .dw 0x0c06 ;Cold start vector
0c02: 0c1e .dw 0x0c1e ;Warm start vector
0c04: 3fff jmp 0x0c04 ;Endless loop
0c06: 40b2 mov.w #0xa540, &FCTL3 ;Cold start: toggle LOCKA, reset LOCK
0c08: a540
0c0a: 012c
0c0c: 90b2 cmp.w #0xaa55, &0xffde ;check key word - is BSL disabled?
0c0e: aa55
0c10: ffde
0c12: 27ff jeq 0x0c12 ;yes - infinite loop
0c14: 4031 mov.w #0x0220, SP ;no - set stack pointer, etc.
0c16: 0220
0c18: 430b mov.w #0, r11
0c1a: 43c0 mov.b #0, 0x0216
0c1c: f5fa
0c1e: c232 dint -- bic.w #8, SR ;Warm start - clear interrupts, etc.
0c20: c0f2 bic.b #0x32, &IE1
0c22: 0032
0c24: 0000
-etc-

You can read out that code for the G2744 using the Flasher.

Hi! 
Thanks for the quick response!

I tried 0x0C02 and  0x0C00 - the result is the same. 
When I try use 0x0C02, I cleared the LOCK and LOCKA bits.

In slau319x in paragraph 2.9.2 NOTE - warm start is not recommended.

Do the addresses 0x0C02 and  0x0C00 contain the first instruction BSL or the address of the transition?

Should i use 
(*(void(**)() )0x0C00)(); or
((void ( * )())0x0C02)(); ?


I tried this and that.

0c00:   0C06                .word   0x0C06
0c02:   0C1E                .word   0x0C1E
0c04:   3FFF                JMP     (0x0c04)
0c06:   40B2 A540 012C      MOV.W   #0xa540,&Flash_FCTL3
0c0c:   90B2 AA55 FFDE      CMP.W   #0xaa55,&0xffde
0c12:   27FF                JEQ     (0x0c12)
0c14:   4031 0220           MOV.W   #0x0220,SP
0c18:   430B                CLR.W   R11
0c1a:   43C0 F5FA           CLR.B   0x0216
0c1e:   C232                DINT    
0c20:   C0F2 0032 0000      BIC.B   #0x0032,&Special_Function_IE1
0c26:   40B2 5A80 0120      MOV.W   #0x5a80,&Watchdog_Timer_WDTCTL
0c2c:   40F2 0088 0057      MOV.B   #0x0088,&System_Clock_BCSCTL1
0c32:   40F2 0080 0056      MOV.B   #0x0080,&System_Clock_DCOCTL

When I try use ((void ( * )())0x0C02)(); -
I jump to 0x0C00, then next step 0x0C02 and endless cycle 0x0C04.

When I try use(*(void(**)() )0x0C00)(); -
I jump to 0x0C06, unlock FLASH, initialize register and etc.


Hi!
Thanks for the quick response!
I think my code is correct. I tried it in debagger. In more detail, I wrote earlier.

Hi.

This adjustment concerns a warm start, and I completely agree with it.
But I use cold start.

I use  indirect branch to address contained in word at 0x0C00.
On the С is the following code:
(*(void(**)() )0x0C00)();                   //Cold start

And I still can't get the response to sync byte (0x80).

Before enter in BSL I :

• disable interrupt
• set default value to Clock Module Registers
• reset the Timer_A registers
• reset interrupt registers
• clear all bit in SR register

Here is my program code:

__disable_interrupt();                      // disable interrupts
 
  DCOCTL = 0x60;
  BCSCTL1 = 0x87;
  BCSCTL2 = 0x00;
  BCSCTL3 = 0x04;
 
 
  TAR = 0x0;
  TACTL = 0x0;
  TACCTL0 = 0x0;
  TACCTL1 = 0x0;
  TACCTL2 = 0x0;
  TACCR0 = 0x0;
  TACCR1 = 0x0;
  TACCR2 = 0x0;
  IE1 = 0;
  IFG1 = 0;
  IE2 = 0;
  IFG2 = 0;
 
 
  __bic_SR_register(V);
  __bic_SR_register(SCG1);
  __bic_SR_register(SCG0);
  __bic_SR_register(OSCOFF);
  __bic_SR_register(CPUOFF);
  __bic_SR_register(N);
  __bic_SR_register(Z);
  __bic_SR_register(C);
 
  (*(void(**)() )0x0C00)();                   //Cold start

Maybe I forgot about something else?

Peter will be your best source on this, but I would suggest that you try flashing test firmware that consists of only the C indirect jump to BSL.  This would jump into BSL from the processor's initial boot state, and the purpose is to make sure that the branch instruction takes you to the right place.  Since hardware invocation works for you, this should also work.  If it does, then the problem is finding what your code is doing after bootup that leaves the processor in a state not expected by BSL.

Make sure your processor speed isn't too fast.  I think it's supposed to be 8MHz or below, but it wouldn't hurt to set it back to 1MHz.

When the software is called BSL I come to the right place, I tested it in the debugger.
I saw how it unlocks the flash, initializes Clock Module Registers, sets the stack pointer and call the frequency tuning procedure using the preamble (0x80).

Processor frequency 8 MHz from the internal generator. If I understand the assembler code correctly, the processor itself sets the frequency in BSL.

I will try with the test program and at a frequency of 1 MHz. I think everything will be good.

"If it does, then the problem is finding what your code is doing after bootup that leaves the processor in a state not expected by BSL."

I totally agree with you on this. But I can't find which resources I still need to free or clear.

Hello Sergey,

could you please let us know the status on your side? If your suspicion is going to the direction of incorrect clock system and other infrastructure settings, conflicting with the BSL functionality, one possibility of debugging it would be using the HW invoke, which as far as I understood works on your side, and stop the BSL execution with the debugger, check the module settings, and then compare the settings with the case of the SW invoke.

There are some main suspects, when something after correct password detection goes wrong with BSL communication.

1. Other interrupts, activated previously by user's SW, are active, interfering at some point with the BSL activities.

2. Timer settings are not matching the BSL requirements.

3. With a warm start, also the Stack Pointer is not initialized.

Best regards

Peter