• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 4 answers
  • Subscribers 79 subscribers
  • Views 1742 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.

MSP430F5659: USB_PUR connection in order to invoke USB TI-BSL with a hard reset

user4725373
Expert 1645 points
Part Number: MSP430F5659
Other Parts Discussed in Thread: MSP430F5529,

Hi,

I'm trying to invoke the USB TI-BSL with a hard reset, but it looks like the device fails to enumerate (I get a "Device Descriptor Request Failed" in Windows' Device Manager).

I have attached a simplified version of the current circuit. Basically, we use USB on the MSP430 (not continuously), so D+ is pulled-up to USB_PUR with a 1.4k resistor. We have a button used with a GPIO, but if this button is pressed for more than 10 seconds, then a chip (U8 on the schematic) forces the RST_SBWTDIO of the MSP430 to 0V, thus resetting the device. When this reset occurs, we want to then connect the USB, release the button, and force the MSP430 to go into TI-BSL mode. From what I've read, I need to pull USB_PUR to VUSB through a 100 Ohm for that to happen.

Now, when I do this, I see that our main firmware isn't called after the device has reset, so the MSP430 is probably in the BSL, but it doesn't enumerate correctly via USB. Furthermore, if I have the USB already connected before entering the "hard reset" mode with the button, then even though the MSP430 is reset, it's still enumerated on the computer. It only disconnects when I release the button, then I get a "USB device not recognized".

What modification to the circuit do you suggest? Should the hard reset control the Vcc of the MSP430 instead of the RST_SBWTDIO?

Thank you,

Fred

BSL reset circuit.pdf

  • 0
    Guru 244220 points

    I see differences from figure 8 of SLAA457; I guess those are the simplifications?

    In theory, there should not be much of a difference between the BSL and the actual firmware.
    What clock are you using?

  • 0 in reply to Clemens Ladisch
    Expert 1645 points

    Yes, they are simplifications. (Edit: except the fact that there is no switch between the 100 Ohm resistor and USB_PUR).

    The clock is 19.2 MHz

  • 0 in reply to user4725373
    Guru 244220 points

    This is not one of the frequencies supported by the BSL (see section 3.6 of SLAA457, or footnote 1 of table 42-2 in the User's Guide).

    Change the crystal, or install a custom BSL. (If you're changing only the clock frequency, you can edit the BSL image without having to recompile it.)

  • 0 in reply to Clemens Ladisch
    Expert 1645 points
    Thank you, that was it. I was using the default BSL instead of our custom one.

    I do have a single issue that's left. If I'm plugged USB with the main firmware running, the device enumerates normally as "Our Device". If I put the device in reset with the push button, Windows' Device Manager keeps listing "Our Device" in the list, even though the MSP430 is in reset. Then, when I release the reset, "Our Device" disappears and now the TI-BSL enumerates as "USB Input Device" (VID = 2047, PID=0200), as it should.

    Is it normal that "Our Device" stays enumerated?

    Thank you,

    Fred
  • 0 in reply to user4725373
    Expert 1645 points
    I also just realized this behavior as well:
    1- USB is disconnected
    2- Put device in reset
    3- Plug in USB with device in reset
    4- "Unrecognized USB device" gets on the list
    5- Release the reset
    6- "Unrecognized USB device" disappears and "USB Input Device" gets listed

    Is it because USB_PUR is pulled-up to VUSB constantly?
  • 0 in reply to user4725373
    TI__Guru 56685 points
    Hello,

    PUR should not be pulled up constantly as this messes with the USB communication. PUR should only be pulled up when wanting to invoke the USB BSL when the part is coming out of reset.
  • 0 in reply to Jace H
    Expert 1645 points

    Hi Jace,

    Thanks for the answer. That does leave me with more questions.

    1- Since Vcc is never off on the MSP430, do I need to connect PUR to the 100 Ohms at the same moment that RST_SBWTDIO is pulled back high? Or should PUR be connected to VUSB before the reset is removed? I think the behavior I get right now is because D+ is pulled high even though the MSP430 is in reset.

    2- How long do I need to keep PUR connected to VUSB after a reset?

    3- Would it be better if the reset signal (from U8) would control the regulator of the MSP430 (i.e. the Vcc).

    4- When you say that it messes with the communication, what do you mean? I've been able to speak to my device with PUR always pulled to VUSB.

  • 0 in reply to user4725373
    Expert 1645 points

    Hi Jace,

    I'm looking at the circuit of the eval board of the MSP430F5529 (slau533d, figure 40), and instead of pulling down D+ with a 1M resistor, PUR is pulled down. Is this normal?

    Also, looking at that circuit, it seems that the device enters BSL when the RESET switch (S3) is pressed, then the BSL switch (S5) is pressed, then the RESET switch is released. Is that correct?

    If it's correct, then I can't explain why I get the following behavior, as it should act like the circuit from the eval board:

    1- USB is disconnected (thus VUSB = 0V)
    2- Put device in reset
    3- Plug in USB with device in reset (equivalent of connecting a 100 Ohms between PUR and VUSB)
    4- "Unrecognized USB device" gets on the list
    5- Release the reset
    6- "Unrecognized USB device" disappears and "USB Input Device" gets listed

    What do you think?

    Ideally, I think I could use a delay circuit on RST_SBWTDIO that would control an analog switch which would connect/disconnect PUR to VUSB (see figure below), but I want to be sure that I won't get the "Unrecognized USB device" behavior.

  • 0 in reply to user4725373
    TI__Guru 56685 points
    Hello,

    The MSP430F5529 Launchpad Schematic should not be used as a reference for USB design . It is a slightly different configuration due to the need of a shared USB terminal between two devices and a USB HUB between the terminal and devices. Please reference the following app note for USB Hardware design in particular Section 4.
    Starting a USB Design Using MSP430 MCUs (http://www.ti.com/lit/slaa457 )

    As you can see from the recommended configuration, PUR is weakly pulled down in conjunction with DP. the pulldown is weak enough to not disrupt operations on DP, but should not be eliminated as doing so might result in unintended invocation of the USB BSL. During normal operation, the PUR pin is an output that pulls up the DP pin via USB standard. For more information about how the PUR pin operates during USB operation, please see section 4.4 of the document linked above.

    To invoke the USB BSL via hardware, the PUR pin needs to held high externally during the moments following a BOR Reset. The typical procedure on our target and EVM boards is to press the USB BSL pushbutton (created connection to pull up PUR) then reset the device. Once the device has come out of reset, the pushbutton cna be released as the device is now in USB BSL mode. This is all outlined in the document linked above.
  • 0 in reply to Jace H
    Expert 1645 points

    Thanks for the answer.

    I now have confirmation of the intended procedure with the push-button, but the document you linked specifies no time constraints for PUR. I also haven't found any in the datasheet of the MSP430F5659. Since I plan to use an analog switch controlled by hardware as in my previous post, I wanted to have the delay needed for proper operation. Is 500 ms ok (see diagram below)?

    Also, I'm still unsure why I get the "USB device not recognized" behavior (see my previous post).

    Thank you,

    Fred

  • 0 in reply to user4725373
    TI__Guru 56685 points
    Hello Fred,

    You are correct that we do not specify time in which PUR must be held high. As noted in Section 4.4 in the document above, the decision that is made to go to USB BSL mode happens during the bring up from the BOR Reset process. The PUR pin is made an input and the voltage level is checked on the pin to see if the device needs to boot up in BSL mode. I wouldn't be worried as much as to how long the PUR signal must be help up, but more that you ensure the PUR signal is up while you are doing a reset. 500 ms seems more than enough in my opinion.

    As far as your USb behavior, I am unsure as the recommended USB HW design was not followed.
  • 0 in reply to Jace H
    Expert 1645 points
    Ok thank you.

    Then do you think 100ms would be fine? My guess is that the time required for PUR to be at VUSB depends on the time from reset to active, which should be pretty low.

    My fear about the "Unrecognized device behavior" is that pulling D+ to VUSB signals the host that there is a device present on the lines, thus it requests the descriptors of the device, and since the device is still in reset, the request fails. It would also explain why our device stays enumerated when we go in reset, as D+ is still pulled-high. What do you think of this interpretation?

    If the interpretation is correct, then I don't see how the eval board does not get the same behavior when connecting PUR to VUSB while the device is in reset, though.
  • 0 in reply to user4725373
    TI__Guru 56685 points
    Hello Fred,

    I would imagine 100ms would work as well . I would take a look at the datasheet for our LPMx.5 wakeup time and double that as a worst case. A wakeup from LPMx.5 modes does a full BOR Reset so that time should cover your situation.

    I haven't run into your unrecognized device behavior before as I have not done the same circuit you have so I cannot comment on what could be exactly wrong. More than likely it's an issue with the USB stack process with a combination of HW, but I'm not versed in that level of detail about the USB Stack to comment.
  • 0 in reply to Jace H
    Expert 1645 points

    Ok thank you.

    I think I'll order the eval board of the 5529 just to be sure that the reset circuit works like I intend it. I could then prototype the delay + analog switch circuit on it as well.

  • 0 in reply to Jace H
    Expert 1645 points

    Hi Jace,

    Just to let you know that I've received the eval board and I get the same behavior as my PCB (i.e. "Device Descriptor Request Failed" when I connect USB_PUR to VUSB for too long while the device is in reset). It really seems that pulling D+ is what tells the host to send a device descriptor request, which will fail if the device is still in reset. Furthermore, if I release the reset after having received the "Device Descriptor Request Failed" event, then the BSL just does not enumerate and I need to redo the procedure.

    Timing seems quite critical for this application, but it's more on the side of "don't press the button too long" instead of too quickly.

    Fred

  • 0 in reply to user4725373
    Expert 1645 points

    Also letting you know that 200ms was enough delay.

**Attention** This is a public forum