FNIRSI-1013D "100MHz" tablet oscilloscope

[ObsoleteDIY]

Try.

O7 trigger calculation fix.
O8 removed longer sample reading in auto trigger mode.

FW DSO1.00o7 - Auto-trigger works correctly for memory settings of 12000 and for trigger positions 25%, 50%, 75%. Basic calibration sometimes takes a very long time, but this time varies probably depending on the sample rate and time base settings. Similarly, auto-tune sometimes takes a very long time and sometimes quickly.

FW DSO1.00o8 - Auto trigger does not work properly for memory settings 12000 and for trigger positions 25%, 50%, 75%. Basic calibration works fast. Similarly, auto setup works fast.

[Atlan]

1. I added calculation of *trigger address* when a time_base_out occurred (previously the trigger address was set to a fixed value)
How do I understand this? What will it do?

 If DSO does not find a trigger, it will use the trigger value 25 50 75%, which means that at startup, cnt will start to increase (in autotrigger mode) if it does not find a trigger and the required number of samples (3000-12000) will be collected. And the value from the set trigger 25 50 75% will be used to load data and place it on the screen.

[Atlan]

Thanks for your time. I've been revisiting the various posts, and now they're finally clear to me. Initially, I didn't understand the context, and they were just confusing. You gave me the right input.
As a precaution, I won't use the original FPGA flash, but another 25Q80 that I'll clone before soldering it (that might be helpful).
After the FPGA upgrade, is the version I should be displaying 1532 (my FPGA is an AL3-10)?

https://www.eevblog.com/forum/testgear/fnirsi-1013d-100mhz-tablet-oscilloscope/3400/

The procedure was described clearly, the memory above for uP needs to be unsoldered and set aside, connect the connectors for the SPI flash programming interface with cables, the original content of the SPI flash fpga is known, so going back is not a problem. The advantage is that you can improve the fpga firmware from the oscilloscope interface, i.e. no opening the oscilloscope. Since there are a lot of modifications to the fpga firmware now, when they are tested we will also transfer them to the version for AL3.

[Etrius]

Thanks for the reply and the clarification. I didn't realize the FPGA version currently being developed is only for EF2. I don't have the necessary knowledge to help you yet, but I hope to gain some.

One question: why does it say that after making the hardware changes indicated, it's impossible to revert to the original state? If I restore the original hardware and flash, shouldn't I revert to the factory settings?
Or is it because the FPGA (not the FPGA SPI Flash) is also being rewritten, losing its original content because it's encrypted and unknown?

[ObsoleteDIY]

Hi,

Maybe I made an unnecessary change because I didn't understand how the FW DSO works. Can you please write how the *trigger_addres* register should be set if *time_base_timeout* occurs? I will make the change so that the FW FPGA works as expected by the FW DSO.

If a trigger occurs, the FPGA stores the triger_address and writes to memory (postriger_samples) and then stops.

If a timebase out occurs, the FPGA immediately stops writing samples to memory. I added the calculation so that the triger_address value is on the window last samples written to memory.

     if (~trigger_mode & time_base_timeout & (sampling_triggered == 0)) begin
             //OLD trigger_address <= postrigger_samples);

             //NEW  if (trigger_read_address >= postrigger_samples) trigger_address <= (trigger_read_address-postrigger_samples);           
                        else trigger_address <=  (MEM_SIZE - (postrigger_samples-trigger_read_address));   
     end else trigger_address <= trigger_read_address;

[Atlan]

Thanks for the reply and the clarification. I didn't realize the FPGA version currently being developed is only for EF2. I don't have the necessary knowledge to help you yet, but I hope to gain some.

One question: why does it say that after making the hardware changes indicated, it's impossible to revert to the original state? If I restore the original hardware and flash, shouldn't I revert to the factory settings?
Or is it because the FPGA (not the FPGA SPI Flash) is also being rewritten, losing its original content because it's encrypted and unknown?

Where does such a message appear? Now it is still possible to return to the fnirsi firmware, the contents of the fnirsi firmware: DSO and FPGA are available.

When the version for EF2 is functional, I will compile the version for AL3 as well, it is not a problem. There is a version for AL3 on github, but it does not contain current knowledge and changes applied to EF2. Firmware version 1.0 is still Beta. Because it is necessary to remove errors in the fpga firmware and DSO firmware. Therefore, I do not recommend combining files with github, at least for now. Here on the site, complete packages are published that are functional, i.e. contain fw fpga and the corresponding DSO firmware.

[Atlan]

Hi,

Maybe I made an unnecessary change because I didn't understand how the FW DSO works. Can you please write how the *trigger_addres* register should be set if *time_base_timeout* occurs? I will make the change so that the FW FPGA works as expected by the FW DSO.

If a trigger occurs, the FPGA stores the triger_address and writes to memory (postriger_samples) and then stops.

If a timebase out occurs, the FPGA immediately stops writing samples to memory. I added the calculation so that the triger_address value is on the window last samples written to memory.

     if (~trigger_mode & time_base_timeout & (sampling_triggered == 0)) begin
             //OLD trigger_address <= postrigger_samples);

             //NEW  if (trigger_read_address >= postrigger_samples) trigger_address <= (trigger_read_address-postrigger_samples);           
                        else trigger_address <=  (MEM_SIZE - (postrigger_samples-trigger_read_address));   
     end else trigger_address <= trigger_read_address;

This can be useful because the end and beginning of the memory will not be combined. Give me the line numbers where you are making changes and the code (ideally give the code through the # tag) so that I can implement it in AL3 and EP4 - the code is written differently there.

[Etrius]

Where does such a message appear? Now it is still possible to return to the fnirsi firmware, the contents of the fnirsi firmware: DSO and FPGA are available.

Thanks for the clarification, yes this indication appears in some posts but, probably, I hadn't understood the real context and had this doubt

Here on the site, complete packages are published that are functional, i.e. contain fw fpga and the corresponding DSO firmware.

Thanks for the report. So I should be able to find something for AL3 too, even if that's not the version currently in development.

[ObsoleteDIY]

Hi,

please see attached *.zaklad.v* file. My changes are marked #NEW BEGIN, #NEW END

[Etrius]

Hello everyone. Please tell me which firmware version is more stable.

I think the one on GitHub. The builds in this thread are more for testers.

[Moondeck]

I see a few posts prior there was some talk about removing the FPGA memory to flash it, etc... Looking at the schematics, wouldn't it be possible to simply solder a couple of wires to SDA/SCL, as it already is used for the RTC mod, and then have a routine in the firmware/bootloader to flash the FPGA memory?

[Etrius]

I don't think so, because the FPGA flash uses the SPI bus, not the I2C bus. Furthermore, the solution proposed by Atlan to eliminate the MCU flash (the firmware is loaded from the SD card) and use its bus to program the FPGA flash seems like the best feasible solution.
At least that's my amateur opinion.

[Moondeck]

I don't think so, because the FPGA flash uses the SPI bus, not the I2C bus. Furthermore, the solution proposed by Atlan to eliminate the MCU flash (the firmware is loaded from the SD card) and use its bus to program the FPGA flash seems like the best feasible solution.
At least that's my amateur opinion.

IIRC that depends which model you have, but the AL3-based schematic i was able to find shows a N24C08 (which im not sure is correct, but the surrounding circuitry looks like it would be I2C)

[Etrius]

My device uses an AL3-10, but it doesn't match the schematic you're referring to. The FPGA section looks similar to the 1014d schematic.
Multiple versions were probably produced. You should disassemble your device and check.

[Atlan]

I don't think so, because the FPGA flash uses the SPI bus, not the I2C bus. Furthermore, the solution proposed by Atlan to eliminate the MCU flash (the firmware is loaded from the SD card) and use its bus to program the FPGA flash seems like the best feasible solution.
At least that's my amateur opinion.

IIRC that depends which model you have, but the AL3-based schematic i was able to find shows a N24C08 (which im not sure is correct, but the surrounding circuitry looks like it would be I2C)

That would be more of a chip used for bit stream logging, an absolutely useless thing that only causes problems. And it is connected via i2c to the fpga.

 Otherwise, there is a photo from a user somewhere, I assume that the version of the oscilloscope board that does not have recessed BNC connectors, and there the spi pins were shuffled.

[Felipe Lacerda]

FW DSO1.00o8

That’s really fast!
woowwww 

[ObsoleteDIY]

Code: [Select]

if(fpgasettings.fw_FPGA == 3) //fpga EF2
    {   
      if(data < (fpgasettings.settriggerpoint/2))
      {
          data = 6143 - (fpgasettings.settriggerpoint/2) + data;
      }
      else
      {
          data = data - (fpgasettings.settriggerpoint/2);
      }
    }
This is how it should be right. I'm not sure if it's 6143 or 6144. But when I played with it before, the correct value was - 1, The number of samples doesn't matter. We are actually looking for a trigger in the circular memory. Of course, we also need to display the samples before the trigger 25 50 75%, so the given number is subtracted from the place where the trigger is in the circular memory. The obtained number is used as the start from which the samples are read into the uP memory. If we have samples in the uP memory, a check is also performed to fine-tune the trigger location for its placement in the center of the horizontal cursor. (I have to check there if there is no error too)

In the basic and automode calibration modes, the Trigger is not used and the number of samples is 1000. Due to the increase in speed, it is possible that the given setting is overwritten, see the code for auto Trigger mode, the Sampling duration is extended there. I will upload a modified version of the DSO firmware here. So try to see if the conversion will be ok.

Hi Atlan

I am testing FW DSO 1.00o8 and could there be a problem with the sample shift? Maybe the problem is the constant 6143 in the calculation and I think the correct value is 6144. Please see the attached files.

[Atlan]

Rather, it will be your special changes in the fpga firmware.

so far I have edited the DSO firmware to 0x16yy so that 0x16 indicates the EF2 family and yy the version number, let's just agree whether the version number will be in dec or hex format, i.e. 99 version or 255 firmware version. Or I would lean more towards it. 0x1yyy for fnirsi firmware, 0x2yyy for EF2 firmware, 0x3yyy AL3 firmware, 0x4yyy for EP4 altera firmware. yyy in dec.

0x16yy is supported in dso 1.00o9, I am attaching *.bit with version fw00

[ObsoleteDIY]

Hi,

I will delete the changes in the FW FPGA EFL2 and test again. Thanks

[ObsoleteDIY]

Good idea, hex format is ok for me.

[Atlan]

0x1yyy for fnirsi firmware, 0x2yyy for EF2 firmware, 0x3yyy AL3 firmware, 0x4yyy for EP4 altera firmware. yyy in dec.
Let's leave it in decimal form so that there is no need to explain why firmware 2A is there, the number will be stored in hexadecimal, but only characters 0-9 will be used. 0x3001, is firmware for AL3 s fw 001, if then fw version 10,  write 0x3010

[ObsoleteDIY]

Hi Atlan,

Thanks – now I can change the FPGA firmware version for debugging.

The problem with DSO FW 1.00o8 was measuring a 150ns pulse with sampling 5MSPS (200ns) or 10MSPS (100ns).

The FPGA EF2L does not check the signal before turning on the trigger and resetting the FPGA randomly shifts the sampling.

Maybe I will try to add a signal level check before turning on the trigger. I will try to see if Auto Trigger works better

[Etrius]

I couldn't find the firmware for the AL3-10 FPGA in the various posts. Can I use the firmware on GitHub with version 1.00o8?

[Atlan]

you can but it doesn't make sense. wait a few days, I'll release the firmware dso and if I don't forget I'll compile it for you for Al3

have you progressed? otherwise there is an error, if the memory depth changes, you need to go to trigger settings and re-select the desired trigger location in memory 25-50-75%

[Etrius]

you can but it doesn't make sense. wait a few days, I'll release the firmware dso and if I don't forget I'll compile it for you for Al3

Wonderful, thank you 
(Obviously, don't rush it, when you have time to work on it. I'm just starting to study FPGAs, but I still have a lot to learn...)

have you progressed? otherwise there is an error, if the memory depth changes, you need to go to trigger settings and re-select the desired trigger location in memory 25-50-75%

Sorry ... no, I'm still stuck on version 1.006o and the original FPGA firmware. I was hoping to get to work on it this weekend.