New bench scope - Fnirsi 1014D, 7", 1GSa/s

[pcprogrammer]

The way I worked with the scope while developing was having the special FEL boot on the SD card and use the sunxi-fel tool to load the fresh build code to test things. This way there is no wear on the SD card and the process has a quick turnaround.

Don't worry about memory. There is 32MB and the code itself is very small. 229KB for the 1013D. It uses a chunk of the memory to store the screen data and buffers for the samples which is less then 4MB. (Did not check the actual amount).

Adding extra code won't make it that much bigger.

In Ghidra it is possible to de-compile to pseudo C, which makes things easier to read. But then still, it takes it's time to become an expert with it.

A simple test you can do is to just setup channel 1 of the clock synth to generate 50MHz and see if the sampling starts to work. I'm quite sure they don't change this clock to adjust the sampling rate simply because the other parts of the FPGA design depend on this clock to be set at a fixed value.

Channel 2 will be a different story.

The pin assignments they did in the 1013D for the touch panel are another example of stupid. There is a two wire interface available on other pins of the MCU they could have used instead of bit banging. The same goes for the 1014D. The swapping of the SDA and SCL pins between the 1014D and 1013D design has to do with UART1.

[pcprogrammer]

Damn you for raising my curiosity 

I did some measurements on the clock signals. As I suspected the main clock input is set at 50MHz and stays fixed on that. The other one varies with frequency settings of the AWG.

The only thing is that I made an error in the schematic. CLK0 (pin 10) is for the AWG and CLK1 (pin 9) is for the main clock.

The relation between the AWG frequency and the clock frequency looks a bit odd. For sine wave at 10MHz the clock is 200MHz and at 9MHz I measured 180MHz, but for 8MHz it went back up to 200MHz, so there is more to it then just controlling this clock. I have to say that I did not do accurate measurements. Just probed the signal with my big scope set to 10ns/div and frequency measurement on between two cursors. Due to DC offset and noise it was not very stable.

It is probably easier to get the information from reverse engineering the code.

I also found that I left my scope in FEL mode. When I booted it to do the measurements it stayed stuck on the boot screen, and both clock signals were off. I removed the SD card and it booted with "SD error" message. Now the clocks were running, both at 50MHz. I got another blank formatted SD card and it booted normally with the main clock at 50MHz and the other one very very low. Turned out the AWG was set to 0.005Hz 

So try to modify the startup of the 1013D code to write settings to the clock IC to set both channels to 50MHz before initializing the FPGA, and see if the sampling starts to work.

[pcprogrammer]

I could not resist to take a peak at the code 

In the Ghidra project there are two versions of the 1014D firmware, and in V3 I named two functions to be for the clock control I2C.

The function more_i2c_stuff_for_fpga_clock takes two parameters, which I named setting1 and setting2.
The function some_i2c_stuff_for_fpga_clock takes one parameter, which is a byte to be send out on the I2C bus.

In the function more_i2c_stuff_for_fpga_clock it first sends 0xC0 followed by setting1 and setting2. Have not hold it against the datasheet of the clock ic.

The other functions in the FPGA init function probably do some calculations on data to come to the setting bytes to be send to the clock ic.

I uploaded a new archive to the repository.

Edit: Renamed the functions and the parameters after looking at the datasheet. Confirmed that the 0xC0 is addressing the ic for write, followed by a register address and the data for it. So the two functions are the low level bit for writing a register in the ic. (Look for fpga_clock_ic in the Ghidra project 1014D_program_V3)

Attached is the Ghidra C output for the two functions.

[donwulff]

Whee, now we're doing duplicate work, like I said I've been looking at Ghidra I was wondering if I should've posted the garbage that it decompiled, haha. But yeah I figured the basics, the actual register files not so much... But after the last post I was reading machine translation of the Chinese datasheet for the clock gen, until I discovered it's all explained in AN619 of the Silicon Labs chip https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/application-notes/AN619.pdf (Is it as simple as PLL 30 x 25 = 750MHz VCO / MS 30 = 50MHz? I'll find out!). Now that I understand the values bit better and know they're not magic, the register settings are starting to make a bit more sense to me. There's also Arduino library https://github.com/etherkit/Si5351Arduino which I'd forgotten about for directly calculating & setting the values dynamically, so could even just use that.

I guess I shouldn't be surprised if the clocks are really distributed that way... There's an odd extra function called for the second clock, but other than that they look pretty symmetrical in code. (Function names random guessed of course).

Code: [Select]

void fpga_init(void)

{
  uint *puVar1;
  uint uVar2;
 
  init_porta_0_1_output();
  uVar2 = DAT_80017534;
  i2c_fpga_clockgen_ch0_reset(DAT_80017534);
  i2c_fpga_clockgen_ch1_reset(uVar2);
  i2c_fpga_clockgen_ch1_set(1);
  puVar1 = DAT_80017538;
  gpio_config_pin(DAT_80017538,9,1);

Which is Ghidra being weird, because yes, both initial functions are called with the same parameter = 02FAF080h.

Then the i2c_fpga_clockgen_ch0_reset() ends in:

Code: [Select]

LAB_80026220:
  if ((uVar3 <= uVar4) && (uVar4 = uVar3, uVar3 < uVar1)) {
    uVar4 = uVar1;
  }
  uVar1 = (uint)((ulonglong)uVar4 * (ulonglong)DAT_800262f8 >> 0x37);
  iVar6 = DAT_800262fc * uVar1;
  uVar5 = FUN_8003bd3c(uVar4 + iVar6 * 0x40,iVar6,DAT_800262fc,
                       (int)((ulonglong)uVar4 * (ulonglong)DAT_800262f8));
  uVar5 = FUN_8003bde8(uVar5,DAT_80026300);
  FUN_8003ba60(uVar5,DAT_80026304);
  uVar5 = FUN_8003bcb8();
  i2c_fpga_clockgen_config_pll(0x1a,uVar1 & 0xff,uVar5,DAT_80026308);
  if (uVar2 < uVar7 - 0x9c4) {
    i2c_fpga_clockgen_config_ms(0x2a,4,0xc);
  }
  else {
    i2c_fpga_clockgen_config_ms(0x2a,unaff_r6,bVar8);
  }
  i2c_fpga_clockgen_reg(0xb1,0x20);
  ptr = DAT_8001e440;
  set_gpio_pin_high(DAT_8001e440,0);
  set_gpio_pin_high(ptr,1);
  set_gpio_pin_low(ptr,0);
  _delay(10);
  set_gpio_pin_low(ptr,1);
  _delay(10);
  _delay(10);
  i2c_fpga_clockgen_chg(0xc0);
  _delay(10);
  i2c_fpga_clockgen_chg(0x10);
  _delay(10);
  i2c_fpga_clockgen_chg(0x4f);
  _delay(10);
  set_gpio_pin_low(ptr,1);
  _delay(10);
  set_gpio_pin_low(ptr,0);
  _delay(10);
  set_gpio_pin_high(ptr,1);
  _delay(10);
  set_gpio_pin_high(ptr,0);
  delay(10);
  return;

So we have a LOT of weird functions (possibly more before that point) with pointers for figuring out the values. We set the PLL divider and then the MultiSynth counters with out magic values. Register 0xb1 = 177 = PLL RESET, specifically PLLA here, which makes the new parameters take force. Then, for who knows what reason, we have the register setting protocol expanded out. Register 0x10 = 16 = CLK0 Control. Maximum 8 mA drive, clock from MultiSynth 0 in "integer mode" to improve jitter.

Of note, none of this is actually going according to either the Silicon Labs or chinese datasheet. They have "disable output, power down output drivers" before divider settings and tell to use 177 = 0xAC to reset PLL.

The second clock is handled in exactly the same way, only the register addresses seem to change for the second clock. But of course THEN we get the i2c_fpga_clockgen_ch1_set() which changes the MultiSynth values based on yet other functions... And looking again, i2c_fpaga_clockgen_ch0_reset is called again in relation to the scope, but I guess i2c_fpaga_clockgen_ch0_reset and i2c_fpaga_clockgen_ch0_set are never called again after initialization.

Unknown function end:

Code: [Select]

  fpga_write_cmd('G');
  fpga_write_data((uchar)((*(ushort *)(iVar2 + 2) - 1) * 0x10000 >> 0x18));
  fpga_write_data(*(char *)(iVar2 + 2) + 0xff);
  uVar13 = DAT_8001c128;
  uVar8 = *(uint *)(iVar2 + 4) * (uint)*(ushort *)(iVar2 + 2);
  if (DAT_8001c124 < uVar8) {
    uVar8 = DAT_8001c124;
  }
  if (*(uint *)(iVar2 + 4) < 10) {
    *(undefined *)(iVar2 + 0xb) = 1;
    if (uVar8 < 0xfa) {
      uVar8 = 0xfa;
    }
    i2c_fpga_clockgen_ch0_reset(uVar8 * 10);
  }
  else {
    *(undefined *)(iVar2 + 0xb) = 0;
    if (uVar8 < uVar13) {
      uVar8 = DAT_8001c128;
    }
    i2c_fpga_clockgen_ch0_reset(uVar8);
  }
  fpga_write_cmd('H');
  fpga_write_data(*(uchar *)(iVar2 + 0xb));
  if (*(int *)(iVar2 + 4) == 0) {
    fpga_write_cmd('F');
    uVar13 = 0;
    do {
      fpga_write_data('c');
      uVar13 = uVar13 + 1 & 0xfffeffff;
    } while (uVar13 < 1000);
    return;
  }
  fpga_write_cmd('F');
  uVar13 = 0;
  do {
    fpga_write_data(pbVar3[uVar13]);
    uVar13 = uVar13 + 1 & 0xfffeffff;
  } while (uVar13 < 1000);
  return;

None of those FPGA commands are in the https://github.com/pecostm32/FNIRSI-1013D-1014D-Hack/blob/main/FPGA%20explained/FPGA%20explained.txt document, so that's some more reverse engineering along with trying to find out what it does to the clock gen. And whoops, just re-read what you said with thought, so this must be for the clock-gen whereas the other, fixed output with extra function is indeed for the oscilloscope. No wonder I was thinking it was being changed!

It seems like I might need a crash-course in Ghidra. I'm going to try to solve these BEFORE posting, though

EDIT: Oh yeah, also want to use FEL for all the reasons, but as complained before, libusb doesn't really work over Microsoft RDP RemoteFX USB pass-through. Or it does, if the USB device is part of a composite device and the software looks for that device directly and not the composite device... but yeah, let's just say it doesn't work until fixed.

EDITn: Yes I also looked at how the Sipeed Lichee Nano with F1C100s has 16MB flash, so I guess the 1MB set aside for firmware on the SD-card is just a matter of choice and guessing it won't grow above that. It would also theoretically be possible to load different modules from SD into memory?

Si5351A ClockBuilder Pro lets me choose 200MHz + 50MHz clock even though I guess it's way beyond spec (actually looks like it's in, but needs special settings). So this is something like what I should be looking for in the code. I wonder why there's so many functions & apparent dynamicity to the setting in FNIRSI, just stupid choice/ready-made library I guess? Also note you can write i2c in consequential manner, even according to the Chinese clone datasheet, no need to give write & register address for each. And most registers default to 0x00 value after reset, so those register writes can generally be ignored (unless needed to cover a gap in the register sequence), but that's on ClockBuilder Pro.

Also, this dump shows I still really don't understand the register configuration. The math of "Fvco = 32 x 25MHz = 800MHz, CLK0 divider 4 = 200MHz, CLK1 divider 16 = 50MHz" is just as I'd expect, then in the register file... 0x00E00. WTAF

Code: [Select]

/*
 * Si5351A Rev B Configuration Register Export Header File
 *
 * This file represents a series of Skyworks Si5351A Rev B
 * register writes that can be performed to load a single configuration
 * on a device. It was created by a Skyworks ClockBuilder Pro
 * export tool.
 *
 * Part:                                        Si5351A Rev B
 * Design ID:                                         
 * Includes Pre/Post Download Control Register Writes: Yes
 * Created By:                                         ClockBuilder Pro v4.7 [2022-11-18]
 * Timestamp:                                          2023-01-06 18:41:46 GMT+02:00
 *
 * A complete design report corresponding to this export is included at the end
 * of this header file.
 *
 */

#ifndef SI5351A_REVB_REG_CONFIG_HEADER
#define SI5351A_REVB_REG_CONFIG_HEADER

#define SI5351A_REVB_REG_CONFIG_NUM_REGS 53

typedef struct
{
unsigned int address; /* 16-bit register address */
unsigned char value; /* 8-bit register data */

} si5351a_revb_register_t;

si5351a_revb_register_t const si5351a_revb_registers[SI5351A_REVB_REG_CONFIG_NUM_REGS] =
{
{ 0x0002, 0x53 },
{ 0x0003, 0x00 },
{ 0x0004, 0x20 },
{ 0x0007, 0x00 },
{ 0x000F, 0x00 },
{ 0x0010, 0x4F },
{ 0x0011, 0x0F },
{ 0x0012, 0x8C },
{ 0x0013, 0x8C },
{ 0x0014, 0x8C },
{ 0x0015, 0x8C },
{ 0x0016, 0x8C },
{ 0x0017, 0x8C },
{ 0x0018, 0x0A },
{ 0x001A, 0x00 },
{ 0x001B, 0x01 },
{ 0x001C, 0x00 },
{ 0x001D, 0x0E },
{ 0x001E, 0x00 },
{ 0x001F, 0x00 },
{ 0x0020, 0x00 },
{ 0x0021, 0x00 },
{ 0x002A, 0x00 },
{ 0x002B, 0x01 },
{ 0x002C, 0x0C },
{ 0x002D, 0x00 },
{ 0x002E, 0x00 },
{ 0x002F, 0x00 },
{ 0x0030, 0x00 },
{ 0x0031, 0x00 },
{ 0x0032, 0x00 },
{ 0x0033, 0x01 },
{ 0x0034, 0x00 },
{ 0x0035, 0x06 },
{ 0x0036, 0x00 },
{ 0x0037, 0x00 },
{ 0x0038, 0x00 },
{ 0x0039, 0x00 },
{ 0x005A, 0x00 },
{ 0x005B, 0x00 },
{ 0x0095, 0x00 },
{ 0x0096, 0x00 },
{ 0x0097, 0x00 },
{ 0x0098, 0x00 },
{ 0x0099, 0x00 },
{ 0x009A, 0x00 },
{ 0x009B, 0x00 },
{ 0x00A2, 0x00 },
{ 0x00A3, 0x00 },
{ 0x00A4, 0x00 },
{ 0x00A5, 0x00 },
{ 0x00A6, 0x00 },
{ 0x00B7, 0x92 },

};

/*
 * Design Report
 *
 * Overview
 * ========
 * Part:               Si5351A
 * Created By:         ClockBuilder Pro v4.7 [2022-11-18]
 * Timestamp:          2023-01-06 18:41:46 GMT+02:00
 *
 * Design Rule Check
 * =================
 * Errors:
 * - No errors
 *
 * Warnings:
 * - No warnings
 *
 * Design
 * ======
 * I2C Address: 0x60
 *
 * Inputs:
 *     IN0: 25 MHz
 *
 * Outputs:
 *    OUT0: 200 MHz
 *          Enabled LVCMOS 8 mA
 *          Offset 0.000 s
 *    OUT1: 50 MHz
 *          Enabled LVCMOS 8 mA
 *          Offset 0.000 s
 *    OUT2: Unused
 *
 * Frequency Plan
 * ==============
 * PLL_A:
 *    Enabled Features = None
 *    Fvco             = 800 MHz
 *    M                = 32
 *    Input0:
 *       Source           = Crystal
 *       Source Frequency = 25 MHz
 *       Fpfd             = 25 MHz
 *       Load Capacitance = Load_08pF
 *    Output0:
 *       Features       = None
 *       Disabled State = HiZ
 *       R              = 1  (2^0)
 *       Fout           = 200 MHz
 *       N              = 4
 *    Output1:
 *       Features       = None
 *       Disabled State = HiZ
 *       R              = 1  (2^0)
 *       Fout           = 50 MHz
 *       N              = 16
 *
 * Settings
 * ========
 *
 * Location      Setting Name    Decimal Value      Hex Value       
 * ------------  --------------  -----------------  -----------------
 * 0x0002[3]     XO_LOS_MASK     0                  0x0             
 * 0x0002[4]     CLK_LOS_MASK    1                  0x1             
 * 0x0002[5]     LOL_A_MASK      0                  0x0             
 * 0x0002[6]     LOL_B_MASK      1                  0x1             
 * 0x0002[7]     SYS_INIT_MASK   0                  0x0             
 * 0x0003[7:0]   CLK_OEB         0                  0x00             
 * 0x0004[4]     DIS_RESET_LOLA  0                  0x0             
 * 0x0004[5]     DIS_RESET_LOLB  1                  0x1             
 * 0x0007[7:4]   I2C_ADDR_CTRL   0                  0x0             
 * 0x000F[2]     PLLA_SRC        0                  0x0             
 * 0x000F[3]     PLLB_SRC        0                  0x0             
 * 0x000F[4]     PLLA_INSELB     0                  0x0             
 * 0x000F[5]     PLLB_INSELB     0                  0x0             
 * 0x000F[7:6]   CLKIN_DIV       0                  0x0             
 * 0x0010[1:0]   CLK0_IDRV       3                  0x3             
 * 0x0010[3:2]   CLK0_SRC        3                  0x3             
 * 0x0010[4]     CLK0_INV        0                  0x0             
 * 0x0010[5]     MS0_SRC         0                  0x0             
 * 0x0010[6]     MS0_INT         1                  0x1             
 * 0x0010[7]     CLK0_PDN        0                  0x0             
 * 0x0011[1:0]   CLK1_IDRV       3                  0x3             
 * 0x0011[3:2]   CLK1_SRC        3                  0x3             
 * 0x0011[4]     CLK1_INV        0                  0x0             
 * 0x0011[5]     MS1_SRC         0                  0x0             
 * 0x0011[6]     MS1_INT         0                  0x0             
 * 0x0011[7]     CLK1_PDN        0                  0x0             
 * 0x0012[1:0]   CLK2_IDRV       0                  0x0             
 * 0x0012[3:2]   CLK2_SRC        3                  0x3             
 * 0x0012[4]     CLK2_INV        0                  0x0             
 * 0x0012[5]     MS2_SRC         0                  0x0             
 * 0x0012[6]     MS2_INT         0                  0x0             
 * 0x0012[7]     CLK2_PDN        1                  0x1             
 * 0x0013[1:0]   CLK3_IDRV       0                  0x0             
 * 0x0013[3:2]   CLK3_SRC        3                  0x3             
 * 0x0013[4]     CLK3_INV        0                  0x0             
 * 0x0013[5]     MS3_SRC         0                  0x0             
 * 0x0013[6]     MS3_INT         0                  0x0             
 * 0x0013[7]     CLK3_PDN        1                  0x1             
 * 0x0014[1:0]   CLK4_IDRV       0                  0x0             
 * 0x0014[3:2]   CLK4_SRC        3                  0x3             
 * 0x0014[4]     CLK4_INV        0                  0x0             
 * 0x0014[5]     MS4_SRC         0                  0x0             
 * 0x0014[6]     MS4_INT         0                  0x0             
 * 0x0014[7]     CLK4_PDN        1                  0x1             
 * 0x0015[1:0]   CLK5_IDRV       0                  0x0             
 * 0x0015[3:2]   CLK5_SRC        3                  0x3             
 * 0x0015[4]     CLK5_INV        0                  0x0             
 * 0x0015[5]     MS5_SRC         0                  0x0             
 * 0x0015[6]     MS5_INT         0                  0x0             
 * 0x0015[7]     CLK5_PDN        1                  0x1             
 * 0x0016[1:0]   CLK6_IDRV       0                  0x0             
 * 0x0016[3:2]   CLK6_SRC        3                  0x3             
 * 0x0016[4]     CLK6_INV        0                  0x0             
 * 0x0016[5]     MS6_SRC         0                  0x0             
 * 0x0016[6]     FBA_INT         0                  0x0             
 * 0x0016[7]     CLK6_PDN        1                  0x1             
 * 0x0017[1:0]   CLK7_IDRV       0                  0x0             
 * 0x0017[3:2]   CLK7_SRC        3                  0x3             
 * 0x0017[4]     CLK7_INV        0                  0x0             
 * 0x0017[5]     MS7_SRC         0                  0x0             
 * 0x0017[6]     FBB_INT         0                  0x0             
 * 0x0017[7]     CLK7_PDN        1                  0x1             
 * 0x0018[1:0]   CLK0_DIS_STATE  2                  0x2             
 * 0x0018[3:2]   CLK1_DIS_STATE  2                  0x2             
 * 0x001C[17:0]  MSNA_P1         3584               0x00E00         
 * 0x001F[19:0]  MSNA_P2         0                  0x00000         
 * 0x001F[23:4]  MSNA_P3         1                  0x00001         
 * 0x002C[17:0]  MS0_P1          0                  0x00000         
 * 0x002C[2]     MS0_DIVBY4_0    1                  0x1             
 * 0x002C[3]     MS0_DIVBY4_1    1                  0x1             
 * 0x002F[19:0]  MS0_P2          0                  0x00000         
 * 0x002F[23:4]  MS0_P4          1                  0x00001         
 * 0x0034[17:0]  MS1_P1          1536               0x00600         
 * 0x0037[19:0]  MS1_P2          0                  0x00000         
 * 0x0037[23:4]  MS1_P4          1                  0x00001         
 * 0x005A[7:0]   MS6_P2          0                  0x00             
 * 0x005B[7:0]   MS7_P2          0                  0x00             
 * 0x0095[14:0]  SSDN_P2         0                  0x0000           
 * 0x0095[7]     SSC_EN          0                  0x0             
 * 0x0097[14:0]  SSDN_P3         0                  0x0000           
 * 0x0097[7]     SSC_MODE        0                  0x0             
 * 0x0099[11:0]  SSDN_P1         0                  0x000           
 * 0x009A[15:4]  SSUDP           0                  0x000           
 * 0x00A2[21:0]  VCXO_PARAM      0                  0x000000         
 * 0x00A5[7:0]   CLK0_PHOFF      0                  0x00             
 * 0x00A6[7:0]   CLK1_PHOFF      0                  0x00             
 * 0x00B7[7:6]   XTAL_CL         2                  0x2
 *
 *
 */

#endif

[pcprogrammer]

Haha, I only looked at the lowest level of the code because I had already found those two functions before, but did not checked the parameters. I stopped after verifying that it was indeed addressing the clock chip.

Looked at the programming of the clock ic just a little bit and decided it was up to you to dig further, which you did 

I uploaded the stuff I created in regards with the 1014D FPGA to the reversal repository.

The commands in the  0x4X range are indeed unknown to me and chances are they have to do with the AWG. The clock synthesizer CLK0 output is the variable one. CLK1 is fixed on 50MHz, so verify that your findings match with this.

The command 0x46 ('F') looks like the one for loading the waveform memory. It loops to write a 1000 bytes to the FPGA, which more or less matches the 1KB I found available for it in the FPGA reversal.

Based on the measurements I did, I guess that with one of the other commands they set a clock divider and maybe a range of samples to use.

[pcprogrammer]

EDITn: Yes I also looked at how the Sipeed Lichee Nano with F1C100s has 16MB flash, so I guess the 1MB set aside for firmware on the SD-card is just a matter of choice and guessing it won't grow above that. It would also theoretically be possible to load different modules from SD into memory?

The 1MB is what most SD cards have with default formatting, and it still allows for growth of the firmware.

It would also theoretically be possible to load different modules from SD into memory?

Yes, that is basically how linux does it. You could load some files on the SD card and have the basic part of the firmware read them into memory and jump into that code.

Si5351A ClockBuilder Pro lets me choose 200MHz + 50MHz clock even though I guess it's way beyond spec. So this is something like what I should be looking for in the code. I wonder why there's so many functions & apparent dynamicity to the setting in FNIRSI, just stupid choice/ready-made library I guess? Also note you can write i2c in consequential manner, even according to the Chinese clone datasheet, no need to give write & register address for each.

Programming does not seem to be their forte 
I have found many stupid things in the 1013D code, for which I doubt ready made libraries were used. Like you wrote it is possible to send data for sequential registers in a single write action. Would mean a bit of a speed up, but does not really matter here though.

My code is a bit of a mess due to the way it all came together and could do with cleanup, restructuring and some bug fixing though.

[donwulff]

Edits galore in the above clock gen configuration post as I keep researching more. I still don't fully understand the register configuration, though I can at least see what the FNIRSI code is trying to do - although it seems at least for the scope part they could indeed do with just a couple of mostly sequential writes, for a code that'd be a pleasure to decompile with Ghidra But I suppose I can just dump the ClockBuilder Pro register file into i2c and hope for the best. Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming. But before that, some emergency work

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  7988MB  7988MB  primary  fat32        lba

Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway?

[pcprogrammer]

Meanwhile I'll have a look at the serial configuration, and see if I can't just print the bytes on display or something so I can simplify the in-system programming.

That is a good idea. Should have thought of it myself 

I have used writing to file to capture al sorts of data during the reverse engineering and development, but also wrote stuff on the screen.

You can make a copy of the firmware backup project and use it to show the serial data. It has all but the serial part in it. Write to file can be done and the display lib is there to do the displaying on screen.

But before that, some emergency work

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  7988MB  7988MB  primary  fat32        lba

Let's just blame FNIRSI shall we, what kind of flash alignment is that anyway?

Is that how the original card was done? I have also had something like that before, that I had to reformat the card to make space for the firmware. Might well have been the one of the 1014D.

[donwulff]

To the credit of pcprogrammer's original code (and schematics), configuring ClockGen over I2C using modified (8 bit address, different pins etc.) code worked fine first try. Only I did a classical copy & paste error, disabling the second clock output when I meant third, leading to some lengthy debugging... After finding that, there's now nice, almost flat scope traces (X1 20uS not so useful though!). The 200MHz is attenuated sine-wave even on my 2.5Gs/s Fluke Scopemeter 225C, but that's to be expected.

The clock generator configuration itself has a few oddities. The Chinese chip seems to be based on the Rev B chip, which goes up to 200MHz, and has datasheet and register description split apart: https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/application-notes/AN619.pdf

However, the ClockBuilder Pro generated register map writes to two registers marked as "Reserved" even in that. The generated dump names them "DIS_RESET_LOLB" (Disable something reset Loss of Lock PLL B? But this doesn't use PLL B) and I2C_ADDR_CTRL - I left both alone for now).

For the 50MHz out, the divider from 800MHz fVCO needs to be 32. That seems like an even integer to me, but the generated register map leaves MS1_INT as 0. Time to try what happens if I set it to 1. The ClockBuilder Pro logic seems indecipherable as it's even relying on the Reserved registers. There's the additional thing that I will most likely have to switch to use different PLL's for each clock, as it sounds the 200MHz clock may need more fine-tuning, which at >112.5 MHz can only be done by adjusting the PLL fVCO multiplier.

From what I can see, the original firmware leaves XTAL Crystal Load capacitance at default 10 pF. I have no idea which crystal the 1014D uses, but looking at available crystals, the vast majority of 25MHz crystals come with load capacitance of 8 pF, and the leads and pins will provide a bit of stray capacitance. AN619 specifies "crystal load capacitance" though, so maybe this should be 8 pF, but default 10 pF seems to just work.

And yes, the original 1014D SD-card had that wacky 32.3kB partition start. I guess making it small would make sense on a really small SD, the documents I think talk about 1G one, but you'd definitely want it aligned to some suitable power of two...

On towards the knob controller interface, though I'll probably stop updating on every small change. I'll stick them on GitHub when I have something useful, though I'm not using NetBeans (or some derived IDE?), and not sure how much it'd be worth it to combine the code. I'll see how much changes I'll have to do the the UI inputs; it might even be mostly just renaming the touchscreen functions to something interface-agnostic.

[pcprogrammer]

Well that is good news.

Yep 200MHz square wave needs a scope with a very high bandwidth to show it as square. My 500MHz Yokogawa DL9705L shows a sine too.

About the crystal, if it works it works, I would say.

Netbeans is just the IDE I'm using. Has no impact on the code. Just add a new directory to your fork of the repository and stick your work in it as a backup. When you have something that is usable as new firmware, I would suggest to make a new repository for it and stick it in there. You can also design your own splash screen    (Or make it work without it)

The touch handling in the firmware is based on detection of touch in one of the defined buttons or dedicated areas, and if it is a menu it will open that menu and use dedicated functions to handle the touch in that. It might not be easy to connect this to the input from the user interface controller. But everything for this is found in the "statemachine" and "scope_functions" files.

[pcprogrammer]

A pointer on something that is different between the 1013D and 1014D is the screen brightness setting in the FPGA. It uses the same command 0x38, but it takes only one byte as setting. 0x78 is full on. Have not looked at the settable range, so needs some experimentation.

Is simple to modify in the "fpga_control.c" file. Look at functions "fpga_set_translated_brightness" and "fpga_set_backlight_brightness".

[donwulff]

The touch handling in the firmware is based on detection of touch in one of the defined buttons or dedicated areas, and if it is a menu it will open that menu and use dedicated functions to handle the touch in that. It might not be easy to connect this to the input from the user interface controller. But everything for this is found in the "statemachine" and "scope_functions" files.

Yeah, touch is by necessity "modal" whereas the buttons are more global in nature. It bugs me because I wouldn't want to re-write the whole UI and then people would have to keep both implementations in synch. Maybe some event-driven model.

Did the same copy-paste (of my own code/defines) error for the serial port, making both Divisor Latch LSB/MSB register same, then writing 0 to MSB...  Something else that was different for 1014D, at least to your custom firmware, is the 1014D stock firmware sets the MCU clock to 576 MHz. This means the Divisor Latch is 4% too large for the 600 MHz clock. With those fixed I got the key values easy, so now I can start raking my head for the way to combine touch & buttons in meaningful way. It sends 0xff to the knob-processor before each read, which I guess works as rudimentary flow-control if it responds only when it receives 0xff. I haven't looked if there's a buffer beyond the FIFO on that side though. But at least all the pieces for programming it are there now.

The "PECOS SCOPE" load-screen is flashing in a weird way, I wonder if that is related to the brightness setting. The main scope screen is fine though, so that's not a problem. Because the speed of booting is one of the strengths of the scope, it might be skipped anyway.

Code: [Select]

1 RUN/STOP
2 AUTO
3 MENU
4 S PIC
5 S WAV
6 H CUR
7 V CUR
8 >
9 ^
10 OK
11 v
12 <
13 SLOW
14 CH1
15 CONF (CH1)
16 CH2
17 CONF (CH2)
18 ORIG
19 MODE
20 EDGE
21 CHX
22 50%
23 F1
24 F2
25 F3
26 F4
27 F5
28 F6
29 GEN
30 NEXT
31 LAST
32 DEL
33 SEE ALL
34 SEL
35 + SEL
36 - SEL
37 + POS (CH1)
38 - POS (CH1)
39 + POS (CH2)
40 - POS (CH2)
41 - POS (ORIG)
42 + POS (ORIG)
43 + LEVEL
44 - LEVEL

49 ON
200 OFF

[pcprogrammer]

The "PECOS SCOPE" load-screen is flashing in a weird way, I wonder if that is related to the brightness setting. The main scope screen is fine though, so that's not a problem. Because the speed of booting is one of the strengths of the scope, it might be skipped anyway.

Yes, that has to do with the brightness setting. By modifying the load screen code to just write 0x38 and then 0x78 to the FPGA instead of 0x38, 0xEA, 0x60 (if not mistaken out the top of my head) it will stop the flickering.

Had the same issue with the firmware backup program.

Good work on getting the commands send from the user interface controller. I wonder why they set the F1C100s to a lower clock then the 1013D. Will be fun to see the 1013D firmware working on the 1014D, but modifying the screen setup might be needed to deal with the function buttons on the right of the screen.

Edit: And there is the AWG of course. There in lies a lot of fun stuff to do, like sweeping to measure filter response.

[pcprogrammer]

I checked the command list with the front panel of my scope, and noticed the three bigger knobs are missing from it.

The channel sensitivities and the time base time per division selector.

The gap between - level and on is not large enough to fit them all, so do they have another set between on and off?

[donwulff]

Oh dang, they don't have label so I missed them.
45 - X CH1
46 + X CH1
47 - Y CH2
48 + Y CH2
49 - GEN (TIME)
50 + GEN (TIME)

The 49 is actually an error, it seems to report random/last encoder position on boot, which will be annoying. Could be sort of weird to have separate code for that, as the scope doesn't technically "see" it, and is physically same button. 200 does show up for the POWER button when it's running (and shuts down about a second after).

I have the plastic knobs off because I'm intending to check under the tin-cans, although AliExpress is having delays even mailing the KAQY214(S) chips, so will be a while until I'll be able to try anything with that... should probably put it back together before I break something.

And yes the AWG is still kind of open book, the scope will work without it though. But I hope I'll be able to find time to play with the AWG/mods and even FPGA. First step is getting it usable with the custom firmware though.

[donwulff]

Various issues, I'm not sure if I'm supposed to ask or just test & debug  Is there easier way to debug the AllWinner chip than just printing out debugs into file/screen?

Sometimes the traces don't come up right on startup (I'll check the initialization order/clocks and also need to get most of the settings bound to buttons so I can see if they still work)

scope_setup_usb_screen() it takes really long for the disk to become accessible (sometimes it fails entirely).

settings the trigger mode makes the scope hang. (Interesting, it runs through the set-up commands but just stops responding after that, need to see if there's some mode-specific code)

Auto setting doesn't really set up triggers or anything, just timescale and voltage I guess (I guess first step is checking if it should, actually I think the trigger isn't displaying correctly).


Well, nobody said it was gonna be easy Just in case there's anything known I need to take into account, though.

I needed some other components too so I went ahead and ordered the scope components from DigiKey as well (Took their last OpAmps, mwahahaa, and they don't have the Chinese KAQY214S's which claim lower on-resistance, just the Philips ones) and checked under the cans to verify I have the same OpAmp as everybody else. Too old to be soldering that fine components though, but I might try! And 125MHz frequency (250MSa/s ) seems to work, although whether it makes any sense will require getting some readings & higher bandwidth.

[pcprogrammer]

For as far as I know it does not have proper debug support, at least nothing that is documented. Have not looked in the ARM documentation if there could be something for it, but if it is there it would require code to work with it I suppose. There are no external connections for it like on newer ARM devices like the STM32 where you have SWD.

About the traces, I vaguely recall an extra FPGA command being used, so it might be needing it at some point. You can search for the fpga_write_cmd function in Ghidra, to see which commands are being send from where in the code.

Strange that the USB code is giving problems. Have not received any feedback on problems with it in the 1013D. With the code on the 1013D and linux mint that I'm using it worked every time I tested it. As a matter of fact, it is also used in the firmware backup code and did not see problems on the 1014D with it either.

It might be that the trigger part is where the 1014D FPGA differs, and needs something extra to make it work.

There is some report about a problem with the auto set function on the 1013D, and it might well be what you are writing about. I'm not sure but believe I set the trigger to 50% when auto set is used.

Indeed nobody will say it is easy, because if it was easy everybody would be doing it 

You state the 125MHz ADC clocking to be working, but how did you achieve that? Did you raise the FPGA main clock from 50MHz to 62.5MHz?

This might cause the timing to fail and result in problems in the data. It will also change the 1KHz calibration signal and the screen brightness control signal frequency, and all the rest that is derived from the main clock.

[donwulff]

It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.

EDIT: Then again, I didn't check into the MCU data acquisition path, maybe the ADC is starting to shift levels & FPGA commands fail at the same time, but the most parsimonious explanation is the FPGA is just hitting its limit.

The mounting delay may be Windows filesystem check because I'm just calling the USB disk function which expects touchscreen to terminate, time to fix that next.

And yeah the trigger mode-setting code seems to go through without hanging, and doesn't hang afterwards either unless the mode is actually changed. It's waiting for trigger indefinitely, isn't it?

Some interesting issues popping up, but yeah I don't have 1013D to test if they happen on it as well, and in some cases I may just be using the existing code wrong. But I'm making progress getting it responsive.

[pcprogrammer]

It seems I can hit 300 MSa/s with the FPGA clock (75 MHz) before the FPGA starts flipping out, that's not to say the ADC or bandwidth can follow, in fact I'm quite sure they don't, but it *looks* like it's working, including measuring correct waveforms I'm running most of the testing with stock 50 MHz clock, it makes no difference, just wanted to see how far the FPGA fabric/ADC can go right off.

The sampling frequency depends on the time per div setting. To do the maximum possible the software needs to be set to 200MSa/s which is the case when time per div is 20ns or 10ns per division.

But not bad that it works with 75MHz main clock.

Since I have both I can do some tests and compare between the two of them. Just write up what to test and make the code available.

[donwulff]

I pushed current work at https://github.com/Donwulff/FNIRSI_1014D_Firmware/tree/PORT_A - it's not at all useful yet, other than getting to experiment with things a bit. (Yeah, I stuck everything into port_a module, and edited the NetBeant Debug makefile directly so NB will overwrite it and miss the new module). I have to focus on other things, and keep breaking the source, so better for me to save a copy now

Also a size comparison of Philips AQY214EHAX SSR relay. SMD model here is larger than the S model, but it could work as the other end isn't over the rest of the components. Cooking components will take a while to arrive, so may look at on resistance then, and possibly circuit simulation.

[pcprogrammer]

Top. I will take a look to see what you have been up to 

About the relays, if they had only looked a bit beyond the length of their nose and used a high speed 4051 analog multiplexer it would have been easy to have more ranges then they have now. The 3 control lines for the relays are unfortunately limited in the FPGA to the allowed range it has now, instead of having the limit in software, otherwise it would have been easier to make the change.

[donwulff]

I should have a look at that multiplexer, though the idea here is just to use the SSR to bypass the front resistor, which according to simulations is filtering the bandwidth... Because of that the on-resistance of the optoisolated SSR relay is pretty crucial, in fact if FNIRSI/whoever didn't account for it correctly, the one bypassing the AC coupling capacitor could be limiting the bandwidth further than they meant. (Also, we have to use optoisolated one there, because it's on the high-voltage size of the front-end). Once again though I'm aware that's not magic, for one thing that will cause higher frequencies to alias into lower ones due to the sample rate, however I want to test oveclocking the FPGA/ADC as well as potential for just getting phase of (known) higher frequency signals. That MAY require switching the OpAmp into the Texas Instruments one, with faster slew rate, and yeah that component's small too...

In the pic the SSR is placed with legs right around the resistor it's supposed to bypass... which I should note, is really small, and I'm not at all confident about successfully soldering that. Another possibility would be placing the SSR at the corner with lots of empty space, but that would mean longer leads with associated noise. I'm not at all sure if placing the component on top of the others is better, but at least the SSR shouldn't cause much noise. If it works, it can be driven by the "special IC" pin, eventually.

It seems the minimum sensitivity of the analog front-end is driven by the standard 1M resistor in the highest sensitivity configuration, so I'm not sure it's possible to push that further with sensible changes. There's been a mention of second op-amp stage somewhere. Note on the bench-top 1014D a separate analog switch for turning on extra circuits isn't entirely out of question, could be pretty indistinguishable from the standard user interface. However completely re-doing the analog front-end is just silly, and not something I particularly understand.


Also the 1014D firmware doesn't do much "useful" right now, I just setup the cock gen & UART and hooked up some of the main buttons I'm experimenting with, barely clobbered up. Trigger Mode currently disabled in the code because it hangs, time-div stops working when moved too far either direction have to figure what's up with that. At least I can select trigger channel, auto-set the settings and switch time-scale to 200Msa/s|500ns/div and get some readings.

4051 multiplexer, data-sheet says it has 125 ohm ON-resistance. Of course, depends where it's used, if you have 1M+ resistor in front might not matter that much. It also seems to have no voltage isolation spec, just ESD. I'm not sure how important it is after the big resistors, but the analog relays are still 220VDC signal/1800VAC isolation, would need separate opto-isolators to be safe and maybe replace frequently. At any case the Chinese are pro's at minimizing components, you can be sure they don't plan for end-user upgrades. Was interesting seeing spot for one unplaced component on the analog front-end though, I wonder what that's for. In any case we're limited by the ADC's, I'm wondering if one could use both ADC's on single signal. FPGA's I've worked with had configurable output delays on signals, so even if there aren't free PLL resources, I'm wondering if it would be theoretically possible. Little point doing highly involved one-off customizations nobody else is likely to use though.

Maintaining high-voltage separation is actually PITA with any modifications to the circuit. I wonder how much isolation the actual chip case offers. Placing the chip on top of others will also bring it closer to the tin-can cover which is connected to ground, and placing it to the empty corner would need passing long leads around the other components. The position displayed might be best spot due to that as well, but the clearances are going to suffer no matter what.

I should've probably looked at the Hantek schematics earlier, though I don't think there's anything that would be useful with the analog front-end already in place in the FNIRSI. I guess https://www.ti.com/product/LMH6702/part-details/LMH6702MFX/NOPB is equivalent of what they're using as buffer OpAmp, so could've looked at that instead (Although DigiKey doesn't have them, AliExpress could send some Chinese clone?). And a differential OpAmp possibly with some gain after that? Can't use that on 1014D of course.

Ah, and so much for attempting to get something else done, hah.

[pcprogrammer]

  I did not read your first post correctly. 

Thought you where on about the big relays and did not notice the extra component you put in 

I'm no expert on analog design at all, but the idea I had at some point was to just cut out the whole front end by slicing the traces to the ADC's and design a small circuit board with a new front end, but it is probably quite a bit of work to get it right and also not an easy setup for others to put in their scopes. Also things might get expensive and buying something better comes in reach quickly.

To me it feels best to just tinker with the software and maybe the FPGA to learn and play.

[Moley]

Hi all,

Sorry if this isn't the right place to post - just looking for purchasing advice.

I'm looking for an upgrade from my multimeter for audio frequency analysis. This scope has become quite cheap in Australia, so I thought I'd pick one up. I've considered similar Hantek models (quite a bit more expensive here), plus all the regular flagships (a LOT more expensive here) - from reading through this thread, I'm excited about the modification possibilities, and also convinced the major drawbacks won't have a significant impact on audible frequencies.

At AU$264 (currently US$181.50, 167 Euro), I just wanted to check this would fit the bill for basic audio circuit analysis. Any advice would be greatly appreciated.

Cheers,
Moley

[pcprogrammer]

Hi Moley,

welcome to the forum.

It depends on what information about your signals you want the scope to display. When it is just measuring on audio circuits to see if they come through as expected it could do the job, but keep in mind that the input sensitivity is not that high. 100mV per division with a 1x probe. (The 50mV per division is software zoom).

About modification possibilities it also depends what you are after. Both hardware and software wise there is room for improvement. The 1013D version (The one without the knobs) has working open source firmware for it and might be cheaper. (See this thread) Hardware is much the same.