• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 79 subscribers
  • Views 529 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP5437A rev G does not enter BSL

Mateusz Maciag
Prodigy 120 points

Other Parts Discussed in Thread: MSP430F5438A, MSP430F5437A, MSP-FET

Hi,

 

I got stuck during Bootloader development and I need help. I create custom BSL based on standard MSP430 BSL. The BSL entry algorithm is as follows:

1)      BOR

2)      BSL_Protect unconditionally sets R12 = 0x3 (assembly code attached below)

3)      Run BSL code. Actions performed by BSL are:

4)      Configure needed GPIOs, Clocks, Peripherals, …

5)      Flash led once – there is no condition on it so it should flash always I reset the MCU. No matter we stay in BSL or move to user code (see 6)

6)      Check if some conditions are met to continue BSL:

  • a) Check if known values can be found at specified address in FLASH space. If this special key is different than specified in BSL that means there is no/incorrect firmware. We stay in BSL (go to 7). If key was found go to b.
  • b) If button is pressed wait for special key sent by UART to stay in BSL. If button is released before key is received go to c.
  • c) Generate PUC (writing bad key to WDTCTL) – it causes execution of user code

7)      Run the rest of standard BSL (we can communicate e.g. with BSL_Scripter). To leave BSL we have to generate BOR (reset, power cycle or… send SET_PC 0xfffe – I have changed a bit the interpretation of this command)

 

I have tested this scenario on MSP-EXP430F5438 evaluation board with MSP430F5438A rev. D. Everything works as it should: by default a. condition is met because of no firmware. I use BSL_Scripter to load new firmware. After that I can enter Bootloader only when b. condition is met and it is Ok.

 

Now I am testing similar scenario on our board (there is no big changes – different port for led and button). We use MSP430F5437A rev. G. When I perform mass erase and program the BSL section everything goes well. I see led flashes and I can load firmware through BSL_Scripter or MSP-FET interface.

 

The problem appears after successful firmware download. After that MCU never enters BSL! Neither resetting nor removing power supply help. I don’t see led flash any more. Only mass erase and reprogramming BSL lets me enter BSL.

 

Could anybody tell me what may be wrong? Why old rev. D behaves better than G one ?

 

Thanks in advance,

Matthew Maciag

 BSL_Protect source code

BSL_REQ_JTAG_OPEN .equ 0x0001 ;Return Value for BSLUNLOCK Function to open JTAG
 BSL_REQ_APP_CALL .equ 0x0002 ;Return Value for BSLUNLOCK Function to Call BSL again
 BSL_Protect 
 CLR RET_low ; clear return value (R12 register)
BIS #SYSBSLPE+SYSBSLSIZE0+SYSBSLSIZE1 , &SYSBSLC ; protects BSL
 ;BIC #BSL_REQ_JTAG_OPEN, RET_low ;lock (keep JTAGLOCK_KEY state)
 BIS #BSL_REQ_JTAG_OPEN, RET_low ; make sure it remains open for debugging
; Always go to BSL first
 BIS.W #BSL_REQ_APP_CALL, RET_low
BCC2BSL RETA

 

  • 0
    Guru 227245 points

    Mateusz Maciag said:
    c) Generate PUC (writing bad key to WDTCTL) – it causes execution of user code

    You considered that a PUC won't reset all peripherals? E.g. Timer registers are NOT reset (including the IE bits). So if you changed something in step4, ensure that it is reset to default values before you force the PUC. And if you exit BSL by a MOV &0xFFFE,PC, nothing is reset at all, which can heavily surprise the application.

    Mateusz Maciag said:
    there is no big changes – different port for led and button)

    ...and the button is required to enter BSL once a valid firmware has been uploaded. So double-check this.

  • 0 in reply to Jens-Michael Gross
    Prodigy 120 points

    Thanks for reply

    Jens-Michael Gross said:
    You considered that a PUC won't reset all peripherals? E.g. Timer registers are NOT reset (including the IE bits). So if you changed something in step4, ensure that it is reset to default values before you force the PUC. And if you exit BSL by a MOV &0xFFFE,PC, nothing is reset at all, which can heavily surprise the application.

    I agree about PUC. It will be good for user code to start with known state. I will think about this.

    Jens-Michael Gross said:
    ...and the button is required to enter BSL once a valid firmware has been uploaded. So double-check this

    The problem is that before button state is checked I should see step 5. There is no condition that would cause not seeing blinking led unless BSL is corrupted. When firmware is downloaded i can't see step 5. 

    I have just observed an interesting thing. When I send MASS_ERASE through BSL_Scripter bootloader is not entered any more. It looks like MASS_ERASE removes BSL as well. But I have tested this on MSP-EXP board it never happend...

**Attention** This is a public forum