Custom EzFet Lite

[greeeg 460]

I recently built my own ezFET lite based of the files that TI have made available.

 

Update 9/06:

Works "kinda" as expected.

Board disconnects from USB when a target board is attached and is being powered by the ezFET

 

Orange LED is 10x brighter than green LED. Will correct resistor values in next rev.

 

Programming works. Unfortunately I do not have a target board to test out the UART bridge yet.

 

Board is panelized, and fits in a 5cm square. This is the first time I've done this, copper pour gets very close to the edge when the boards are cut.

 

Downloads:

ezFet_lite_tagConnect_0_01.zip

Altium pcb/sch files, gerbers, schematic.

 

 

Information below is old, was due to the custom BSL not being flashed to the MSP430.

 

Unfortunately It doesn't work.

 

The board is identical to the reference schematic, all component values are equal.

 

The board enumerates fine,

When I plug in a target board I get error,

tilib: MSP430_Initialize: Interface Communication error (error = 35)

If I connect a target then connect the USB the board throws error

tilib: MSP430_OpenDevice: Unknown device (error = 5)

Finally, If I try to force a fw update via mspdebug

MSP430_GetNumberOfUsbIfs
MSP430_GetNameOfUsbIf
Found FET: COM3
MSP430_Initialize: COM3
Updating firmware using /cygdrive/e/eZ-FET lite rev 1.10 Release Package/Firmware/EZFET_LITE_Rev1_1_FW_3_3_0_6.txt
Starting firmware update (this may take some time)...
tilib: MSP430_FET_FwUpdate: Hardware State is unknown (error = 77)
tilib: device initialization failed

Does anyone have experience with the ezFET lite firmware? am I missing something obvious?

 

I'll keep debugging this and report my findings.

 

Edited June 9, 2014 by greeeg

[zeke 693]

Can you upload your design files?

Can you point me to the TI reference files?

I will check your design and pcb against the ref design and look for the gotcha, if it is there.

 

Have you tested it on several target boards?

Have you followed the circuit design rules on the spi bi-wire lines? If the capacitor is missing then it won't work.

 

Do you have a logic analyzer? If so, record and compare the initial patterns of the TEST and RESET lines on a known working TI FET programmer to your unit.

 

My intuition says that you will find timing differences. There is a TI document somewhere that describes the SBW state machine and it's timings. Check out page 11 of http://www.ti.com/lit/ug/slau320n/slau320n.pdf.

 

And, I want to say that this is a very cool design idea. I want to see you succeed!

[greeeg 460]

Thanks, I'll upload the designs soon, they're on my other computer.

 

Here is the wiki page which has a link to TI's designs. (http://processors.wiki.ti.com/index.php/EZ-FET_lite) I've been over the schematics multiple times, no luck.

 

I've made a bit of headway with this.

 

The design files feature a compile firmware file. The source of which I assume is part of the MSP430 debug package (http://processors.wiki.ti.com/index.php/MSP_Debug_Stack)

 

The issue is that the compiled firmware is V3.3.0.6

But the two PC's I'm testing on are;

• Windows 8, Cygwin, Mspdebug MSP430.dllv3 (v3.3.1.3)
• Ubuntu (ARM build), Mspdebug libmsp430.so (v3.4.0.20)

So all the firmwares are mismatched, But it never tells me I need to update. The TI ezFET-lite requires a FW update every time I switch it between these PCs.

 

I tried on the Windows machine, and it successfully connected to a MSP430F5513. I managed to unlock the BSL and read the whole 2k block.

Ubuntu machine still throws errors.

 

So I'm quite certain it isn't a PCB issue now. and more of a FW issue.

 

Related, TI provide a FW file in the TI package for the BSL. does the ezFET use this BSL for it's FW updating?

I did unlock the BSL and flash this file, and it seemed to run without issue, but that might be the issue.

 

 

Have you tested it on several target boards?
Have you followed the circuit design rules on the spi bi-wire lines? If the capacitor is missing then it won't work.

 

A bit more background, this is designed specifically for the tag-connect cables. and this is the first board I have made using these cables/connectors. So I only have 1 target board.

 

Capacitor on the spy-bi-wire? do you mean the 1nF+47k setup on the RST line? I personally have never populated that capacitor, I always thought it was more for stability against accidental resets.

 

 

 

And, I want to say that this is a very cool design idea. I want to see you succeed!

 

Thank you! I want to succeed too

[greeeg 460]

Okay, so after a bit more poking.

 

I found that the FW does use the BSL for it's FW updates, specifically it erases memory location 0xFFFE, then triggers a WDT reset. The MSP thinks it's erased so it runs the BSL.

 

So I now know that the BSL wasn't flashed correctly.

My version of mspdebug 0.22 (from source, but ~2 months old) cannot program the BSL. It reports that it is but the memory doesn't change.

 

I then used TI's MSPflasher 1.3.1 and it worked perfectly. updated the BSL.

 

Now when I connect via mspdebug it asks for a FW update, and actually completes it. I can connect to my target board (MSP430F5513) with no issue.

 

 

I still have a small HW problem. When I connect a target device powered from the FET it hangs while connecting on linux, and disconnects on windows.

My boards need to be updated with a larger capacitance on the VCC rail to support the inrush current of adding a target board.

Or add an extra regulator to provide the ext power.

 

In the meantime It works with powered boards, or if the board is connected before connecting USB.

 

Looks like I have another board spin in the works.

[jazz 209]

I found that the FW does use the BSL for it's FW updates, specifically it erases memory location 0xFFFE, then triggers a WDT reset. The MSP thinks it's erased so it runs the BSL.

 

So I now know that the BSL wasn't flashed correctly.

My version of mspdebug 0.22 (from source, but ~2 months old) cannot program the BSL. It reports that it is but the memory doesn't change.

 

I then used TI's MSPflasher 1.3.1 and it worked perfectly. updated the BSL.

 

Now when I connect via mspdebug it asks for a FW update, and actually completes it. I can connect to my target board (MSP430F5513) with no issue.

 

Yes, for making exact 100% copy of original device (firmware), all memory (including info and BSL) must be copied. In that case everything is clear, without any doubts.

 

I still have a small HW problem. When I connect a target device powered from the FET it hangs while connecting on linux, and disconnects on windows.

My boards need to be updated with a larger capacitance on the VCC rail to support the inrush current of adding a target board.

Or add an extra regulator to provide the ext power.

 

In the meantime It works with powered boards, or if the board is connected before connecting USB.

 

Looks like I have another board spin in the works.

 

Power supply schematic? If 3.3V from internal reg (few mA) of master device is used, than connecting external device while master is working (powered / connected to USB) can cause problems. With external 3.3V reg on FET board, connecting / disconnecting external device should not cause any problems. 

[greeeg 460]

Yes, for making exact 100% copy of original device (firmware), all memory (including info and BSL) must be copied. In that case everything is clear, without any doubts.

 

 

Power supply schematic? If 3.3V from internal reg (few mA) of master device is used, than connecting external device while master is working (powered / connected to USB) can cause problems. With external 3.3V reg on FET board, connecting / disconnecting external device should not cause any problems. 

 

The problem in this case was mspdebug not actually writing to the BSL memory. I had used it to flash TI's EZFET...BSL.txt file, but it hadn't actually overwritten the old BSL.

 

I am powering the whole board from a tiny 3v regulator. Which I believe is the cause. I have ~8uF of capacitance on my 3v rail, which could also be increased. I already added a 4.7uF tantalum cap.

 

This is what happens to the 3 volt rail when I connect a target.

 

The datasheet for the regulator diodes.inc AP130 doesn't show a transient response graph to step changes in current. So I guess it's not a feature they want to showcase. It does recommend 10uF of output capacitance though, which I will try adding.

[Fred 453]

I'm glad to see you got it working. I thought you may have been caught be the same issues I had with a FET430-UIF that I mentioned on the TagConnect thread, but it seems not. I also had issues that when switching between CCS5.5 and CCS6 it always wanted to update the FET firmware. (I was just switching to rule out config issues.) MSPFlasher helped with that as I could at least week what version was on there.

 

Have you gone with the pinout that Spirilis did or will your updated board keep compatibility with the FET430-UIF pinout you get using the TagConnect supplied adapter? I'm struggling to find geek time at the moment, but hope to etch a board to finally double-check my FET430-UIF pinout this week.

[jazz 209]

This is what happens to the 3 volt rail when I connect a target.

NewFile0.png

 

The datasheet for the regulator diodes.inc AP130 doesn't show a transient response graph to step changes in current. So I guess it's not a feature they want to showcase. It does recommend 10uF of output capacitance though, which I will try adding.

 

Well, with debugger don't see advance in possibility of hot-plugging target devices, and for me powering down (unplug USB for target device exchange) is not big minus.

 

For flasher (not debugger) used in production, hot-plugging is big plus.

 

Maybe problem is related to your target board that on connection moment takes to much current, forcing regulator voltage drop. What is behavior of hot-plugging target board to other (not eZ-FET related regulator) 3V supply?

[greeeg 460]

Have you gone with the pinout that Spirilis did or will your updated board keep compatibility with the FET430-UIF pinout you get using the TagConnect supplied adapter? I'm struggling to find geek time at the moment, but hope to etch a board to finally double-check my FET430-UIF pinout this week.

 

I used @@spirilis' personally I don't own a FET430-UIF. I debated buying one when I was using the original launchpad debugger. but the ez-FET is fast and programs every MSP430 chip.

The layout should work perfectly with the FET430-UIF, except you need to power your target board separately. Since the VCC pin that @sprililis used is infact the V_sense line for the FET430-UIF

 

Well, with debugger don't see advance in possibility of hot-plugging target devices, and for me powering down (unplug USB for target device exchange) is not big minus.

 

For flasher (not debugger) used in production, hot-plugging is big plus.

 

Maybe problem is related to your target board that on connection moment takes to much current, forcing regulator voltage drop. What is behavior of hot-plugging target board to other (not eZ-FET related regulator) 3V supply?

 

Finally a use for the uCurrent I bought the other week.

 

Current is yellow, the uCurrent is set to 1mV/mA so the grid is 200mA/div

Voltage is blue, AC coupled.

 

Here is the insertion of a target board using my ez-FET-lite

 

Here is the same board, using the LP5529's 3v3 rail.

 

The 5529LP's power rail is actually a switchmode design, ignoring that you can see that my regulator is to blame. (I've added an extra 10uF of capacitance to the rail now too.)

The 5529LP's actually manages to supply a larger inrush current and yet has a lower voltage drop.

 

I would prefer is the debugger didn't disconnect when I connected a target board, so in the next revision I will be investigating current limiters/better regulators/PTC fuse.

[oPossum 1,083]

Easy fix may be a separate regulator for the target.

[greeeg 460]

Easy fix may be a separate regulator for the target.

That is the method used in the ezFet, and there is a few software stubs that enable/disable power to the target.

 

I might look into a separate rail on the next version. For now this is the solution.

 

A PTC resettable fuse.

I have no idea what rating this fuse has. But it was pulled from an old USB drive, so I'd imagine in the region of 100mA-500mA.

It has a room temperature resistance of 20 ohms. Even a plain old resistor would be enough in this case. But the PTC gives a little more peace of mind.

[Fred 453]

I used @@spirilis' personally I don't own a FET430-UIF. I debated buying one when I was using the original launchpad debugger. but the ez-FET is fast and programs every MSP430 chip.

The layout should work perfectly with the FET430-UIF, except you need to power your target board separately. Since the VCC pin that @sprililis used is infact the V_sense line for the FET430-UIF

tagConnect.PNG

Not quite. In addition to the V sense (i.e. VCC on pin 2 rather than pin 4), SBWTCK should also be pin 3 rather than pin 6. I only mention it as you said there might be a revision of this board. Obviously you can go with whatever pinout you like, but if your design isn't final there's still the option of being compatible with TagConnect's kit.

 

Also just realized I'd forgotten to say what an impressive job you've done of this!

[greeeg 460]

Not quite. In addition to the V sense (i.e. VCC on pin 2 rather than pin 4), SBWTCK should also be pin 3 rather than pin 6. I only mention it as you said there might be a revision of this board. Obviously you can go with whatever pinout you like, but if your design isn't final there's still the option of being compatible with TagConnect's kit.

 

Also just realized I'd forgotten to say what an impressive job you've done of this!

 

Ahh, I only just realized what you were saying about the TCK and TEST pin now. I'll post that stuff in the tagConnect thread though.

 

Long story short, it should be compatible with those SPY-BI-TAG connectors IF you install that 330ohm resistor.

 

I am still investigating the changes I should make to V2 of this board.

Thanks, it wasn't really much work. The FW + schematics were already done by TI.

[mbeals 74]

quick question for you.  I've been comparing schematics and noticed that you have a SBW_NC net (that is in the TI schematic too), but it is not connected to anything.  Is that net really not connected, or am I overlooking something?

[greeeg 460]

quick question for you.  I've been comparing schematics and noticed that you have a SBW_NC net (that is in the TI schematic too), but it is not connected to anything.  Is that net really not connected, or am I overlooking something?

 

You're right it's not needed for programming. I am under the impression it's used / was used for some kind of debugging when TI were designing the eZFET-lite.

 

Only because if you look at the eZFET-lite on the 5529LP, you can see SBW_NC brought out onto the 0.1" header. The target side isn't connected to anything though.

 

I just copied it across when I transposed the schematic, on my board the net doesn't have a trace on the board.