New handheld scope+DMM, Fnirsi 2C23T, 2ch, 10MHz/50MSps (Nov 2023)

[pilatomic]

Hi Dibu,

Sorry I did not answer sooner, I had a business trip this week, only got back a few hours ago.

Simply fixing and compiling the C code obtained from Ghidra does not make it an open source firmware (as it's still Fnirsi's code, hence subject to their licencing)
Depending on your country, doing so might be illegal, as your firmware would surely reuse some of Fnirsi's code.

What is usually done in that case is a clean room design, where one guy writes the documentation about the existing firmware, and another guy writes a new firmware from that documentation.
That avoid any risk of finding code too similar between the 2 firmwares.

[dibu]

The multimeter IC is SDIC SD7502, the ADCs are 3PEAK 3PA1030

[dibu]

Simply fixing and compiling the C code obtained from Ghidra does not make it an open source firmware (as it's still Fnirsi's code, hence subject to their licencing)
Depending on your country, doing so might be illegal, as your firmware would surely reuse some of Fnirsi's code.

Your post gave me a new boost, i have nearly everything decoded now, apart from some floating point stuff for the siggen and font details, but that is not that important anyways. I newer planned to just re-compile the ghidra output and be done with it, ghidra output is not perfect, even less so the original code, I want nothing to do with the original code, i just need it to understand how the hw works.

Now even the lasered chips are identified, maybe the fpga will be a bit tricky with its weird tooling.

There is nothing special about the firmware, there is no secret sauce, no magic, no nothing, pretty basic stuff, i doubt anyone would complain if i reuse "their" put_pixel func. 

[pilatomic]

I am interested to collaborate with you on writing a new firmware.

The hardware isnt perfect but it has potential, at an incredible price and perfect form factor IMHO.

The FPGA bytestream can be used as is, although the device would benefit from having the triggering in the FPGA rather than done in software in the MCU.
(It is pushed at startup by the MCU to the FPGA).

The DMM IC seems to have its own firmware in another EEPROM. There is a "REL" indicator, but it never lights up, and I don't know if the feature is only missing from the MCU, or also not implemented in the DMM IC FW.

Overall, I agree with you, nothing special in that firmware, except for the unusually high amount of bugs !

[dibu]

Nice 

At first fpga could be threated as fixed function hw.
The DMM definitely has its own firmware, ROM might be OTP, I could not find much info on it, this can be used as is, it seems to be good enough.

It seems that the mcu has the lit rel indicator also the code to show it (@0800f83c), i did not check how one is supposed to activate this feature

[dibu]

user manual says rel works only for capacitance, activated with 'save'

When you first check the firmware, before reading the manual  go straight to the source

[pilatomic]

Damn, must have missed that part in the manual.

Anyway, in the idea of laying the groundwork for a custom firmware, I tried to map all the basic HW info to get started.
Here are my notes :

MCU: AT32F403AVGT7
FPGA: AG1KLPQ48
ADCs: 3PEAK 3PA1030
LCD: 320x240, 16bpp, probably ILI9341 based

MCU pinout :
TMR5:
PA0: (TMR5_CH1) LCD Backlight PWM
PA1: (TMR5_CH2) Buzzer

GPIO_config:
PB2: HIGH to keep device on, LOW to turn off
PC11: Unused ?
PA10: CH1 coupling selection (HIGH for DC)
PE0: CH2 coupling selection (HIGH for DC)
PA4: (DAC1_OUT) CH1_Offset
PA4: (DAC2_OUT) CH2_Offset
PC6: Enable DMM IC when HIGH ?
PD3: Key Power
PB9: Key Auto
PB8: Key CH1
PB6: Key F1 (Move)
PB7: Key F2 (Cursor)
PC15: Key Left
PC13 : Key Ok
PE2: Key CH2
PE3: Key Save
PE1: Key F4 (Prm)
PC14: Key F3 (Trigger)
PA3: Key Down
PE6: Key Up
PE5: Key Right
PE4: Key Menu
PC7: Beep from DMM IC when LOW
PB0: Battery charging when LOW

USART3:
PB10: USART3_TX (DMM)
PB1: USART3_RX (DMM)

USART1:
PA9: USART1_TX debug uart

Attenuators:
PA6: CH1 Attenuator
PD2: CH1 Attenuator
PC12: CH1 Attenuator
PA11: CH1 Attenuator
PA7: CH2 Attenuator
PD12: CH2 Attenuator
PD13: CH2 Attenuator
PB1: CH2 Attenuator

FPGA:
PC10:
PC0: FPGA SPI func select 0
PC1: FPGA SPI func select 1
PC2: Some kind of reset / sync ?
PC9: FPGA CRESET_B
PA15: FPGA SPI_SS
PB3: (SPI3) FPGA SPI_SCK
PB4: (SPI3) FPGA SPI_MISO
PB5: (SPI3) FPGA SPI_MOSI
PA8: CLKOUT
PC3:
PC8: FPGA CDONE

SPI2:
PB12: EEPROM_SS
PB13: EEPROM_SCK
PB14: EEPROM_MISO
PB15: EEPROM_MOSI

LCD:
PD6: LCD_RESET ?
PD4: LCD_NOE
PD5: LCD_NWE
PD7: LCD_NE1
PD0: LCD_D2
PD1: LCD_D3
PE7: LCD_D4
PE8: LCD_D5
PE9: LCD_D6
PE10: LCD_D7
PE11: LCD_D8
PE12: LCD_D9
PE13: LCD_D10
PE14: LCD_D11
PE15: LCD_D12
PD8: LCD_D13
PD9: LCD_D14
PD10: LCD_D15
PD12: (A17) : LCD_C/S

ADC:
PA2: ADC for battery voltage

FPGA SPI FUNC SELECTION :
PC0, PC1
0,0 : Unused
0,1 : Scope buffer
1,0 : Timing config
1,1 : Siggen buffer

PC2 set to "1" before sending FPGA a single 0x00 byte, before any other transfer, then set back to 0
also this on timer event after downloading sampling buffer
  GPIO_write_pin(PTR_GPIOC_0800a3bc,GPIO_PIN_0,1);
  GPIO_write_pin(GPIOC,GPIO_PIN_2,1);
  delay_ms(1);
  GPIO_write_pin(GPIOC,GPIO_PIN_2,0);
  GPIO_write_pin(GPIOC,GPIO_PIN_0,0);

[dibu]

based on the init code, i would say that the display controller is ST7789
spi serial flash is 64Mb in my case, but code supports various sizes, only used for screenshots and startup screen

[dibu]

i think making a dumper, that dumps the complete flash (including loader) over uart/vcp would be useful, so jtag could be unlocked and debug capability restored. So a complete flash backup would be available, the firmware file doesn't contain the loader part.

[goldfoxigor7]

Good afternoon, everyone! does Vrms display incorrectly on firmaware 2.0.3 in oscilloscope mode? the mains voltage is actually 230 volts.