• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 80 subscribers
  • Views 1219 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.

Sharing SBWCLK pin

yvonh
Prodigy 200 points
Other Parts Discussed in Thread: MSP430G2230

Hi all,

I'm working on a project using the MSP430G2230 and I have very limited access to outside signals.  I'd like to share one output GPIO with the TEST/SBWCLK pin.  This would allow programming the MSP430 with the same connector as the end design which includes only 4 pins: 3.3V, ground, reset and one output signal (or SBWCLK when programming).

In this project, the output is driven high by default and when it goes low it's at least for 10 milliseconds long.  Timing between low pulses is always at least 100milliseconds and could be up to several days.  On power up, the firmware waits a few seconds before driving the output to give a chance to the MSP430 to be reprogrammed.

In the User's Guide "MSP430 Programming Via the JTAG interface" (SLAU320M), it is mentioned that: "...Exit the SBW mode by holding the TEST/SBWTCK low for more than 100us...".

Based on our design output timing, the 100us SBW timeout and that the RESET line is always driven at 3.3V, I'd like to know if this would work.

I couldn't find in the documentation if the code would stop running based on the details listed above.

Any suggestions/comments?

Thanks,

 

  • 0
    Guru 58965 points

    My understanding is, for MSP430G22x0 chips, the TEST/SBWTCK pin can only be used to blow the JTAG Fuse, or as SBWTCK. In both cases, it is an input (with a weak pull-down). It cannot be used as GPIO pin.

    If I were you, I would connect TEST/SBWTCK in parallel with P1.2 and bring that out (plus Vcc, Vss, and nRST/NMI/SBWTDIO). But one should not try to  blow JTAG Fuse when they are connected together as that might damage P1.2.

  • 0 in reply to old_cow_yellow
    Prodigy 200 points

    Maybe I was not clear, I want to connect P1.7 to the TEST pin.  I was not sure if the firmware changes P1.7 state from 1 to 0 or 0 to 1, if it would put the MSP430 in debug mode and stop the code from running.

  • 0 in reply to yvonh
    Guru 58965 points

    I think P1.0, 1, 2, or 3 has a better chance to work with this scheme as compared to P1.4, 5, 6, or 7.

    I do not have a MSP430G2230.

  • 0 in reply to old_cow_yellow
    Prodigy 200 points

    I ran some tests and I can see that the firmware resets whenever the SBWCLK/TEST pin is toggled.  I'll have to find another solution.

    Thanks for your inputs.

  • 0 in reply to yvonh
    Guru 58965 points

    When the development tool is not attached to the chip, the only thing TEST pin does is to disable P1.4, P1.5, P1.6 and P1.7. It dose not reset the chip.

    A development tool (when attached to the chip) can use TEST pin in conjunction with nRST pin to force the chip to go to BSL or JTAG operations.

  • 0 in reply to old_cow_yellow
    Guru 12050 points

    Why would you want P1.7 connected to a pin that is the Spy-Bi-Wire clock input during programming?

    Only way you are going to get more GIO is to use the NMI as input.

    The NMI is tricky, you can not read its state but you can change the edge it triggers a ISR.
    And you could toggle the edge inside ISR to keep track if it's low or high.

    But if the edges are too fast and you don't change edge-polarity detection fast enough you could miss it
    and it will not catch up until your input signal toggles twice.

    For example. A Switch that is not hardware debounced would created edges back to back that are too fast.

  • 0 in reply to Tony Philipsson
    Guru 58965 points

    The way I understood what Wonh wants is as follows. He wants to make a very small MSP430G2230 based PCB that has only 4 wires connected to the outside out-side world. Through those 4 wires, he wants to be able to (a) use SBW tools to download firmware and (b) run the firmware with one GPIO connected to the out-side world. He will do either (a) or (b) depending on what is connected to those 4 wires. He cannot do (a) and (b) at the same time. His proposed way to achieve this is to use the 4 wires to connect (i) TEST pin in parallel with P1.7, (ii) nRST pin, (iii) Vcc, and (iv) Vss.

    According to the Data-Sheet, This should work. While doing (a) with SBW, P1,7 will be a high-impedance input pin (POR default setting) and should not interfere with the TEST pin used as SBWCLK. While doing (b) running the on chip firmware, TEST pin will be an input with very week pull-down and should not interfere with P1.7.

    However, I suspect that the Data-Sheet might have omitted something. Namely, during (b), TEST pin high might disable P1.4, P1.5, P1.6, and P1.7 for “normal” usage. Thus I suggested that wire (i) should be connected to TEST pin in parallel with P1.2 instead of P1.7. BTW, functional wise, P1.2 is more versatile than P1.7. If my suspicion were correct, connecting TEST and P1.7 in parallel may cause some interesting situation when the firmware tries to drive P1.7 high. This may have been misinterpreted as resetting the chip.

  • 0 in reply to old_cow_yellow
    Guru 12050 points

    Oh I see

    >very limited access to outside signals

    Hint:
    instead of a 4pin 2.54mm connector go with a 5pin 2mm connector, saves you the headache.

    On a pcb design I made, there are only 4pins to the outside and LATER they wanted to add custom BSL

    I have been able to use double duty for reset/NMI OK,
    it programs using sbw just fine even if reset function is turned in to nmi.

    I was able to turn NMI in to a crude 9600baud Rx pin but that is not for the faint hearted
    If I he want to share pins, I would go with nmi as long he can override any low signal coming in
    used for the other input pin and even if the other pin is an output it should also work as long it waits
    30seconds before going low after a power up.


    Most  programmers are open-drain so mixed low/high signals will not do any harm, but if the shared pin is an output set high, put a 2K ohm between these pins.

  • 0 in reply to old_cow_yellow
    Prodigy 200 points

    old_cow_yellow, you're right when you summarize what I intended to do.  The only thing you missed is my name:  YvonH.  LOL.

    This circuit connects to an existing main board so I didn't had the choice for the connector, it had to be 4 position, 1mm pitch.

    I did some tests and the firmware was reseting when it was trying to drive P1.7 high.  What I ended up doing is an "analog switch" using a few transistors and resistors.  On power up, P1.7 connects to the outside world and the TEST pin is isolated and pulled down.  A falling edge on the reset input turns on the "analog switch" and connect the TEST pin to the P1.7 signal.  I can only be reset by cycling the power off-on.  It seems to work fine this way.

  • 0 in reply to old_cow_yellow
    TI__Guru 68116 points

    old_cow_yellow said:
    According to the Data-Sheet, This should work. While doing (a) with SBW, P1,7 will be a high-impedance input pin (POR default setting) and should not interfere with the TEST pin used as SBWCLK. While doing (b) running the on chip firmware, TEST pin will be an input with very week pull-down and should not interfere with P1.7.

    One other thing I wanted to point out for future users that might stumble across this post or want to do something similar:

    The TEST and RST pins are also used to do the entry sequences for SBW, JTAG, BSL, etc. So toggling on these pins  could actually get you into some other mode by accident. In that case your part could basically "hang up" on you until you do a power cycle (e.g., you were running application code but then you started to enter SBW or JTAG, but since you aren't really having a debugger connected or anything your part is just going to sit there and do nothing or be in some unknown state). I've actually seen something like this happen when someone put a long wire on the TEST line and it was picking up noise (you can find descriptions of this kind of situation if you search the forum - solved by putting an external pulldown), but having TEST connected to another pin that is toggling could do the same thing. More information on SBW/JTAG/BSL entry sequences and the TEST/RST pins on SBW capable devices: www.ti.com/lit/pdf/slau320 figure 1-11

    Regards,

    Katie

**Attention** This is a public forum