Reverse engineering FNIRSI-5012H

[maginnovision]

To remove the chip you really can just use an xacto knife with new blade. Hold the chip to the board(if it slides you may pull up pads, especially as fewer pins hold it) while applying downward pressure with a small amount parallel to the plastic package as close to the plastic as possible. You are basically snapping the leads at the package so if a pad lifts it likely wasn't used(95%). Then carefully using some wick(don't slide it until leads are removed) to get the leads off. Go again to clear remaining solder. Then solder new chip. People pull pads up at about the same rate as using hot air the first times. At least from my experience training people.

[GeorgeOfTheJungle]

Well, compiler versions are likely different. ELF files include debug information, so they are going to be different no matter what unless you put your files at exactly the same place as I do. Plus my stuff was build on Linux.

They may use different settings for hex files too. The only thing you can really compare is output of the arm-none-eabi-size command or the size of the raw binary files.

I've updated the msg above, and yep, the .bin file sizes are different too.

[ataradov]

I've updated the msg above, and yep, the .bin file sizes are different too.

Again, differences in compilers will explain this. Also differences in compiler flags.

I have no idea what platform.io is. And I don't want to know. I have a very low tolerance for arduino-style things.

I use a compiler provided by ARM - https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

[GeorgeOfTheJungle]

I have no idea what platform.io is. And I don't want to know. I have a very low tolerance for arduino-style things.

You're an elitist  . But Platformio has nothing to do with Arduino.

I use a compiler provided by ARM - https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm

I'll try to decipher your makefile and make it work with what I have.

I've soldered the new chip already. The most complicated part is to keep it aligned properly for the first solder tack. Once tacked in place, a minimum of solder skills and lots of flux and Bob's your uncle! Some photos:

[GeorgeOfTheJungle]

Code: [Select]

st-info --probe
Found 1 stlink programmers
 serial: 363f71064d56383533070643
openocd: "\x36\x3f\x71\x06\x4d\x56\x38\x35\x33\x07\x06\x43"
  flash: 1048576 (pagesize: 16384)
   sram: 196608
 chipid: 0x0413
  descr: F4 device

st-flash erase
st-flash 1.5.1
2020-02-20T21:14:42 INFO common.c: Loading device parameters....
2020-02-20T21:14:42 INFO common.c: Device connected is: F4 device, id 0x16080413
2020-02-20T21:14:42 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
Mass erasing.

st-flash write open-5012h.bin  0x8000000
st-flash 1.5.1
2020-02-20T20:55:24 INFO usb.c: -- exit_dfu_mode
2020-02-20T20:55:24 INFO common.c: Loading device parameters....
2020-02-20T20:55:24 INFO common.c: Device connected is: F4 device, id 0x16080413
2020-02-20T20:55:24 INFO common.c: SRAM size: 0x30000 bytes (192 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 16384 bytes
2020-02-20T20:55:24 INFO common.c: Attempting to write 34756 (0x87c4) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08008000 erasedEraseFlash - Sector:0x2 Size:0x4000
2020-02-20T20:55:24 INFO common.c: Finished erasing 3 pages of 16384 (0x4000) bytes
2020-02-20T20:55:24 INFO common.c: Starting Flash write for F2/F4/L4
2020-02-20T20:55:24 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 1988
2020-02-20T20:55:25 INFO common.c: Starting verification of write complete
2020-02-20T20:55:26 INFO common.c: Flash written and verified! jolly good!
  The backlight turns on but all I get is a blank screen...

[thinkfat]

If that's openocd being used in the background, it doesn't look like its successfully programmed.
Ah no, it says "verified", it's all good.

[ataradov]

Try to build your own binary and see that you get at least to the LCD backlight. LCD initialization happens after main clock initialization, so some amount of code has run successfully.

If your binary works, then basic debugging is very simple. Just move lcd_set_backlight_level(100); to different points and see where it stops being enabled.

Most likely the reason is the LCD communication. I have not really checked that all the timings are followed correctly. It might be overclocked quite a bit.

As a first step I would look at lcd_data_write() and add a lot more nops there to see if that helps.

[GeorgeOfTheJungle]

Thanks Alex, but I'm a total STM32 noob, and haven't found yet a way to compile that here.

Now I regret two things. 1st I shouldn't have removed the LCD. I think I haven't damaged anything (looks fine with the loupe) but who knows. And 2nd buying the 1024k flash GD32 instead of the same that came with the scope. I hope that's not the problem but again, who knows?

Today I spent all the day making my STLINK V2 clone with a blue pill, and learning to use it. It's been the first time ever I've done an st-info --probe or an st-flash write, or used SWD.

Oh well, tomorrow will be another day.

[ataradov]

Just download the compiler from ARM site I linked. Then run 'make' in the 'make' directory and it should build the image.

Yes, removing of the LCD was not necessary. Double check that you have soldered it back correctly.

The bigger part should not be the problem. I don't see any dependencies in the code on the bigger flash or SRAM size.

[GeorgeOfTheJungle]

I can compile now. Setting up the toolchain was easy, and it just werks To be sure it makes it to the loop, I've put this:

Code: [Select]

  uint32_t ctr= 0;
  int flip_flop= 1;
  while (1)
  {
    timer_task();
    scope_task();
    battery_task();
    buttons_task();
    config_task();
    if (!(++ctr%65536)) {
      lcd_set_backlight_level(flip_flop*100);
      flip_flop= !flip_flop;
    }
  }

And...

fnirsi-not-ok

I'm going to grab the solder and redo that flex :-)

Edit: It werks!

fnirsi-ok

[ataradov]

Awesome! You are the second person in the world to run this firmware.

Also, duckdns.org is blocked by uBlock.

[GeorgeOfTheJungle]

Awesome! You are the second person in the world to run this firmware.

Blocks duckdns? Why? Fuck uBlock... ( use Brave! :-) )

I've been playing with it:

up/down: offset the trace up/down
up+down: reset the trace offset to 0
left/right: move the trigger left/right
left+right: reset trigger to center of screen

TRIG (mode): normal, single, auto
EDGE: up, down, both
trigger up/down: moves trigger level
STOP: run/stop

In stop mode, you can move the trace left/right/up/down, scroll horizontally along the sample memory, AND ZOOM in x and in y !!! It's the dogs bollocks!

AC/DC: ac/dc

NOTE: SHIFT IS 1X10X

shift+up/down: vertical scale 50mV, 100mV, 200mV, 500mV, 1V, 2V, 5V, 10V
shift+left/right: time base 50ns..500ms

MENU: not yet
SAVE: not yet
MODE: not yet
AUTO: not yet
50%: not yet
F1: not yet
F2: while (1) ; :-) (beware!)

Love it! 

[mg3100]

When I first saw the picture that Alex took from the pcb, I noticed that PC3 was connected to Vcc.
I forgot about it until I removed the chip a few days ago. I cut the trace (just in case) before I soldered the new chip back in place.
I removed the chip without removing the board from the case. Just to make sure I did not damage the LCD/cable.

Anybody any idea why it was connected to Vcc because PC3 is nothing special according the GD32 manual?
Maybe they used it to measure Vcc because one of it's alternate functions is ADC123_IN13.

I made a list of all the unused pins and the most useful alternate functions :

7 - PC13   GPIO
8 - PC14   GPIO
15 - PC0   GPIO
16 - PC1   SPI1_MOSI
17 - PC2   SPI1_MISO
(18 - PC3)   SPI2_MOSI
23 - PA0   UART3_TX
24 - PA1   UART3_RX
25 - PA2   USART1_TX
33 - PC4   GPIO
34 - PC5   USART2_RX
37 - PB2   SPI2_MOSI/BOOT1
39 - PE8   GPIO
40 - PE9   GPIO
41 - PE10   GPIO
64 - PC7   SPI1_SCK/Usart5_Rx
65 - PC8   GPIO   
66 - PC9   GPIO
69 - PA10   USB_ID
70 - PA11   USB_DM
71 - PA12   USB_DP

So we have access to UART3, SPI1, an USB port and a couple of GPIO's. That gives us a lot of extra options for this device.
Adding a serial port is easy and I was also thinking about adding a normal usb connector next to the existing one. We have an ID pin so even OTG should be possible. I only wish I had a lot more knowledge about programming USB devices 

[ataradov]

I don't see hoe it can be used to measure VCC. There are no dividers and none of the voltage references are higher than VCC. This may just be some sort of ID pin that their original firmware understands.

There is no real point of having working USB on this device. I see no value it can add.

[GeorgeOfTheJungle]

I didn't notice until it was too late that BOOT1 is connected to GND under the chip, I would have liked to cut that to upload the fw with the serial bootloader (*) because everybody has a working serial port but not everybody has a working SWD hardware and driver.

USB would be a good thing, it can be setup as a CDC serial port or as a mass storage device to download screen captures or remote control or fw updates in dfu mode or whatever, I think.

(*) One of the pins of USART1 is used by a clock of the ADC, but it doesn't matter.

[ataradov]

Yes, cutting BOOT1 pin is a good idea if someone wants to use serial port. But you would need to add external pull-down resistor in that case.

[mg3100]

BOOT1 doesn't have to be cut because it is not used (as you can see in my list).
I think you mean BOOT0 which is indeed connected to GND. I lifted it from the board in my first attempt
to get into the bootloader.

So if we don't need PC3 we can have an extra ADC pin. Now I can add fancy features like autodim display

[ataradov]

Yes, I meant whatever BOOTx pin is a dedicated pin.

[GeorgeOfTheJungle]

BOOT1 doesn't have to be cut because it is not used (as you can see in my list).
I think you mean BOOT0 which is indeed connected to GND. I lifted it from the board in my first attempt
to get into the bootloader.

Oh, sorry. Yeah, BOOT0 :-)

With a bluepill and three resistors you can make an STLINK V2:

Use this circuit but don't use that .bin (it doesn't work!):
https://hackaday.io/project/158262-using-blue-pill-stm32f103c8t6-as-st-link

Use this .bin:
http://e.pavlin.si/wp-content/uploads/2016/02/STLinkV2.J16.S4.bin_.zip
Taken from here:
http://e.pavlin.si/2016/02/28/how-to-program-blank-stm32f1-with-stlink-v2-firmware/

Then probe, erase and flash with st-link:
https://github.com/texane/stlink

Edit: Just in case...

[mg3100]

 

Alex, do you want us to report "white screen of death" events? I did look at the code to find out what the cause might be but there was no comment in the code for the "timer overflow" error.

[ataradov]

Alex, do you want us to report "white screen of death" events? I did look at the code to find out what the cause might be but there was no comment in the code for the "timer overflow" error.

Yes! Especially if you can make a note of what you were doing at a time, or even better can reproduce it reliably.

This error means that something took a long time (> ~0.5 s), but ultimately recovered. I originally assumed that this will never happen in the real life, so there was just a dummy while (1) loop.

It froze on me a couple of times when I had intentional long delays, so I added an error message, so I would not have to guess.

After that I've seen that error only 2 times. And I could not figure out what I was doing at the time  and I could not reproduce it.

If it is really gets in a way, you can safely comment that error out in timer.c, it is mostly harmless, unless it happens a lot.

[robca]

With a blue pill and three resistors you can make an STLINK V2:

At this time, you can buy an STLink clone on eBay for ~$2, same price as a Blue Pill... so, given that anyone who wants to modify this DSO needs to wait for the processors to arrive from China anyway, might as well order an STLink at the same time. There was a time when SWD programmers were expensive, but not anymore...

Granted, if you already have a Blue Pill laying around, might as well do it, but I'd bet that most people who have Blue Pills around very likely also have an STLink also (given that debugging a Blue Pill without STLink is an exercise in frustration)

[mg3100]

@ Alex

It happened twice and both times while I was scrolling through a sample in stop mode but I can't reproduce it (yet).

BTW I had to edit the makefile,

ifeq ($(OS), Windows_NT)
  MKDIR = gmkdir
else
  MKDIR = mkdir
endif

makes windows users call gmkdir   

[ataradov]

This is because normal windows mkdir is stupid and does not understand "-p" switch. This is not ideal, but this is the least offensive solution I found.

[thinkfat]

You do realize that you can source-level debug that thing with the same st-link, gdb and openocd?