| Products > Test Equipment |
| EEVBlog 121GW Multimeter Firmware Details |
| << < (6/62) > >> |
| tpw_rules:
--- Quote from: Iagash on January 25, 2018, 10:59:03 pm --- --- Quote from: Iagash on January 25, 2018, 06:23:34 pm ---I also tried to read out the option bytes from the cpu. --- End quote --- I'm not sure about these if I did it right. I'll look into them tomorrow with the datasheet to see if they make sense. This is my first encounter with STM32, I just used AVRs up to now. I'll have to do a lot of reading. --- End quote --- As far as I can tell, you did. Most of the memory should be 0s as it's not actually mapped to anything. The rest of them are two-byte complement pairs. I didn't actually decode them to see what they mean. Page 73 of the reference manual has all the details. And welcome to ARM! I made that transition a year or so ago and it's great. Everything is more complicated and there's more reading to do, but you get a heck of a lot of cool stuff and power in return. --- Quote from: Iagash on January 25, 2018, 10:59:03 pm ---And also a lot of thanks to Dave and UEi for not setting the readout protection on the STM32! I sincerely hope they don't regret it. --- End quote --- Me too. Thanks also to UEi for not encrypting the firmware and for not using compiler optimizations. That's being extremely nice to hackers :) |
| bicycleguy:
--- Quote from: tpw_rules on January 23, 2018, 03:13:13 am ---I've set up a GitHub repository for future development and information, located here. The wiki on it is free to edit for anyone with a GitHub account. I plan to upload my IDA database tomorrow or so and work on documenting what I've found on the wiki. If you would like to help, please check out the Questions page. I haven't got my meter yet so I can't answer them. I've got pretty much the entire thing documented in terms of variables and functions. Some algorithms I don't know yet and would like help with. But there's a hell of a lot of information we can use to start our own firmware, which I also hope to do on perhaps a bit of a longer timescale. And as I mentioned previously, I have some firmwares edited with bugfixes, if anyone would like to test them out? --- End quote --- Looked at your github and am really amazed at all you have figured out and documented. Looks better documented than most new code! I have a few questions if you don't mind. Most are not about the 121GW but about the process. I've done a lot of micro coding but never decompiling. 1. Looks like C++ because I see the word 'class' around a lot. Is this why you commented 'everything is global' ie. the decompiler put all the class object data in one big pile? 2. Since you have modified firmware already (and tested by Dave somewhere) does that mean you were able to recompile the code. I don't see how that could happen without all the object definitions, headers ect. Could you illuminate further. Is the binary just patched ? I didn't see any C++ code. thanks |
| amspire:
Fantastic, I have just cloned your repository. Ages since I have used a decompiler. Did you rebuild the C++ code from the assembler? That seems to be pretty amazing. |
| tpw_rules:
--- Quote from: bicycleguy on January 28, 2018, 02:43:46 am ---Looked at your github and am really amazed at all you have figured out and documented. Looks better documented than most new code! --- End quote --- Thank you :) I made great use of IDA 6.6 and the Hex-Rays decompiler. It automated all the disassembly and decompilation; my job was going and figuring out what e.g. the function sub_801C504 and variable dword_20003908 did. --- Quote from: bicycleguy on January 28, 2018, 02:43:46 am ---1. Looks like C++ because I see the word 'class' around a lot. Is this why you commented 'everything is global' ie. the decompiler put all the class object data in one big pile? --- End quote --- Um I'm not sure where you've seen the word 'class'. I did a search of the repo and could not find that word anywhere. What I mean by 'everything is global' is that there are several functions (e.g. meas_ohms_calc_50M_offset(digits, factor)) where all the intermediate variables are stored as globals and only read/written in that function. This makes no sense and I'm pretty sure it can't be caused by the compiler. --- Quote from: bicycleguy on January 28, 2018, 02:43:46 am ---2. Since you have modified firmware already (and tested by Dave somewhere) does that mean you were able to recompile the code. I don't see how that could happen without all the object definitions, headers ect. Could you illuminate further. Is the binary just patched ? I didn't see any C++ code. --- End quote --- No, I'm not yet able to recompile the code. I do want to have that available so everyone can play with the firmware, but I haven't taken the time to try it, see what's missing, etc. It's definitely possible, but may be a crazy amount of work. And I still would have no way to test it. For now, I just hand-assembled ARM instructions and patched the binary. It's a lot easier because the compiler wasn't very efficient and so space can easily be made for new code. --- End quote --- is the assembly for the bit I patched, and --- End quote --- is it after the patch. You can see I was able to make more efficient use of registers and fit in an extra test, store, and branch that does if (autorange_changed_range) meter_mode_range_change_delay = 0; |
| tpw_rules:
By the way, Dave, if you're reading this, I sent you a PM a couple days ago? I sent an e-mail to dave@eevblog.com as well. It might have got lost in the shuffle. |
| Navigation |
| Message Index |
| Next page |
| Previous page |