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.

msp430f2274 Controller reset when jumping from Application to Custom BSL.

Other Parts Discussed in Thread: MSP430F2274

I am working on custom bootloader for msp430f2274 for image upgrade over Rs485. The bootloader update the current application and maintain the image state which is validImage or InvalidImage. On StartUp the controller in boot mode and check the image state which is stored in flash. If the imagestate is valid it jumps to application mode if the imagestate is invalid then it stays in bootmode and wait for the imageupgrade packet.

From BSL mode I am able to update application successfully but when I am in application if I try to update the application it change the image state and come to the bootmode. In BootMode controller resets continuously at a point when i am enabling the interrupts.(  __enable_interrupt(); ) .

But when I do POR the controller is working fine in bootmode.

  • Hi Mohit,

    Mohit kumar1 said:
    but when I am in application if I try to update the application it change the image state and come to the bootmode

    How are you making this change?? Are you writing to a shared memory between both images (Boot / App) and then forcing a reset or are you jumping to an specific location in your boot code?? Do you re-initialize anything?? (Stack/RAM, etc..) 

    Mohit kumar1 said:
    In BootMode controller resets continuously at a point when i am enabling the interrupts

    What kind of reset are you getting??( A Watchdog reset perphaps) Where does it jumps after you enable the interrupts?? Also what is the status of your Interrupt Flags (IFGx)??

    Anyway, hopefully this helps.

    Regards,

    David

  • Mohit kumar1 said:
    ... but when I am in application if I try to update the application it change the image state and come to the bootmode. In BootMode controller resets continuously at a point when i am enabling the interrupts.(  __enable_interrupt(); ) .

    But when I do POR the controller is working fine in bootmode  

    Instead of jump to the BootMode, try to cause a POR. For example, WDTCTL = 0;

  • Thanks David for your reply.

    I am jumping to an specific location in your boot code. I also tried WDT to jump to boot mode. Both work fine. I also printed the flags status in the boot mode when it hangs (IFG1- 02 & IFG2- 0A) and when it run successfully after POR (IFG1- 02 & IFG2- 0A).

    After enabling interrupts it just reset I do not know how to catch its jump when we enable interrupts. Because I can not run it in debug mode. I am just have uart prints and one led.

  • Thanks for your reply.

    Please suggest another way its not working same issue. Our product ready to deploy at field and we have to remotely upgrade the firmware.
    Please suggest how to do the POR.
  • Hi Mohit,

     I've developed a couple of "custom" boot loaders and I've used the watchdog reset as old_cow_yellow suggested without any problem.

    Could you please give us more information on your code flow?? For example:

    Maybe there is a problem with the stack, but it is hard to say with the info that we have.

    Regards,

    David

  • Here is the block dia.

  • In all the cases after POR it works fine.
  • Before jumping to the boot code, do you disable all interrupt sources? Especially the timers (including the TAIE and CCIE bits) are NOT reset on a PUC, so as soon as you set GIE, the CPU might try to call the timer ISR - and cause another PUC.
  • yes timers and adc interrupts were causing the issue. After disabling the interrupts its working fine now. 

  • Hi Mohit kumar1,

    I've been working with the MSP430F2274 too, can you tell me how did you achieve the POR, because I assume that you can make a RESET at the distance, what I find out is that you can do a POR by software, so I don´t have any clue to beggin the BSL.

    Thanks.

    ANDRÉS FELIPE RODRÍGUEZ

  • A possible way to cause a POR by software on 2x family is to connect the reset pin with a port pin and pull it low. The hardware reset will switch the port pin to high-impedance input and this will release the reset.
    On 5x family, the power management module has control bits to force a BOR or POR.

**Attention** This is a public forum