FNIRSI-1013D "100MHz" tablet oscilloscope

[pcprogrammer]

Why oh why do I keep making these stupid copy, paste not modify errors.

Copied the setup_interrupt function call from the timer code, but forgot to change the IRQ number.

With this the USB interrupt was called every millisecond instead of on the actual USB interrupts. Since this is fast enough for the USB interface to be handled that part worked.
But for the rest of the system the timer delay is killed since the timer handler is replaced with the USB handler. This most likely caused the system not to return to the normal state when touched in the ON/OFF field of the USB connect screen

Code: [Select]

  //Setup the interrupt for the USB interface
  setup_interrupt(TMR0_IRQ_NUM, usb_irq_handle, 0);

Now set with the correct irq number it works like a charm

Code: [Select]

  //Setup the interrupt for the USB interface
  setup_interrupt(USB_IRQ_NUM, usb_irq_handle, 0);

So it now is a case of converting it to a mass storage device and clean things up.

[jchd]

Mine got shipped from Czech source/stock.

Yeah, zero-COVID policies in S-E Asia + repeated confinements in industrial areas caused breaks in stocks of everything. In electronics, this first showed for high-value components but I now see more and more "small" components out of stock for up to 12 months. This will probably affect almost every business, electronics being so ubiquitous.

Anyway, thanks for putting so much time and efforts to fix this device.

[pcprogrammer]

On and off working on the mass storage code. Found the tinyusb implementation which gives a nice base to work from. Reversing the original code is not a real option. It is full with strange bits that do not stroke with the specifications. For instance a check is done on length not being 31 and if so a debug command says valid CBW, which is strange since a command block wrapper has to be 31 bytes.

In the mean time I tried using the scope to do measurements on a defective guitar amplifier (A Marshall MG-100FX), but for that it is absolute useless. In the power stage the supply voltage is plus and minus 45V, whilst control signals are in the range of 200mV or lower. With a 10x probe (needed for the 45V to not destroy the scope) the 500mV/div is to high to see some meaningful signal. Switched to the Hantek DSO2D10 with which I was able to determine the positive side of the power stage was not getting signal. Without a schematic very tricky to find the problem, but close inspection showed a hole in an opamp. Not sure about further defects and don't have any smd opamps in stock so shelved for later.

[pcprogrammer]

Managed to get at least file read to work (very crude implementation without error checking) but it is very slow compared to the original one. Need to figure out if this is caused by the USB handling or the SD card reading.

Since high speed USB with bulk endpoints works with 512 bytes and the SD card sector size is also that I made my implementation such that it only reads one sector per USB IN transaction, and I think that the original code reads all the requested sectors in one swoop to a big buffer. So I have to try that and see if it makes a difference.

Monitored the transfer for both with wireshark and the difference is significant. >2.3S versus <0.1S

This is a capture from the original scope. Second column is the time indication.

Code: [Select]

1423 18.279385 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c660, Len: 240)
1424 18.279399 1.18.1 host USB 64 URB_BULK out
1425 18.279435 host 1.18.1 USB 64 URB_BULK in
1426 18.290936 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1427 18.290982 host 1.18.1 USB 64 URB_BULK in
1428 18.291015 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1429 18.291098 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c750, Len: 16)
1430 18.291145 1.18.1 host USB 64 URB_BULK out
1431 18.291180 host 1.18.1 USB 64 URB_BULK in
1432 18.292487 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1433 18.292525 host 1.18.1 USB 64 URB_BULK in
1434 18.292562 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1435 18.292895 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c760, Len: 240)
1436 18.292906 1.18.1 host USB 64 URB_BULK out
1437 18.292946 host 1.18.1 USB 64 URB_BULK in
1440 18.304417 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1441 18.304462 host 1.18.1 USB 64 URB_BULK in
1442 18.304477 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1443 18.304554 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c850, Len: 16)
1444 18.304563 1.18.1 host USB 64 URB_BULK out
1445 18.304569 host 1.18.1 USB 64 URB_BULK in
1446 18.305946 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1447 18.305979 host 1.18.1 USB 64 URB_BULK in
1448 18.306014 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1449 18.306096 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c860, Len: 240)
1450 18.306106 1.18.1 host USB 64 URB_BULK out
1451 18.306145 host 1.18.1 USB 64 URB_BULK in
1452 18.317644 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1453 18.317676 host 1.18.1 USB 64 URB_BULK in
1454 18.317685 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1455 18.317752 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c950, Len: 16)
1456 18.317800 1.18.1 host USB 64 URB_BULK out
1457 18.317844 host 1.18.1 USB 64 URB_BULK in
1458 18.319139 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1459 18.319173 host 1.18.1 USB 64 URB_BULK in
1460 18.319211 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1461 18.319297 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000c960, Len: 240)
1462 18.319307 1.18.1 host USB 64 URB_BULK out
1463 18.319345 host 1.18.1 USB 64 URB_BULK in
1464 18.330856 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1465 18.330911 host 1.18.1 USB 64 URB_BULK in
1466 18.330948 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1467 18.331002 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000ca50, Len: 16)
1468 18.331022 1.18.1 host USB 64 URB_BULK out
1469 18.331026 host 1.18.1 USB 64 URB_BULK in
1470 18.332387 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1471 18.332393 host 1.18.1 USB 64 URB_BULK in
1472 18.332460 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1473 18.332477 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000ca60, Len: 240)
1474 18.332528 1.18.1 host USB 64 URB_BULK out
1475 18.332533 host 1.18.1 USB 64 URB_BULK in
1476 18.344028 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1477 18.344086 host 1.18.1 USB 64 URB_BULK in
1478 18.344133 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1479 18.344189 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cb50, Len: 16)
1480 18.344214 1.18.1 host USB 64 URB_BULK out
1481 18.344248 host 1.18.1 USB 64 URB_BULK in
1482 18.345597 1.18.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1483 18.345604 host 1.18.1 USB 64 URB_BULK in
1484 18.345659 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1485 18.345727 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cb60, Len: 240)
1486 18.345738 1.18.1 host USB 64 URB_BULK out
1487 18.345792 host 1.18.1 USB 64 URB_BULK in
1488 18.357253 1.18.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1489 18.357300 host 1.18.1 USB 64 URB_BULK in
1490 18.357307 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1491 18.357363 host 1.18.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x0000cc50, Len: 43)
1492 18.357373 1.18.1 host USB 64 URB_BULK out
1493 18.357427 host 1.18.1 USB 64 URB_BULK in
1494 18.359918 1.18.1 host USBMS 22080 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1495 18.359929 host 1.18.1 USB 64 URB_BULK in
1496 18.359955 1.18.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)


This is a capture from my code

Code: [Select]

1473 37.161925 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000110c0, Len: 240)
1474 37.161974 1.17.1 host USB 64 URB_BULK out
1475 37.162023 host 1.17.1 USB 64 URB_BULK in
1478 37.518151 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1479 37.518224 host 1.17.1 USB 64 URB_BULK in
1480 37.518299 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1481 37.518440 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000111b0, Len: 16)
1482 37.518488 1.17.1 host USB 64 URB_BULK out
1483 37.518542 host 1.17.1 USB 64 URB_BULK in
1484 37.546236 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1485 37.546310 host 1.17.1 USB 64 URB_BULK in
1486 37.546372 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1487 37.547731 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000111c0, Len: 240)
1488 37.547798 1.17.1 host USB 64 URB_BULK out
1489 37.547857 host 1.17.1 USB 64 URB_BULK in
1490 37.904446 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1491 37.904558 host 1.17.1 USB 64 URB_BULK in
1492 37.904623 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1493 37.904795 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000112b0, Len: 16)
1494 37.904831 1.17.1 host USB 64 URB_BULK out
1495 37.904851 host 1.17.1 USB 64 URB_BULK in
1496 37.932611 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1497 37.932640 host 1.17.1 USB 64 URB_BULK in
1498 37.932652 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1499 37.932763 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000112c0, Len: 240)
1500 37.932820 1.17.1 host USB 64 URB_BULK out
1501 37.932877 host 1.17.1 USB 64 URB_BULK in
1520 38.289367 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1521 38.289441 host 1.17.1 USB 64 URB_BULK in
1522 38.289468 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1523 38.289631 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000113b0, Len: 16)
1524 38.289645 1.17.1 host USB 64 URB_BULK out
1525 38.289657 host 1.17.1 USB 64 URB_BULK in
1532 38.317430 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1533 38.317488 host 1.17.1 USB 64 URB_BULK in
1534 38.317502 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1535 38.317612 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000113c0, Len: 240)
1536 38.317626 1.17.1 host USB 64 URB_BULK out
1537 38.317638 host 1.17.1 USB 64 URB_BULK in
1628 38.674216 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1629 38.674310 host 1.17.1 USB 64 URB_BULK in
1630 38.674337 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1631 38.674464 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000114b0, Len: 16)
1632 38.674479 1.17.1 host USB 64 URB_BULK out
1633 38.674502 host 1.17.1 USB 64 URB_BULK in
1640 38.702252 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1641 38.702326 host 1.17.1 USB 64 URB_BULK in
1642 38.702341 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1643 38.702457 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000114c0, Len: 240)
1644 38.702472 1.17.1 host USB 64 URB_BULK out
1645 38.702484 host 1.17.1 USB 64 URB_BULK in
1722 39.059089 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1723 39.059195 host 1.17.1 USB 64 URB_BULK in
1724 39.059258 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1725 39.059427 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000115b0, Len: 16)
1726 39.059463 1.17.1 host USB 64 URB_BULK out
1727 39.059474 host 1.17.1 USB 64 URB_BULK in
1730 39.087230 1.17.1 host USBMS 8256 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1731 39.087261 host 1.17.1 USB 64 URB_BULK in
1732 39.087272 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1733 39.087376 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000115c0, Len: 240)
1734 39.087398 1.17.1 host USB 64 URB_BULK out
1735 39.087412 host 1.17.1 USB 64 URB_BULK in
1736 39.443931 1.17.1 host USBMS 122944 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1737 39.444045 host 1.17.1 USB 64 URB_BULK in
1738 39.444121 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)
1739 39.444293 host 1.17.1 USBMS 95 SCSI: Test Unit Ready LUN: 0x00
1740 39.444317 1.17.1 host USB 64 URB_BULK out
1741 39.444327 host 1.17.1 USB 64 URB_BULK in
1742 39.444362 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Test Unit Ready) (Good)
1743 39.444519 host 1.17.1 USBMS 95 SCSI: Read(10) LUN: 0x00 (LBA: 0x000116b0, Len: 10)
1744 39.444543 1.17.1 host USB 64 URB_BULK out
1745 39.444553 host 1.17.1 USB 64 URB_BULK in
1746 39.461909 1.17.1 host USBMS 5184 SCSI: Data In LUN: 0x00 (Read(10) Response Data)
1747 39.461939 host 1.17.1 USB 64 URB_BULK in
1748 39.461950 1.17.1 host USBMS 77 SCSI: Response LUN: 0x00 (Read(10)) (Good)


So they got one thing right but when I open an image from this mass storage device the scope hangs, so on the other hand they messed something up

My version still needs the write command implemented to be able to un-mount the drive when it needs a write back. At least there is progress again.

Edit: Modified the code to read from the SD card into a bigger buffer and it is the solution for the speed. It shows the same speed as the original. So quite a lot of overhead in reading a single sector from the SD card. With the USB mass storage only active when enabled by the user and blocking the rest of the scope code, allows for using the 400000 byte buffer the code has for loading the thumbnail files when viewing pictures or wave files on the scope itself. My version does not hang, at least with the code I have working now.

[pcprogrammer]

The write command is now also implemented. During testing I noticed that the host sends commands to allow or prevent removal of the device, so I'm thinking about implementing this in the code with visual feedback like a lock symbol if the host won't allow release of the device.

Needs to be robust in the sense that when the cable is disconnected the scope won't hang in this mode and releases it self back to the scope mode. This is not the case on the original. It needs a power cycle to be brought back to live

My implementation is very crude and lacks a lot of checks, so there is still work to be done on it. Like to do a complete re write of the whole USB code, since it is full of crap. Much easier now I have a working code base and knowledge about the working of it all.

It did survive several tests with writing a file, un-mounting, mounting again, deleting the file, etc. So very promising.

[pcprogrammer]

I have been playing with SD cards a bit, to look into making a firmware and touch panel configuration backup utility and found that my SD card implementation has some problem. To not screw up the original SD card I wanted to use one of the 4GB cards I have lying around, but it did not work with them. Tried with a shrunk image of the original card written to the 4GB card, but no dice. It does work with the original code, so it is back to the drawing board for that.

Also looked into the booting from a SD card, which the F1C100s is capable of, and it is the first device tested when booting. I noticed that a linux image I made does boot without problems even when written to bigger cards. Tried the FEL boot with the original 8GB card in the scope (even used the scope to dd the image to, which works) and it started in FEL mode no problem what so ever, so I'm stumped as to were it failed with the 4GB cards before

The boot process is described here: https://linux-sunxi.org/Bootable_SD_card
When there is a valid EGON or TOC0 signature at byte address 0x2000 it will boot from it.

This opens up an easy route to get things done without opening the scope.

Thinking of the following steps:

• Connect the scope to the computer and start the USB connection
• Use DD to make a backup of the SD card, just to be safe (sudo dd bs=4M if=/dev/sd? of=scope_sd_card.img)
• Use DD to write the needed backup program to the boot location (sudo dd if=backup_program.bin of=/dev/sd? bs=1024 seek=8)
• Reboot the scope so it can make the backups
• Copy the backup files from the SD card to the computer (Via the USB connection)
• Press a screen button to erase the backup program
• Reboot the scope so it gets back to its normal state

This way it is also possible to add a check on the touch panel config to see if it fits my new scope Easy to show a message on the screen alerting this is the case and ask to have it posted here on the forum

[pcprogrammer]

The USB re write is coming along nicely

Managed to get rid of several unneeded memcpy's and cleaned up the complete end point 0 handling. Since it is bare metal programming I'm making it mass storage dedicated, but with the amount of commentary in the code it is easy to change it for other USB devices.

Next up is the end point handling for the mass storage data. Converting what I have is not that much, but it still needs the adding of the error checking. When done the amount of code needed, I suspect will be near half of what I had first. After the first working version it was about 15KB for the USB, and now with the additional cleaned up code it is about 20KB, because the old code is also still in there. So the new code is about 5KB.

Did a small step at a time conversion, with in between testing to make sure it kept working.

[pcprogrammer]

Done with the first step of the USB re-write. Encountered some tricky things of the USB peripheral, like the order in which some bits are set or cleared make a world of difference between working and not working and sometimes a bit random working.

Cleaned up the repository where the source code resides. (https://github.com/pecostm32/FNIRSI-1013D-Hack/tree/main/Test%20code/fnirsi_1013d_scope)
Removed the original USB source files. Left are four new files that handle the USB mass storage device.

Still work to be done on the error checking in the mass storage class, and improve the data handling of its out end point, which for now still uses a memcpy to move the data from the receive buffer to the SCSI buffer. Can be done without it, by direct copying from the FIFO into the target buffer. Easier to tackle now the other stuff is out of the way.

Improved on the USB FIFO reading and writing to be buffer alignment independent. The original code only works when it is 32 bit aligned.

[pcprogrammer]

Quite a while back I wrote about I wanted to use my own startup image on the scope, and today I wrote the code for it. It is not a bitmap that is loaded, but display code that is run to make the image.

The attached picture is a bit fuzzy, but it is on my test scope, which still has the protective film on the acrylic panel I made for it to repair the broken glass.

[KubaSO]

I usually compile with O2. The speed increase is noticeable.
Why does the optimization break the touchscreen?

The touch panel delay routine was an empty for loop. This is removed by the compiler when optimization is set to 1 or higher. Changed it to an assembly loop and now it works with optimization level O2.

The speed of the sliding in of the menu's is much better now. There will still be room for improvement, but the first goal is to get working code that mimics the scope.

And that is coming along, but still a lot of work. Put in the code for changing the screen brightness. It uses special functionality of the FPGA, for which I reversed the code a while back but did not test it until now. Happy to say that it works.

That's normal. Modern C and C++ programming does not admit the concept of a delay loop. The compiler removes code that has no observable side effects, and time wasted is not a side effect in C/C++.

Code compiled without optimization is junk. It's only useful for debugging with a debugger actually running on the target. It has no other uses.

So basically forget about building stuff without optimizations. You'll be fighting performance windmills most of the time.

[pcprogrammer]

The firmware backup is taking shape.

The touch panel configuration is already being saved and I made the layout of the remainder of the screen.

It also shows the FLASH manufacturer and the id, based upon which it decides to backup either 2MB or 4MB. 2MB is the minimum size since the original firmware is 1.6MB, and I don't think there are scopes with 8MB FLASH chips, and even if there are it is not a big deal.

When the backup is finished it attaches to the computer as a mass storage device and allows for copying the files.

In case of the special touch panel being detected it will show some messages. Might even blink them

[pcprogrammer]

Finished the backup part of the backup-er and made a video of it.

https://youtu.be/h-tdKPDocHI

Next is to make a bootloader for it and a combined package that can be written to the SD card of a scope.

Waiting for a bunch of new SD cards I ordered from Aliexpress to do further testing on the SD card code.

Doing this bit of code showed me that the bulk of the scope code is made up of the FatFs, SD card, USB interface and display library. This fairly simple backup program is 147KB against the scope program being 211KB as it stands now. Removed a couple of the fonts, and the icons, but that took of only 16KB or so. The statemachine (user interface) and scope functions is about 50KB of code.

[ledtester]

Oh, and all this time I thought the "pc" in  "pcprogrammer" stood for "personal computer" 

[pcprogrammer]

Very frustrating this boot loader stuff

When I load my original boot loader to the SD card starting on sector 16 and turn on the scope it boots the original scope code from flash without problems, so starting from SD card works.

But when I try the boot loader I wrote for loading from the SD card it fails big time. Tested the code, adapted for running in DRAM, by loading it to DRAM via my special FEL boot (which is in the FLASH) and that loads the firmware backup code from the SD card and starts it, so I know the code it self is OK.

Figure it has to do with the timer interrupt needed for the SD card implementation, but testing this theory is not easy. With FEL only very small programs can be loaded and tested in the startup RAM. The boot loader is 17KB and that is to big to load. FEL fails when I try. Have to write it to the SD card to test it. Bit of a pain in the bum

The problem lies in the fact that the code is loaded to address 0x00000000, which is where the vectors are. It should be fine to overwrite the first bit of the code since it is only the loading of the stack pointers. The code to copy the vectors follows after that, so should not be a problem

Guess I will look at the SD code and see if I can get it working without the timer interrupt, and hopefully that solves it.

Oh, and all this time I thought the "pc" in  "pcprogrammer" stood for "personal computer" 

Yes that is the fun part of my initials

[pcprogrammer]

Took quite a bit of fiddling and get past an oversight to get it working.

The oversight was, that in the project I originally created, I made all kind of modifications to test things, and I forgot to remove a while(1); near the beginning of the code, so it never reached the new SD card code. Found that one when I inspected the code in Ghidra Falls under one sees what one wants to see.

Removed it et voila it did the trick. The SD card code for this boot loader no longer uses the timer ticks for the max timeout timing. Changed to a variable being decremented and if it gets to zero before the card interface is done it is a time out. It worked in the DRAM based project, so I had high hopes. Justified apart from the stupid oversight.

Do have another weird problem. The firmware backup program uses nice rounded rectangles for the progress bars, and as can be seen in the video it works when I load the program via the FEL utility. However when it is loaded from the SD card they are f-ed up

" alt="" class="bbc_img" />

So a bit more research to be done.

[pickle9000]

I am so bad for that. 

[pcprogrammer]

I found the problem with the rounded rectangles, but do not have a solution for it due to lack of knowledge.

It has to do with the linker and the size it calculates. For the BROM header at the start of the program the size of the complete program has to be set. This means the code (.text) and the preset data (.data). Had problems with this before and thought to have solved it with adding read only data (.rodata) which seems to live in a separate segment in my tools.

Just read an article online that data declared constant ends up in the .text segment, but that does not seem to be the case here.

With the below shown linker script the sine table is placed at the end of the file, but the __program_size falls short with about 1KB. That is why it works when I load the program with FEL. All the data is loaded to memory, but when it is loaded from the SD card it does not load the last kilo byte and that screws up the sine table and with it the rounded rectangles.

When I add the size of .bss it returns the full size of the created file, but that also entails uninitialized data that is not needed to be copied. Tried with adding the size of .rodata, but that gives an error (undefined section `.rodata' referenced in expression)

This means doing a bit more research

Code: [Select]

MEMORY
{
  ram  : org = 0x7FFFFFE0, len = 32M
}

SECTIONS
{
  . = ORIGIN(ram);
  .text :
  {
    build/Debug/GNU_ARM-Linux/start.o (.text)
    *(.text);
  } >ram

  .data :
  {
    *(.data);
    *(.rodata);
  } >ram

  BSS_START = .;
  .bss :
  {
    *(.bss);
  } >ram
  BSS_END = .;

  __program_size = SIZEOF(.text) + SIZEOF(.data);
}


[pcprogrammer]

Fixed it. Modified the linker script and now it returns a value that equals the actual size of the file it creates.

Code: [Select]

MEMORY
{
  ram  : org = 0x7FFFFFE0, len = 32M
}

SECTIONS
{
  . = ORIGIN(ram);
  PRGM_START = .;
  .text :
  {
    build/Debug/GNU_ARM-Linux/start.o (.text)
    *(.text);
  } >ram

  .data :
  {
    *(.data);
    *(.rodata);
  } >ram
  PRGM_END = .;

  BSS_START = .;
  .bss :
  {
    *(.bss);
  } >ram
  BSS_END = .;
}

__program_size = PRGM_END - PRGM_START;

Tried the code on my new scope and it resulted in opening it up again

The SD card had a, to my understanding valid but uncommon partition setup. The partition started at sector 32 leaving only 16KB for boot data. Since the BROM boot loader expects the loader to be at sector 16 it only left 8KB, which is less then half the bootloader, let alone the full firmware backup package.

No actual damage done, but the scope started with "SD ERROR", so had to take the card out and reformat it.

This means that anyone willing to use this tool does so under its own responsibility!!

In case something goes wrong it means opening up the scope and fix the problem. In that case a SD card reader/writer is needed.

In my next post I will provide the package and instructions to make it all work.

Tested the steps I'm providing on my new scope and it worked without problems. (After the first test that is  )

[pcprogrammer]

Here is the tool plus the steps to make it work.

!! I take no responsibility if anything goes wrong !!

Steps for making the FNIRSI-1013D firmware backup on a Linux machine:

• Connect the scope to the computer via USB.
• Turn on the scope and start the USB connection via the main menu option.
• Wait until the file manager window opens. (Only if auto mount is working properly)
• Close the file manager window.
• Open a terminal window (ctrl + alt + t) and type the "lsblk" command (!do not use the quotes!) and check which device the scope is on. (~8GB disk)
• Copy the files from the card to have a backup on your computer.
• Un-mount the partition. ("sudo umount /dev/sdc1" in my case)
• Just to be more safe make a backup with dd. ("sudo dd bs=4M if=/dev/sdc of=sd_card_backup.bin" again in my case)
• Open gparted and check if the device is properly formated. (Use right mouse and information to see the sector info)
• If not delete the partition and make a new one leaving 1M free at the start. Format is fat32.
• When the partition remounts after the previous step un-mount it again.
• Use dd to place the backup package on the SD card. ("sudo dd if=fnirsi_1013d_fwb.bin of=/dev/sdc bs=1024 seek=8")
• This will re-mount the partition. Un-mount the partition again. ("sudo umount /dev/sdc1" in my case)
• Turn of the scope and turn it back on. This will start the backup process.
• Wait until it is done and the scope is mounted again. File manager window should open after a while.
• Copy the three files to the computer. (FNIRSI_1013D_full_flash_backup.bin, FNIRSI_1013D_tp_config.bin, FWB_FSI_1013.bin)
• Turn off the scope and turn it back on. It should start normally.

When the scope showed the "!! special touch panel detected !!" message please upload the "FNIRSI_1013D_tp_config.bin" file in this thread.

If your scope uses a smaller or bigger SD card be warned that this is not tested yet. Only 8GB cards have been tested.

See the attached image for info on the sd card sectors. Screen cap from gparted.

Remove the .txt extension from the firmware backup package file.

[pcprogrammer]

There is a problem with the firmware backup made with the backup tool.

The check bytes do not match what they should be, and unfortunately after correcting them with the tool I made for it earlier it still fails when loaded on the scope.

In itself not a problem, but it means that restoring the scope to its original state after trying my open source version is a bit trickier.

Have to open up my new scope again to see if I can find why it failed in restoring the firmware and restore it via FEL.

Need to compare what is in the backup with what it should be to be sure the backup is correct.

To be continued

[pcprogrammer]

Fixed the check data calculation and I'm onto the why my new scope is not doing a firmware backup.

By the looks of it, I unintended changed the boot loader in the FLASH of it since the first try of loading new firmware. There are so many flash backups on my computer from different tests that when I had to fix the touch panel problem of the new scope I probably used a file that has my own version of the boot loader in it. This one does not have the start of the other executable in it, so no firmware update being done.

There is a size difference between the different boot loaders, so that way I was able to tell them apart.

This means there is a good change the firmware backup file made with the correct firmware backup package (attached below) does what it needs to do.

To test it I first have to put the right boot loader in my new scope

[pcprogrammer]

Ah well enough crap for today, both mine as the Chinese type

It was indeed the boot loader, but with the original one in there it started the writing of the flash, but it keeps doing it over and over. It looks like it fails the check at the end of the firmware update and then resets. In the flash the brom header of the main program is not written (12 bytes the program skips at first and needs to fill them in later).

Or judging by the way it fades at the end and then restarts, it could also be the result of the watchdog still running and the flash program running to long

But all this experimenting gave me an idea for easier testing or even running the open source code. Just make a SD card package for it and load it that way. Also easy to get rid off again. Just clear sector 16 on the SD card and it is gone.

[pcprogrammer]

Did not check the firmware update any further and instead continued the "run from SD card" idea.

It makes use of a two stage boot loader setup. The first boot loader loads the startup screen program from the SD card and starts it. This startup screen program puts my startup image on the screen and then loads the main program from the SD card and starts it.

Made the projects and code for it and tested it on my test scope. Worked in the first try

To be able to test it on my new scope I first have to change the touch panel code to use the original configuration. When that is done it can be tested by others whom are willing to test the user interface part. The actual scope functionality still needs a lot of work.

Loading it is easy once the SD card is the way it should be. Partition starting on sector 2048, to allow the scope package on the card without interfering with the partition. (See a couple of posts back, with the red warnings  )

Code: [Select]

//Connect the scope to the computer and enable USB
//Un-mount the partition
sudo umount /dev/sdc1

//Load the package
sudo dd if=fnirsi_1013d.bin of=/dev/sdc bs=1024 seek=8

Removing it is also easy

Code: [Select]

//Connect the scope to the computer and enable USB
//Un-mount the partition
sudo umount /dev/sdc1

//Un-load the package
sudo dd if=/dev/zero of=/dev/sdc bs=1024 seek=8 count=1

This setup does not interfere with the FLASH, so normally no risk on having to open up the scope. Bricking it is near impossible

[pcprogrammer]

And here is the test package

It does not modify the touch panel configuration, but instead it reads it and calculates scalars based on the set x and y max values. Tested it on both my scopes and did not have any problems.

It reads the scope configuration from FLASH, but it does not write it on power down, so the FLASH is left unmodified.

I did notice that on my new scope the startup screen looks iffy, which strengthens my believe that it is a different display. So some more work on that front, but the live scope screen itself looks ok.

It also writes the touch panel configuration to the SD card, and when left on there, it only does this once. (file: FNIRSI_1013D_tp_config.bin)

As I wrote before it is basically impossible to brick this scope, and in case something goes wrong all that is needed is a screwdriver and a SD card reader/writer.

[pcprogrammer]

Received a couple of the SD cards today, and I tested them in the scope with my software version.

I ordered 1GB, 2GB, 4GB, 8GB and 16GB. Still waiting on the 4GB and 8GB.

The 1GB and 2GB are FAT16 formatted and this did not give any problems, but they need re partitioning to allow the new firmware to be loaded on to it. The 1GB starts on sector 16 and the 2GB on sector 32. Needs to be at least sector 800, but the more standard 1MB (sector 2048) allows for expansion.

The 16GB card is FAT32 formatted and also works without problems. The partition on that card starts beyond the needed 2048 free sectors, so no problem there.

For people with smaller cards in their scopes, they will, most likely, have to re partition their SD cards.

As there are different types of cards out there, it is no guarantee it will work with all cards. The ones I got are marked HC class 10

More testing when the other cards arrive.