• State Answer Suggested
  • Locked Locked
  • Replies 17 replies
  • Answers 1 answer
  • Subscribers 84 subscribers
  • Views 9271 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Invoking USB BSL from user program MSP430F5514

Reto Truninger
Intellectual 525 points
Other Parts Discussed in Thread: MSP430F5514, MSP430F5529, MSP430F5528

I am trying to invoke the BSL from my user code on a MSP430F5514 with the following code:

{

  typedef void (* __data16 functionpointer)(void);

  const functionpointer bsloader = (functionpointer)(0x1000);

  USB_disconnect();
  USB_disable();

//   SYSBSLC &= ~(SYSBSLPE | SYSBSLOFF); //Tried with or without this line

__disable_interrupt();

    // enter BSL
    bsloader();

}

It does not work, all I get is a hung CPU. Is there anything I'm missing? I also tried to jump to 0x1002 instead, in this case the CPU does restart the user program but not start the BSL. On my Hardware the PUR is pulled low with 1M. I can invoke the BSL by pulling PUR high while doing a reset.

 

  • 0
    TI__Expert 3315 points

    Hi,

       Jumping or calling address 0x1000, with disabled interrupts, is 100% correct.  Have you examined the assembly to make sure your code is doing that?

  • 0 in reply to Lane Westlund
    Intellectual 525 points

    The code is doing what it's supposed to, I can set a breakpoint on 0x1000 and it get's there with ints disabled:

    ---
        USB_disconnect();
     005FD2    13B0 494C          calla   #USB_disconnect
        USB_disable();
     005FD6    13B0 4AA4          calla   #USB_disable
    __disable_interrupt();
     005FDA    C232               dint
     005FDC    4303               nop
        bsloader();
     005FDE    0080 1000          bra     #0x1000

     --

     

    In the disassembly window in IAR at address 0x1000 I can only see 0xFFFF. If I manually change SYSBSLC from 0x0003 to 0x4003 then all I can see in the debugger is 0x3FFF.

     If I scoll down I only can see sort of valid code from around address 0x1A00. I did check the "Allow erase/write access to locked flash memory" and "Allow erase/write access to BSL flash memory" checkboxes as suggested in another thread.

    Any ideas?

  • 0 in reply to Reto Truninger
    TI__Expert 3315 points

    It's worth considering the possibility that this device either does not have BSL, or has had it erased.  A pretty fool proof way to check is to have a little BSL reader program which unlocks the BSL, then dumps some memory into a RAM arrray, which you can check out using the debugger.  Usually however, when you uncheck those bits using the debugger, you can also read the BSL memory and see the program there.

  • 0 in reply to Lane Westlund
    Intellectual 525 points

    As mentioned before, the BSL works fine if I invoke it by pulling PUR low during reset, however I need to have a method on invoking it from the user software. I did do a memdump over the USB (I somehow didn't get any conclusive results using the IAR debugger), I attach the text file:

    0143.bootloader.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    1000:3C34
    1002:3C08
    1004:3FFF
    1006:3FFF
    1008:3FFF
    100A:3FFF
    100C:3FFF
    1010:0300
    1012:3383
    1014:903D
    1016:DEAD
    1018:2004
    101A:903E
    101C:BEEF
    101E:2001
    1020:3C03
    1022:430C
    1024:430D
    1026:0110
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Does the code in this memdump make any sense?

  • 0 in reply to Reto Truninger
    TI__Expert 3315 points

    Its tough to tell exactly, looking at the output, but it seems correct (I just see a couple familiar words there).  Plus, as you say, the BSL works via other invoke methods.

     

    This is tricky, setting the PC to 0x1000 should work exactly like the other invoke.  Perhaps it's just not being registered correctly on the host side?

  • 0 in reply to Lane Westlund
    Intellectual 525 points

    Problem solved... I've got to identical PCB's here, but only one has the JTAG sodered on. I was trying to get it to work on the PCB with the JTAG, but as described before I was not having any luck getting any useful data with the debugger. It seems now that this HW has got a problem with the BSL.

    On the other PCB (without the JTAG) I was always only loading the firmware over the USB (by pulling PUR low). This is the HW I also used to generate the memory dump. On my working USB code I was not calling    USB_disconnect(); and USB_disable(); before invoking the BSL. Turns out this is needed and now it works (on the one PCB). This is the code I use:

    {
        typedef void (* __data16 functionpointer)(void);

        const functionpointer bsloader = (functionpointer)(0x1000);

        USB_disconnect();
        USB_disable();

        SYSBSLC &= ~(SYSBSLPE);

        //disable interrupts
        __disable_interrupt();

        // enter BSL
        bsloader();

    }

    Thanks for your excellent support!

  • 0 in reply to Reto Truninger
    Expert 1580 points

    Hello :

    I am beginner with BSL... I try to implement the same thing and I have the same symptom than described in this post. I use a MSP430F5529.

    When the JTAG is connected to the MCU I can trigger the BSL code from a software call using USB communication  (pid / vid 0x2047, 0x0200) and process normally my firmware update (I use the RAM_BSL.00.05.04.34 file ) . But when the JTAG is not connected I can't trigger the BSL via a software call (the pid/vid is still 0x2047, 0x300). The PUR is pulled low with a 1M resistor...

    Any help would be appreciated...

    Thank you very much

    Cedric

    [edit] When the JTAG is connected I use the CCS debugger environment...

  • 0 in reply to Cedric 40627
    Intellectual 525 points

    My symptoms were slighty different. The one the board with the JTAG soldered on, the SW invokation of the BSL would never work, even when the JTAG is not connected, so I think that I must have stuffed something up on this board (either BSL firware or even the HW). I'm using my other board now (no JTAG connector has ever been soldeder on) and this has been working fine ever since. If you can, it would be worth maybe trying with a new board (or new CPU at least), and try to get it to work withour ever using JTAG (or SpyBi Wire).

  • 0 in reply to Reto Truninger
    Expert 1580 points

    Thanks for your suggestion, I think I have found out where my problem was... I continue to investigate and I will post it here for the benefit of TI community.

    Thanks and have a great day,

    Regards,

    Cedric

  • 0 in reply to Reto Truninger
    Intellectual 435 points

    I have exact the same problem and adding "SYSBSLC &= ~(SYSBSLPE);" won't fix the problem, what else could be wrong? I can do the flashing with SW3, but just can't enter the BSL via software. Without SYSBSLC &= ~(SYSBSLPE);, the code execution jump right back to my application, with "SYSBSLC &= ~(SYSBSLPE);", it just stuck, nothing happens unless I recycle the power.

    Thanks!

     

  • 0 in reply to Cedric 40627
    Prodigy 70 points

    Cedric,

    Were you able to solve this problem and invoke the BSL via software?  I would appreciate hearing how you did so as I am trying to do the same thing with the MSP430F5529. Thank you in advance.

    Regards,
    Cory W. Baker

  • 0 in reply to Cory Baker
    Expert 1580 points

    Hello Cory :

    Yes I have been able to solve the problem, it was hardware related... (I have an external hardware watchdog which was resetting my uC when switching BSL) The software was working properly.

  • 0 in reply to Cory Baker
    TI__Guru 73216 points

    Hi Cory,

    I think the app note USB Field Firmware Updates on MSP430 MCUs might be helpful for you - it describes various different entry methods for different use cases. In particular section 4 talks about different system update models you might use. Section 4.3 will tell you the steps to switch from normal USB function in your application to invoking the BSL - this includes disconnecting from USB in your software and disabling general interrupts before calling the jump to 0x1000.

    Regards,

    Katie

  • 0 in reply to Katie Pier
    Intellectual 570 points

    Hello,

    Thank you all, this blog helped me alot! 

    But now the FW upgrade is failing with the following log:

    Opening HID device HID device (vID=0x2047, pID=0x0200, v=0x0105); Unknown manufacturer; @input.inf,%hid_device%;HID-compliant device, Path: \\?\hid#vid_2047&pid_0200#7&14785a30&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
    Mass erase...
    Download full BSL...
    Programming...
    Programming: OK
    Waiting for BSL...
    closing HID device
    Closed!...
    Exception in Tkinter callback
    Traceback (most recent call last):
      File "C:\msp430usb\msp430_usb\imports\MSP430USBDevelopersPackage_4_00_02\Host_USB_Software\Python_Firmware_Upgrader\build\pyi.win32\Python_Firmware_UpgraderGUI\out00-PYZ.pyz\Tkinter", line 1410, in __call__
      File "<string>", line 275, in selectFile
      File "<string>", line 180, in doLoad
      File "<string>", line 251, in open_connection
      File "C:\msp430usb\msp430_usb\imports\MSP430USBDevelopersPackage_4_00_02\Host_USB_Software\Python_Firmware_Upgrader\build\pyi.win32\Python_Firmware_UpgraderGUI\out00-PYZ.pyz\msp430.bsl5.hid", line 101, in open
    ValueError: USB VID:PID 2047:0200 not found (not in BSL mode? or try --device)

     

    Can you please help me in resolving this problem.

    Thanks & Regards,

    Deep

  • 0
    Prodigy 30 points

    I had the same problem.

    The CPU MSP430F5528 did restart after entering BSL from software.

    The problem was in using NMI:

     SFRIE1 = OFIE; // Enable osc fault interrupt

    Then I disabled NMI Interrupt before entering BSL:

    SFRIE1=0;

    the problem had been solved.

  • 0 in reply to Nikita Kuznetsov
    Intellectual 570 points

    Hello Nikita,

    I could resolve it.

    Regards,

    Deep

  • 0 in reply to graviton
    Intellectual 330 points
    Old post but if someone is reading this, I found this statement in SLAU319i.pdf for USB BSL:
    "When starting this BSL from an application, the application should first de-enumerate itself, then delay
    (approximately 500 ms), before starting the BSL. This allows proper re-enumeration with the host."

**Attention** This is a public forum