DEBUG ERROR: Haven't got ASM to flash-pulse SBW.

[f4grx]

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.

[travisgoodspeed]

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.

[f4grx]

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!