travisgoodspeed
DEBUG ERROR: Haven't got ASM to flash-pulse SBW.
Hello,
Trying to program a msp430g2553 via sbw, since the bsl pins are a mess if you want to use a normal UART simultaneously...
This is the message I get:
DEBUG ERROR: Haven't got ASM to flash-pulse SBW.
I see there is no code for : //Pulse TCLK //sbw430_tclk_flashpulses(35); //35 standard
Since the TCLK line is the same as SBWTCK, I tried to replace this line by:
//Pulse TCLK jtag430_tclk_flashpulses(35); //35 standard
I have set APP=0x17 and MSP430APP=0x17 in GoodFETMSP430.py to activate SBW
But the goodfet.msp430 dangeroustest fails like this. Any idea? Thanks.
grx@grxmint ~ $ goodfet.msp430 dangeroustest Identified as 89. < -- I added this line as a debug to check that some communication happens. Running an erase/program test. Testing None. Testing RAM from 200 to 210. Failed to write 0xffff to 0x0200 Fault at 000200 Failed to write 0xffff to 0x0201 Fault at 000201 Failed to write 0xffff to 0x0202 Fault at 000202 Failed to write 0xffff to 0x0203 Fault at 000203 Failed to write 0xffff to 0x0204 Fault at 000204 Failed to write 0xffff to 0x0205 Fault at 000205 Failed to write 0xffff to 0x0206 Fault at 000206 Failed to write 0xffff to 0x0207 Fault at 000207 Failed to write 0xffff to 0x0208 Fault at 000208 Failed to write 0xffff to 0x0209 Fault at 000209 Failed to write 0xffff to 0x020a Fault at 00020a Failed to write 0xffff to 0x020b Fault at 00020b Failed to write 0xffff to 0x020c Fault at 00020c Failed to write 0xffff to 0x020d Fault at 00020d Failed to write 0xffff to 0x020e Fault at 00020e Failed to write 0xffff to 0x020f Fault at 00020f Testing identity consistency. Testing flash erase. ffe0 unerased, equals 0000 ffe1 unerased, equals 0000 ffe2 unerased, equals 0000 ffe3 unerased, equals 0000 ffe4 unerased, equals 0000 ffe5 unerased, equals 0000 ffe6 unerased, equals 0000 ffe7 unerased, equals 0000 ffe8 unerased, equals 0000 ffe9 unerased, equals 0000 ffea unerased, equals 0000 ffeb unerased, equals 0000 ffec unerased, equals 0000 ffed unerased, equals 0000 ffee unerased, equals 0000 ffef unerased, equals 0000 fff0 unerased, equals 0000 fff1 unerased, equals 0000 fff2 unerased, equals 0000 fff3 unerased, equals 0000 fff4 unerased, equals 0000 fff5 unerased, equals 0000 fff6 unerased, equals 0000 fff7 unerased, equals 0000 fff8 unerased, equals 0000 fff9 unerased, equals 0000 fffa unerased, equals 0000 fffb unerased, equals 0000 fffc unerased, equals 0000 fffd unerased, equals 0000 fffe unerased, equals 0000 Testing flash write. ffe0 unset, equals 0000 ffe1 unset, equals 0000 ffe2 unset, equals 0000 ffe3 unset, equals 0000 ffe4 unset, equals 0000 ffe5 unset, equals 0000 ffe6 unset, equals 0000 ffe7 unset, equals 0000 ffe8 unset, equals 0000 ffe9 unset, equals 0000 ffea unset, equals 0000 ffeb unset, equals 0000 ffec unset, equals 0000 ffed unset, equals 0000 ffee unset, equals 0000 ffef unset, equals 0000 fff0 unset, equals 0000 fff1 unset, equals 0000 fff2 unset, equals 0000 fff3 unset, equals 0000 fff4 unset, equals 0000 fff5 unset, equals 0000 fff6 unset, equals 0000 fff7 unset, equals 0000 fff8 unset, equals 0000 fff9 unset, equals 0000 fffa unset, equals 0000 fffb unset, equals 0000 fffc unset, equals 0000 fffd unset, equals 0000 fffe unset, equals 0000 Tests complete, erasing.
The pulse timing is really weird and annoying. The idea is that the target chip can be flashed by the host's clock, with pulses coming on the TCK line in 4-wire JTAG. On SBW, the same pulses have to come a lot faster, as all of the data lines are multiplexed over a single wire.
You might get away with pulsing SBWTCK many more than 35 times, but a cleaner way to do this would be to write code into RAM that then flashes data to Flash while running on the internal oscillator. That way, the flashing would not be dependent upon the GoodFET's clock, helping ease the port to @mossmann's GreatFET without breaking backward compatibility.
Example code for flashing the host is unique to each family, but there oughtn't be too many differences between the 1xx, 2xx, and 4xx families.
It is not sufficient to clock SBWTCK. You would loose the 3-slot synchronization.
Instead the internal JTAG TCLK signal is acquired during the TDI slot of the SBW protocol when the TAP state machine is in RESET/IDLE. See http://www.ti.com/lit/ug/slau320t/slau320t.pdf page 17.
And there are special cases to latch the hi-lo transition without moving the tap state machine.
I think I have implemented it right in my fork, but it does not work yet.
The IR is shifted OK, because I get the 0x89 value, and I dont get it when the wiring is wrong.
However I cannot read or write memory, and the device is still identified as 0x0000.
So I have more important issues to tackle before playing with the flash!
