-
Notifications
You must be signed in to change notification settings - Fork 5
TI TXT
Firmware updates to the RF430FRL152H are usually linked into TI-TXT
files, which are supported by most MSP430 toolchains and by srec_cat
.
This is the RF430FRL152H_Default_Project_With_Custom_Command.txt
example from Texas Instruments, which is mostly empty except for
adding a new command handler in the table at FFC0
. It is fairly
typical, and a good representation of the sorts of challenges we face
in OTA programming.
@f867
C7
@fdd0
D2 B3 67 F8 17 20 3C 90 F3 00 14 2C 0A 12 0F 4C
0E 4C 3E 50 00 FA B0 12 CC 5C 0A 4C E2 B3 67 F8
03 20 3A 50 50 F8 02 3C 3A 50 40 F8 5E 43 30 40
4E 54 02 3C 30 40 2C 54 0C 43 30 41 F2 90 03 00
0C 08 11 20 5F 42 06 08 F2 D0 10 00 04 02 4F 93
04 20 F2 F0 EF 00 02 02 03 3C F2 D0 10 00 02 02
C2 43 08 08 02 3C D2 43 08 08 30 41 D2 B3 03 07
07 20 F2 F0 3F 00 02 07 F2 D0 40 00 02 07 03 3C
F2 F0 3F 00 02 07 30 41
@ffc0
CE CE 3C FE 00 16 D0 FD 00 26 0C FE AA 00 CE CE
FF FF FF FF FF FF FF FF
@ffea
B8 5B C0 59 06 5A 8A 48 D0 54 48 5E 2A 5E 76 4E
42 5E 44 5E 12 50
q
Newlines are defined by the standard, but to parse this, it's easiest
to take individual words. q
means to quit, @xxxx
sets the target
address, and xx
is a data byte.
The first write is a single byte to F867
, which is tricky because
this is the system control register, and it's not directly accessible
from outside the chip. So we can't use the default write command, but
there is a secret way to fetch it by writing to block 0x00FF
with
first a password of 0x95, then the byte we intend to write, and six
don't-care byte.
The second write, to FDD0
, is nice and easy, because it is 8-byte
aligned and a multiple of 8 bytes long. In a perfect world, they
would all be so easy, and the patch table at FFC0
is in fact just as
easy.
The final write, to FFEA
, is in a writable region, but it isn't
8-byte aligned or a multiple of 8-bytes long. Further, it overwrites
the IVT, so we are in danger of a bricked device if a write fails in
this region. Writing 0xFFFF
to 0xFFFE
marks the IVT as
untrustworthy, and at the next boot, a clean IVT would be installed by
the mask ROM.
To support small fragments of shellcode, the format has been extended
in our Android app with the x
command to allow the execution of
code. See the Shellcode page of the wiki for more details.