The following image is a piece of disassembled code that was compiled for the MSP430F1611. The code is found in many programs, but in this one it is accidentally vestigial as a result of a compiler bug. Please comment as to (1) which compiler generated the code, (2) what the code was intended to do, and (3) why the code is vestigial in the example, but might not be in another program. Translations to C or psuedocode and commented write-ups are also nice. The MSP430F1xx Family Guide might be handy if you're unfamiliar with the architecture.
I'll send a GoodFET board to the most insightful commentator, but as I send those boards out to anyone who asks, you're really only commenting for the neighborliness of it all. If I get enough replies, I'll post one of these each month.
Also, I saw a lot of good work on last month's Masked ROM Challenge while I was a Cleveland, but next to nothing has been sent my way. If you made significant progress, such as semi-automated extraction of the bits, please email me.
--Travis Goodspeed
<travis at radiantmachines.com>
3 comments:
Hi Travis
The first line just stops the Watchdog.
(cmp r14,r13) and (cmp R15,13) instructions set the zero flag, so (jz $+12) jump instrunctions produce two jumps. After that, the code execution branch to the adress 0x4056.
Best regards
AES
I found the code directly in libgcc.S :
.func _reset_vector__
_reset_vector__:
mov #23168, &288
mov #_etext, r15 ; load r15 with end of .text segment
mov #__data_start, r14 ; load ram start
mov #_edata, r13 ; end of data segment
cmp r14, r13
jeq .Lend_of_data_loop
;; inc r13
.Lcopy_data_loop:
/* copy data from @r15 to @r14 */
mov.b @r15+, @r14 ; move one byte
inc r14
cmp r13, r14 ; check if end of data reached
jlo .Lcopy_data_loop
.Lend_of_data_loop:
mov #__bss_start, r15
mov #__bss_end, r13
cmp r15, r13
jeq .Lend_of_bss_loop
;; inc r13
.Lzero_bss:
clr.b @r15
inc r15
cmp r13, r15 ; check if r15 < r13
jlo .Lzero_bss
.Lend_of_bss_loop:
br #main ; jump to main procedure
.endfunc
It means that:
- you don't use any global initialized variables
- the code is not necessary for your actual firmware
- if you will use some global vars, the code will be ok and working
- msp430 pipeline (if there is any) does not affect the code
Vasek
Both of you are right, but Vaclav's got absolutely everything there is to say about the code. Good job; email me if you'd like a GoodFET, the next revision should be arriving on Thursday.
--Travis
Post a Comment