FNIRSI GC-01: Installation tricks

[PlasmaHH]

Hi there, before I resort to flashing it with a debugger ( btw. since the bundled flashtool scripts use openocd maybe you can add ftdi support? Many more people possibly have some kind of ftdi device than stlinks ) I wanted to see if I exhausted all possibilities on a "normal" install.

Sorry if this is somewhat lengthy, I just wanted to show all my process, since I think I almost got it (due to the "bricked" state it must have changed the firmware somehow) the missing piece might be smoewhere in here...

Context

I have a CH32F1 chip, ENH LCD.

It seems to me that the device is somehow trying to emulate a FAT16 partitiion and communicating back to us via the filename of an empty .txt file.

btw. does the LED red/green provide any useful status information?

Attempt 1

This documents the state more or less before/while writing this entry. During that time I tried something else whic possibly bricked the device completely (See Attempt 2)

State

Current state: device is "bricked" (NOAPP.TXT), bootloader acticve, so it seems at one point it was trying to install the firmware, which gives me hope that I need a tiny step.

Linux

This is my machine, all others are just borrowed from friends so it would be best if it worked here ;)

Plugging it in:

[642986.667705] [T25958] usb 3-1: new full-speed USB device number 61 using xhci_hcd
[642986.809438] [T25958] usb 3-1: New USB device found, idVendor=0483, idProduct=002a, bcdDevice= 2.00
[642986.809449] [T25958] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[642986.809453] [T25958] usb 3-1: Product: AIR01
[642986.809455] [T25958] usb 3-1: Manufacturer: FNIRSI
[642986.809457] [T25958] usb 3-1: SerialNumber: Í«,4\¼U\xc2\x9c\x0fA
[642986.811984] [T25958] usb-storage 3-1:1.0: USB Mass Storage device detected
[642986.812792] [T25958] scsi host0: usb-storage 3-1:1.0
[642987.839155] [T25230] scsi 0:0:0:0: Direct-Access     AIR      DETECTION 1.0         PQ: 0 ANSI: 2
[642987.840017] [T25230] sd 0:0:0:0: Attached scsi generic sg0 type 0
[642987.845029] [T25601] sd 0:0:0:0: [sda] 51200 2048-byte logical blocks: (105 MB/100 MiB)
[642987.845367] [T25601] sd 0:0:0:0: [sda] Write Protect is off
[642987.845373] [T25601] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[642987.845544] [T25601] sd 0:0:0:0: [sda] No Caching mode page found
[642987.845547] [T25601] sd 0:0:0:0: [sda] Assuming drive cache: write through
[642987.869320] [T25601] sd 0:0:0:0: [sda] Attached SCSI removable disk

fsck seems to find some oddities:

fsck.fat 4.2 (2021-01-31)
FATs differ - using first FAT.
Cluster 0 out of range (255 > 12). Setting to EOF.
There is no label in boot sector, but there is volume label 'GC01 BOOT' stored in root directory
1) Copy volume label from root directory to boot sector
2) Remove volume label from root directory
[12?q]? 2
Reclaimed 1 unused cluster (8192 bytes).

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 1
/dev/sda: 2 files, 0/11 clusters

this may or may not explain the problem of the other sytems to properly mount it.

After mounting it, there is a Readme.TXT ... when I then copy the firmware file radpro-fnirsi-gc01-ch32f103r8-2.0.1-install.bin to it, umount and mount again, it will show UNKNOWN.TXT as if it does not recognize the firmware file.

Do we know exactly what the bootloader is looking for? I know from some chinese devices that they sometimes look for special magic bytes, some signature or even an exact location on the FAT16 device by block ( and don't really understand the filesystem)

Win11

USB 2 Port.
It seems to detect something, asks me to fix/format it but then nothing else happens. Same AIR01 device as on Win10 shows up.

Win10

Only has USB3 capable ports.

An "AIR01" device appears in the "Devices and Printers" section of windows but no drive. diskmgmt.msc does not show any volume/device without assigned drive letter.

The dialogue of the AIR01 device at one point talks about it not working because a secondary device has an invalid hardware identification number, no idea what that one means.

Looking at the windows eventlog at one point I find a message "USBSTOR too many separators"

Android

Upon plugging the device in (USB C to C) android tells me that there is something wrong with teh device and it needs to be formatted which does not succeed

Attempt 2

While writing this entry another thing to try under linux came to my mind, which now seems to have left the device in a bricked state at first glance.

Linux

One thing came to my mind: when copying the file, it is not using the 8.3 naming convention. So I mounted the device as -tmsdos which prevents that to happen and renamed the file to something with .bin.

This seems to do something, but either I was too impatiend or that went wrong for other reasons, the device no seems bricked.

After that whenever I plug it in (irregardless of what buttons I have pressed ):

[644028.635635] [T26216] usb 3-1: new full-speed USB device number 79 using xhci_hcd
[644028.758931] [T26216] usb 3-1: device descriptor read/64, error -71
[644028.992202] [T26216] usb 3-1: device descriptor read/64, error -71
[644029.222105] [T26216] usb 3-1: new full-speed USB device number 80 using xhci_hcd
[644029.345545] [T26216] usb 3-1: device descriptor read/64, error -71
[644029.578859] [T26216] usb 3-1: device descriptor read/64, error -71
[644029.685838] [T26216] usb usb3-port1: attempt power cycle
[644030.092381] [T26216] usb 3-1: new full-speed USB device number 81 using xhci_hcd
[644030.092645] [T26216] usb 3-1: Device not responding to setup address.
[644030.299014] [T26216] usb 3-1: Device not responding to setup address.
[644030.505541] [T26216] usb 3-1: device not accepting address 81, error -71
[644030.505703] [T26216] usb 3-1: WARN: invalid context state for evaluate context command.
[644030.628815] [T26216] usb 3-1: new full-speed USB device number 82 using xhci_hcd
[644030.628972] [T26216] usb 3-1: Device not responding to setup address.
[644030.835891] [T26216] usb 3-1: Device not responding to setup address.
[644031.042147] [T26216] usb 3-1: device not accepting address 82, error -71
[644031.042301] [T26216] usb 3-1: WARN: invalid context state for evaluate context command.
[644031.042390] [T26216] usb usb3-port1: unable to enumerate USB device

Removing the battery seems to resolve this somehow. Plugging in the battery seems to start some code, causing the usb to not work anymore, so the only option left now is trying to get it to work without the battery possibly?

I would think that at this point there is some other code than the bootloader running which is unable to properly identify as a USB device.

I just now noticed that there is a reset button which seems to make this easier to not have to unplug the battery all the time...

Trying to install the original flash this way failed too.

So what I am really wondering:

• What is the real trigger in the bootloader to start copying the firmware file?
• What is is the requirement for the bootloader to recognize the data?
  • Does it need to be at an exact sector?
  • Does it need vfat extended names? or supports only 8.3 names?

At the moment I also sometimes get ERRAPP.TXT ... do we know the exact circumstances of these error filenames?

Win 10

Windows gives an error message that it failed to provide a hardware ID

[gc01noob]

here's a trick to make your life much easier:
forget Windows 11
use Linux
connect the device and power on
open the BOOTLOADER mounted drive
copy over the new firmware
(nothing will happen but leave the window open)
drag/copy over the same firmware file again
OK the overwrite
your device will now boot with the new firmware installed

don't ask me why but it just works :)

ps. you can use Windows for GeigerLog-RadPro if you like, it's fine with the COM hardware but ignores the USB mount.

[dc1rdb]

Thanks for this great tip! The bootloader of my GC-01 was not accessible under Windows 7/10/11.
So I connected my GC-01 to a Raspberry Pi running Debian Buster and the bootloader drive showed up with READY.TXT.
After copying the 2.0.1 firmware file via drag and drop (had to do it twice, too), the GC-01 rebooted with the new firmware!

[denka977]

I am currently trying to flash my Fnirsi GC-01 with the same chip CH32F1. Windows XP and 10 see the device only as AIR01, I managed to mount the Fnirsi drive from Ubuntu, but the first attempt at flashing resulted in the dosimeter not turning on. I have already tried to load the firmware file through the console (sudo cat /home/ubuntu/Desktop/123.bin | sudo tee "/media/username/GC01 BOOT/whatever.bin" > /dev/null). The firmware file successfully appears on the dosimeter's drive, but there is no effect - it does not turn on. Classic drag-and-drop of the file also does not lead to anything, and the file cannot be rewritten (not enough memory). Repeated use of the console when rewriting the firmware does not give errors, but the dosimeter still does not turn on. At different times I see such files on the drive: README.TXT, UNKNOWN.TXT, APPERR.TXT. Is there any hope to flash the dosimeter without a programmer?

[PlasmaHH]

I am currently trying to flash my Fnirsi GC-01 with the same chip CH32F1. Windows XP and 10 see the device only as AIR01, I managed to mount the Fnirsi drive from Ubuntu, but the first attempt at flashing resulted in the dosimeter not turning on. I have already tried to load the firmware file through the console (sudo cat /home/ubuntu/Desktop/123.bin | sudo tee "/media/username/GC01 BOOT/whatever.bin" > /dev/null). The firmware file successfully appears on the dosimeter's drive, but there is no effect - it does not turn on. Classic drag-and-drop of the file also does not lead to anything, and the file cannot be rewritten (not enough memory). Repeated use of the console when rewriting the firmware does not give errors, but the dosimeter still does not turn on. At different times I see such files on the drive: README.TXT, UNKNOWN.TXT, APPERR.TXT. Is there any hope to flash the dosimeter without a programmer?

The bootloader is quite fiddly, it waits for a specific sequence of streamed data into a file. so far the most successful for me is to just use plain cat with output redirection in a shell (that has the sufficient permissions) into a new file. Never worked with using tee.

[PlasmaHH]

Just saw something: the downloadable file under assets (radpro-fnirsi-gc01-ch32f103r8-2.0.3-install.bin) is a couple of bytes bigger than the radpro-fnirsi-gc01-ch32f103r8-2.0.3.bin shipped with the flastool zip. At least in my tests these extra bytes seem to irritate the bootloader ( which afaik checks a few things like size, checksum etc. about that image) ... so only the smaller file in the zip file works for me

[HFDave]

This time, I have tried everything from this thread plus combinations. Nothing has worked for me yet.

In the past, I managed to flash all the previous versions using different methods. I think I used Windows box the first time, but since then, I was using linux and the double copy/rewrite trick. So when I saw there is a fresh version, I happily went to update my device. And it went straight to bricked mode (device descriptor read/64, error -32).

It wasn't for the first time so I knew what to do. I am repeateble able to somwhat unbrick it using the battery or the reset button method. I mean I am able to mount the "GC01 BOOT" drive again and keep trying, but I am not able to even revert to 2.0.2. So the device is not bricked completely, but yeah, it is not functioning anymore.

Whatever and however I upload a firmware, it refuses to accept it and reboot on its own. Everything was working perfectly for me up to 2.0.2. So, it is a kind of roulette...

[gc01noob]

I used Gnome/Wayland on Ubuntu 22.04. It mounts to /media/username/BOOTLOADER

I think it does a cat as part of the drag/copy process to check what files exist and hence prompt for overwrite, if I remember correct normally a basic cp command just fails or requires a /f to force an overwrite if there's a name conflict

great news you got it working, weird bug but at least we have a workaround now. win-really-blows.....but RadPro is great

[ugopapetti]

Hi,

I have no more a running bootloader working with my Win10 PC.

I have lost it because while updating the GC-01 sw (apm processor) I connected usb, powered on GC-01, then tried to power it off, with no success, then forced detach of GC-01 drive inside Win10, disconnected the USB cable, pulse led still on with dim red light.
Tried on-off of GC-01 with no effect,
Only way to power off was by pressing the reset microswitch close to GC-01 usb.
Reconnected to usb, no way to get back to bootloader.

Connected to an old Lubuntu, copy-paste SW on bootloader, write a second time, and then SW loaded / running.

Reconnected to Win10pc and bootloader is no more visible, i.e. when you power on the USB-connected GC-01 it simply powers on, without entering in drive mode (just a new serial port opens).

Reconnected to Lubuntu, bootloader drive reopens as expected and updates could be executed.

First of all, Thanks a lot for the Linux-double write trick.

Does somebody know how regainin access to bootloader with windows? In the meanwhile, will try to execute the process with a different Win10 PC, will let you know the result.

Tnx ugo

[PlasmaHH]

your last resort is always attaching an swd debugger...

[renatogmac]

Got my GC-01 bricked for a long time, nothing worked, UNTIL I SAVED IT with this:

• Windows 10/11 environment
• Disconnect the battery
• Connect device with STLink (GND, Vcc 3v, CLK and DIO wires)
• Install STM32CubeProgrammer, and connect to the device, try read something and you´ll get an error
• HERE IS THE TRICK: Disable read protection, disable write protection and Apply
• Try read something, now it works, no errors
• Disconnect and close STM
• Download radpro-flashtool (latest version) and extract it all on a folder
• Open it, Select the folder corresponding to your device, select the .bat file corresponding to your MCU, and run it
• Well, it´s done!!! Unplug device from STLink, reconnect the battery.

It doesn´t amtter what you do nor how many times you do, while de flash memory is read protected and/or write protected, nothing gonna work. Disabling read/write protections using STM32 is the trick.

[Gissio]

Thanks for your report.

The radpro-flashtool of the upcoming release (2.1.1) should remove the protections and make this much easier!

[tadawson]

For those of us not using a dumbed down, useless file manager on Linux, I found that mounting the device (/dev/sdc in my case) at /mnt, and then "cp <the .binfile> /mnt, cp /mnt, umount /mnt" worked. Note that Linux mounts are buffered, and the cp writes to the buffer of the physical device - the umount forces the write to the hardware. (sync could also do this, but using sync leaves the GC-01 mounted, and would always return to the "Ready.txt" condition, but not come up.) Dropping the mount worked on the first try. FWIW . . .

[gc01noob]

oh you must be so clever, typing instead of using a simple and excellent GUI interface to copy a single file......fyi you are using the same commands(excluding the > you missed, and typing "ot" instead of "of") that the GUI does....but of course you obviously know it all..... (fyi there's a good chance other important devices may be using the /mnt folder so best to specify it exactly in a subfolder of /mnt and some secure distros require root to mount there too, but of course you wouldn't be logged in as root now would you (sudo cp xyz.bin /mnt/gc01 would be the actual command to use twice) - most GUIs do this automatically and safely for USB devices in the /media folder and when the device reboots it automatically unmounts, btw it's the second copy that forces the direct write)

btw if you are going to try and sound smart, at least try spelling "manager" correctly so you don't look like an arrogant smart-ass that can't even type English properly "mangoer" isn't a word......

[tadawson]

My point is simply that those who state to use a GUI are not necessarily correct, that the buffer flush may well be the "key" (never heard that mentioned, and may be what the dual write is forcing) and that I hate touch keyboards. And (depending how you mount, and have fstab setup), root privs may not be necessary (and I assume that a *nix user knows when to use them, so don't waste my time typing "sudo" where root privs should be obvious).(Personally, I have no use for sudo either . . . been using *nix systems close to 40 years professionally, predating it (sudo) by a huge margin. Granted, Linux isn't Sys-V or BSD, but overall function in the kernel/filesystem is very similar, and I have been trained on internals at the source code level, so will wager I hwve a damn fine grasp of how it works . . . and you?)

I don't automount either, so the subdir nonsense to /mnt is irrelevant as well . . . please do not dare to presume how my distro works or how I work - you will likely embarrass yourself . . . badly . . .

Oh, and "it's the second copy that forces the direct write" is also trivially disprovable. I can copy 3 or 4 times, and no reaction until a sync is forced either via umount or the sync command. The system buffer cache is far bigger than the firmware. (That might be an artifact of some file manager, but it wasn't when I tried Dolphin . . . hence the additional testing, and continued abandonment of the GUI.)

And "excellent GUI"? Dude, seriously, what are you smoking? Both ways work, and very often the cli is far faster . . . For that matter, in all the years Inhave worked on servers in major ckients, it's pretty rare to have a GUI on a box at all . . . so knowing the cli is critical. Cli skills work anywhere, but good luck with just GUI skills on a server with nothing but a terminal session available . . .

Do what works, I honestly don't care . . .

And I'm not the one so insecure as to be bleating about what many may consider useful information, simply because of a few touchscreen induced typos, and rushing on my part . . .

[HFDave]

For those of us not using a dumbed down, useless file manager on Linux, [...]

It is not a universal solution. I have tried things far beyond your endeavour without any success. Initially, all methods were working for me with the early versions. Copying the file in the GUI, then doing it twice... it worked until it all stopped. After that, nothing helped. I tried the command line, copying, syncing, cating the file to the target, overwriting, checking checksums, unmounting, of course, and trying various versions, including the one pulled from the ST-LINK flashing package, etc. So, do not think that you have found "the solution" just because you succeeded once (or a few times). It is somewhat random. In the end, once it suddenly stopped cooperating, I had to use ST-LINK and wait for the 2.0.3 release.

[tadawson]

I can't argue with that . . . all I know was that I was having zero luck with any "published" procedure (despite multiple attempts - I got the "READY.txt" status, and a black screen). I tried what I described and it instantly worked, so figured I'd pass that along, since despite long hours of reading docs and forums, never heard that suggested. Granted, and single data point, but might help someone . . . (This was tried with 2.0, 2.0.3, 2.1, and 2.1.1, and all behaved similarly, fwiw . . . 2.1.1 finally worked, so did not retry, since it was up).