Figured this would be of interest to some, I was expecting to see the firmware that this meter came with to be encrypted with at the very least some very basic xor, but turns out the 'EEVBlog.bin' firmware on the SD card is just the plain firmware, with what looks like a calibration file appended to the end of it (cal.dat)
geoff@sarah-xen:~/Projects/121GW$ arm-none-eabi-objdump -D -b binary -marm -Mforce-thumb EEVBlog.bin | head -n 21
EEVBlog.bin: file format binary
Disassembly of section .data:
00000000 <.data>:
0: 4b78 ldr r3, [pc, #480] ; (0x1e4)
2: 2000 movs r0, #0
4: 2879 cmp r0, #121 ; 0x79
6: 0802 lsrs r2, r0, #32
8: 0e35 lsrs r5, r6, #24
a: 0802 lsrs r2, r0, #32
c: 0e37 lsrs r7, r6, #24
e: 0802 lsrs r2, r0, #32
10: 0e39 lsrs r1, r7, #24
12: 0802 lsrs r2, r0, #32
14: 0e3b lsrs r3, r7, #24
16: 0802 lsrs r2, r0, #32
18: 0e3d lsrs r5, r7, #24
1a: 0802 lsrs r2, r0, #32
...
To explain:
0x20004b78 - The main stack pointer
0x08022879 - The reset vector (this is thumb, so the address is actually -1)
... etc
I am yet to look more into this, but it's good news from the point of view of writing custom firmware for the meter.
That is good news!
Since we now have a FW thread, my 121 came with v1.01 and I've seen references to 1.02? Considering the FW resides on the SDcard I guess someone with a 1.02 could post it for us on 1.01 to upgrade.
That is good news!
Since we now have a FW thread, my 121 came with v1.01 and I've seen references to 1.02? Considering the FW resides on the SDcard I guess someone with a 1.02 could post it for us on 1.01 to upgrade.
Indeed, mine has 1.01 on it, it would be interesting to compare the two.
Indeed, mine has 1.01 on it, it would be interesting to compare the two.
I attached version U-1.02 as zip file (at least I hope, since it is from my sd-card).
I suggest not to upgrade from this file. It might contain cal-data only suitable for my meter.
Just use it to compare against your files.
Gnif, from what you currently know, does it look like we can add our own firmware using the existing bootloader and binary update mechanism? In other words, can we load new experimental firmware and easily return to the official firmware?
FYI, as mentioned in another thread, v1.02 has a small bug fix for the calibration SD card import/export feature.
Gnif, from what you currently know, does it look like we can add our own firmware using the existing bootloader and binary update mechanism? In other words, can we load new experimental firmware and easily return to the official firmware?
It seems so, I have been on break though and have not had an opportunity to play more with this yet. If the base address can be figured out there should be nothing stopping custom firmware being flashed into the device, it seems it has a boot loader that then hands over control to the program in ROM, but at this time I can not confirm if this bootloader contains the flash utility.
When I find some more time I will attach to the JTAG port on the STM32 and see what I can do with it, if we get lucky they may have not set the read protection bit and we can dump the entire firmware out. If that doesn't work it shouldn't be hard to compile some code to dump it all out to the SD card or UART, etc...
Note: I am very familiar with the STM32F1xx series chips, they remain my favorite micros, I am excited to see what I can make this meter do.
PS: Thanks for the sticky Dave
It would be very useful for someone to extract the bootloader, as during software development, for speed you'd want to flash the application code directly with a programmer rather than via SD card, but you'd want the ability to put the bootloader back agaon afterwards.
I am just hoping that the IAP Binary update mode (Turn on with HOLD and MEM pressed) is completely in the bootloader. It would make sense for this to be so.
If it is, we should be able to switch between the official firmware and experimental with the need of JTAG.
I am just hoping that the IAP Binary update mode (Turn on with HOLD and MEM pressed) is completely in the bootloader. It would make sense for this to be so.
If it is, we should be able to switch between the official firmware and experimental with the need of JTAG.
Yes, I believe that's how it works. Stock standard ST Micro IAP bootloader (with code to drive the LCD and buttons). I've taken out the SD card during firmware update and it recovers just fine.
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?
Is it possible to put this information into the very first posting of this thread?
Could be helpful finding it more easily imho.
Thanks.
I don't have my meter yet.
I will be in wave 2 of the shipping (March?).
However, I am very interested in following the firmware thread - bookmarked, so to speak.
Dave, could you provide us with the pinout of the jtag connector, so I could try to read out the bootloader and the option byte values with my ST-Link dongle?
I've uploaded the database now. There's a lot more documentation to come too. I will really need y'all's help figuring out the reasoning behind the measurements. If we need to reimplement logging, whatever, but I'd really like to learn how and why the meter e.g. does frequency dependent offset for AC mode. Glance at the
Questions page and see if you can figure something out.
By the way, thank you to GitHub users htro for determining the chip and c-MM for finding the clock crystals (though I have a hunch there's still an oscillator somewhere).
Dave, could you provide us with the pinout of the jtag connector, so I could try to read out the bootloader and the option byte values with my ST-Link dongle?
I'd bet money it's ARM SWD. I don't think these smaller parts use JTAG. The pin list is in the
datasheet somewhere; the meter uses the LQFP144 package. You're looking for SWCLK, SWDIO, NRST, VCC, and GND.
Edit: I know you meant the pin header on the accessible side of the board, but if you have some time this would give the answer without waiting for Dave. Be sure to add it to the wiki!
Reading
(Interesting to see what happens with this meter and what members can do with it. My guess it is going to become a great meter because of the firmware updates
)
Here is the schematic which may help
David2 is working on seeing what we can provide in terms of documentation to help people who want to write their own firmware.
http://www.eevblog.com/files/121GW%20EEVBlog%20Circuit%20diagram.pdf
The CN2 connector seems to be a debug interface for the BLE module.
Can the STM32 update the bluetooth firmware with the serial port ?
I hooked up the 121gw to my st-link and seem to be able to dump the flash.
I also tried to read out the option bytes from the cpu.
I am a backer for the 2nd batch ... and looking forward to the new toy.
I did have some look at the firmware and had it decompiled here:
https://retdec.com/decompilation/I was surprised how easy and straightforward that was. - Of course, the code is not very readable... but in combination with know-how on the hardware, it should be possible to have some improvements.
e.g. finding the function for the buzzer should be quite doable.
I myself could not have a very detailed look yet.
p.s. - perhaps somebody finds the source for this firmware on a USB-stick in the dumpster (next to a 500k$ scope or something ;-)
If so... it would be a very nice move to upload it here...
Edit: if you wanna use the attachments: remove the ".zip" extension from the filenames and process with 7zip. (The forum does not allow bigger files... nor files ending with .7z.001 )
I hooked up the 121gw to my st-link and seem to be able to dump the flash.
Here is the openocd config file I used to dump the data:
# 121gw.cfg openocd config
source [find interface/stlink-v2.cfg]
set WORKAREASIZE 0x4000
source [find target/stm32lx_dual_bank.cfg]
# use software reset
reset_config none
init
reset halt
flash probe 0
Here is how I connected the meter. I didn't use the reset line.
/ 1 Vcc -------- 8 3.3V \
| 2 Reset ------ NC |
121gw - + 3 TMS/SWDIO -- 4 SWDIO + ST-Link-v2 mini
CN3 | 4 TCK/SWCLK -- 2 SWCLK |
\ 5 VSS -------- 6 GND /
This way the meter is powered by the ST-Link and you need to make sure to switch it on or the CPU will be kept in reset mode.
I used the LowZ range, but other ranges will probably work too.
Start openocd with:
sudo openocd -f 121gw.cfg
And the connect to it in another terminal with:
telnet localhost 4444
p.s. - perhaps somebody finds the source for this firmware on a USB-stick in the dumpster (next to a 500k$ scope or something ;-)
If so... it would be a very nice move to upload it here...
If I may toot my own horn a little bit, I'm already ahead of you. If you're interested, check it out
here and feel free to contribute to the wiki.
I hooked up the 121gw to my st-link and seem to be able to dump the flash.
I also tried to read out the option bytes from the cpu.
Thank you so much for both of those (along with the cal data from earlier) and the detailed instructions you provided on doing it yourself. I've added all three things to the GitHub. By the way, your meter has version 1.02, correct? That's what the dump seemed to indicate.
I also tried to read out the option bytes from the cpu.
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.
By the way, your meter has version 1.02, correct? That's what the dump seemed to indicate.
Yes this is correct.
Thank you a lot for your work investigating the firmware! This is very interesting.
I get you are also one of the early backers and you meter is stuck at UEi in the US. If you don't mind a wobbly switch, Dave might be able to poke them a bit to send your meter out early.
Edit:
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.