Gissio
FNIRSI GC-01: Can’t power on while charging from USB
version 2.1 is nice on a gc01 APM32F103RBT6 (Geehy) / CL24CG1045-40B screen and modified to have a j321b tube i installed it the old fashion stlink way
after i updated it , tested it , i had it charge a bit in off state on a usb charger, i noticed it cant be powered on if its connected and off. works fine as soon as its not connected ( it seems to go in some kind of DFU mode right after boot , i see the radpro 2.1 splash, the cumulative screen and then the screens goes blank like its off , the buttons do nothing the light under is red , i can powercycle again but it does the same thing )
if i power it on , and connect it to the usb power its stays on fine , just like normal usage. i cant recall this happening and i wouldve notice on previous version , hense me reporting it even if it doesnt really hinder the usage and can work around it.
beside that pretty solid release !
cheers ! i appreciate your work a lot
sure , hope it links yt , https://youtube.com/shorts/Ge16XsF889M?feature=share
feel free to let me know if you want me to test a revision, or any debug procedure that might benefit you cheers hope it help
Confirmed with my Geehy GC-01. But the issue only shows with "intelligent" chargers, like Quick Charge capable devices. If charging from a plain USB 5V source, the unit turns on as expected.
ok i tried the cheapest 1A charger i have and indeed it doesnt exibit the problem,
the first usb charger i used isnt those super fast charge , it a midrange motorola 5v 2a ... (not a 2.1) it does fast charge but i believed ive used it before and didnt do this.
ive tried the second faster charger i have samsung 5v 1.55a that i definitely used with the device before and it does the issue .
seems only the cheapest 1a works without causing this . first time i have a problem like this with them, always knew 2.1a were problematic on some machines , but never these ones ...
so noted ill keep using the 5v 1a instead then ( or keep using the fast charge as this is very minor inconveniance in a specific case)
cheers!
It’s likely that the charger is not interacting well with the libusb_stm32 library I’m using for USB communication. Unfortunately, I don’t have such a charger, so I can’t test this myself.
Maybe some kind soul familiar with STM32 and USB can offer some assistance?
since i know edgetx handles the power adaptor properly with stm32f4 and a whole array of stm radios, i went and look if it uses libusb-stm and they use a version of libusb and tinyusb , ive been trying to find the difference between the two code ( radpro and edgetx ) . seems they have a routine to unload the power registers but i havent made much sense of it or if thats when its in dfu or when its flashing, or low power debugging . but theres a large difference with usb and pwr codes
i will admit this is a steep curve for me , i would love to make sense of both projects usb power management , this is lowlevel newgrounds for me. will keep trying to figure this out
i think i would gladly send you that samsung ep-ta50jwe 5v 1.55a adaptor i have , but maybe if i can talk about this with the dev of edgetx that might streamline a solution
ok im prepared to make another video if necessary as i have been able to to further hardware testing of cables and chargers with a yojock usb digital tester model J7-C . but ill type it here first and see if its necessary
-------- the hardware -------- still testing the samsung power adaptor ep ta50jwe 5v 1.55a also a motorola mc-101 sa18c82741 10w 5v 2a and a cheap apple a1385 5v 1a
one 8bitdo 85he retro keyboard ibm edition usb cable (170cm long) one 8bitdo 85ha retro keyboard c64 edition usb cable (170cm long) and one cheap power only redlink usb charge usb cable (15cm long)
-------- diving into tesing -------- 1- using the redlink power only usb cable - doesnt exibit the problem on any of the charger , so power cable only have it work on everything . ill put it aside
2-oddly enough one of the 8bitdo cable actually works on all chargers , i think its my newer c64 edition one
3-while the other ibm edition one have this problem with the samsung and motorola.
-------- preconclusion and a bit of what the tester spewed out -------- ok so this could just be a cable problem , ive notice on the meter that both dont have the same resistance the problematic one has a resistance of about ( 0-54 unpowered ) 27~30 up to 113 ~ 124 ohm when powered
the one that does work has a resistance of a more solid (0-36 unpowered ) 50 - 130 - 150 up to even 240 ohm when conneected
whats super odd is when all goes through the tester all cable works on all chargers and the cg-01 doesnt crash after the splash
ok so that might confirm its more of a (not even 4 months old or so) cable that defective or temperamental for some odd reason , perhaps one of my cats got to it when i had my back turned or just having it mechanically worked more than my newer c64 i got not even 2 months ago .
i went and look at the tester resistance about the power only redlink cable and it says 30 ~50 ohm off and about 50 ~77 ohm when on.
when back again to test resistance of the defective and good one and they both exibit about the same resistance , not as low as before . so i cant really tell the testers ohm test ( as it fluctuate when charging ) whats the complete deal with this cable .
-------- my conclusion from this -------- you might want to close the issue , and keep it in mind that some cable / power devices / or even chained testers can affect this ( in positive or negative way ) lil weird bug that doesnt happen on other stmf4 devices i have with screens , this might just have been a cable aging and not 100% charger or even libusb-stm issue.
cheers gissio , might still help others or you to have reported this but i would call it closed/resolved as this works pretty well one mintier cable .
if the colour of both cables werent so similar i couldve seen this earlier but when i first tested this i mightve just connected the same one . i was sure i tested both properly.
have a good one and long live to your project
-n
ps i find it so weird that all cable when going throught the tester thats supposed to be passive , actually have the defective cable not do the bug !
In case you have a USB debugging tool: it would be tremendouly helpful to know what data traffic is moving between the charger and your Geiger counter.
It seems the FNIRSI GC-01 is getting a lot of USB traffic, which could explain why the screen updates so slowly.
ill see what i can do . forgot to say the tester showed me the protocol was QC2.0
you sure its not just the cable that getting quick aging ? since the other exact one the device works perfectly as it should. ill agree with you a debuging tool might show us for a fact. ill get back to you on this .
cheers
about the screen updates slowly : the splash comes in quick in any cases , just when it crash it crashes for good , but i didnt see it or would refer to it "as slow"
one other thing i didnt think of testing is using the cable as input to the tester and not just the output , anycase ill gather more tools and info that might help
ok thank you for the specification , im looking into code to turn my stm32 devel board or esp32s i have to make one.
meanwhile i tested in reverse the (output to input) the problematic cable has a 0.1-0.2v fluctuation at most, but 4.99v on v+ , and exibit the same problem as without the tester , while the good one is stable, and like before works like a charm and a solid 5.01v on v+.
bit hard to extrapolate all states of d+/- and vc+ when i power the defective cable vs the good one so im on looking into turning one of my board into a usb debugger.
according to the joyock tester's manual what i just tested is what they define as not an optimal cable between the two and it stops there . current seem stable and that according to the manual says the power stable and performing
still curious what a usb debugger would show compared to this
whoa didnt realise i could use the j7-c i have as a signal analyser , im sorting this out to use sigrock on the cg01
darnit , the board has the antenna but not the bl chip , might take me two week or so to get the proper one . ill try to populate it eventually as returning a 20 bucks thing will probably cost me half of it , and for the purpose of a sure shot test im getting a fully populated one. im tempted to try it sigrok directly on the uart but im not sure how this will play out .
noticing a few things messing with all this already , low voltage protection being one , i wonder if thats whats kicking in on the defective cable making it work in the case i elaborated earlier... but ill stop procrastinating and really see with sigview once it arrives.
cheers
I’ve found a timing issue in USB interrupts. Can you try https://github.com/Gissio/radpro/actions/runs/16640381355/artifacts/3655118583 ?
Havent have time to check into it , but i have taken note of this and will report as soon as possible
On Fri, Aug 29, 2025, 11:41 p.m. Gissio @.***> wrote:
Gissio left a comment (Gissio/radpro#211) https://github.com/Gissio/radpro/issues/211#issuecomment-3238911286
Does this issue still occur in 3.0?
— Reply to this email directly, view it on GitHub https://github.com/Gissio/radpro/issues/211#issuecomment-3238911286, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6NZVBXUT3DMTUBDJBQMHDT3QEMP3AVCNFSM6AAAAABXKQPHJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZYHEYTCMRYGY . You are receiving this because you authored the thread.Message ID: @.***>
I did some troubleshooting: From what I gathered, the issue is with the USB data lines being shorted or almost shorted when booting the gc-01.
I got some captures of the D+(blue) and D-(yellow)
Both are low if nothing is connected and it is off.
If it's on and nothing is connected, D+ goes high
During startup (nothing connected) D+ gets pulled high, low and then high again by the gc-01 while D- stays low.
If we now connect a charger with a cable that has data capability to a charger that does more than 1A, D- gets pulled high :
If the same type of charger is connected first, while the gc-01 is off, D+ and D- are being pulled low, but during startup D- now follows D+:
Every time that D- goes high during startup, the Bug appears and it shuts off. I replicated it also by directly shorting D+ and D- while applying 5V without any other connection.
To circumvent this for now, use a USB cable without data lines (only charging). It is way harder to find a charger that does not short the data lines or pull them high.
While I was troubleshooting, I also analyzed the traffic on the cc-lines for USB-PD. I don't think it has to do with this bug, but In case, someone might find that useful:
Charger No. 1: A lot of messages from the charger advertising its specs and then:
0xFF00A001 from the gc-01 whether it was on or off
in case it was on, this message followed: 0xFF00A041 0x18000000 0x00000000 0x00000000 0x00048040
Charger No. 2: A lot of messages from the charger advertising its specs
0xFF00A001 Msg 1 from the gc-01 (on or off)
0xFF00A041 Msg 2 from the gc-01 (on or off) 0x18000000 0x00000000 0x00000000 0x00048050
I also captured the PD-protocol as a Waveform for further analysis if someone is interested.
The core of this problem maybe is that the USB detection logic of the libusb_stm32 library is incompatible with the electrical characteristics of certain chargers, causing the device to incorrectly enter DFU（Device Firmware Update） mode instead of normal operation mode during startup. The safe and conservative way is to charge the device while it is powered on, but there is also a way to modify the firmware code.
Actually theres a similar problem happenning with certain tx16s v1 on the edgetx project when hook to usb it goes in dfu. The dev knows theres a problem but cant figure out how to reproduce it.
Definitely we all tought a usb lib was in the wrong .. just nobody pinpoint it yet
N
On Sun, Oct 5, 2025, 10:58 a.m. Aurora Master @.***> wrote:
AuroraMaster left a comment (Gissio/radpro#211) https://github.com/Gissio/radpro/issues/211#issuecomment-3369113214
The core of this problem maybe is that the USB detection logic of the libusb_stm32 library is incompatible with the electrical characteristics of certain chargers, causing the device to incorrectly enter DFU（Device Firmware Update） mode instead of normal operation mode during startup. The safe and conservative way is to charge the device while it is powered on, but there is also a way to modify the firmware code.
— Reply to this email directly, view it on GitHub https://github.com/Gissio/radpro/issues/211#issuecomment-3369113214, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6NZVBULZ55BYAHRSNH45ND3WEWZJAVCNFSM6AAAAABXKQPHJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNRZGEYTGMRRGQ . You are receiving this because you authored the thread.Message ID: @.***>
Actually theres a similar problem happenning with certain tx16s v1 on the edgetx project when hook to usb it goes in dfu. The dev knows theres a problem but cant figure out how to reproduce it.
Definitely we all tought a usb lib was in the wrong .. just nobody pinpoint it yet
N …
On Sun, Oct 5, 2025, 10:58 a.m. Aurora Master @.***> wrote: AuroraMaster left a comment (Gissio/radpro#211) <#211 (comment)>
The core of this problem maybe is that the USB detection logic of the libusb_stm32 library is incompatible with the electrical characteristics of certain chargers, causing the device to incorrectly enter DFU（Device Firmware Update） mode instead of normal operation mode during startup. The safe and conservative way is to charge the device while it is powered on, but there is also a way to modify the firmware code.
— Reply to this email directly, view it on GitHub <#211 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/A6NZVBULZ55BYAHRSNH45ND3WEWZJAVCNFSM6AAAAABXKQPHJ2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNRZGEYTGMRRGQ . You are receiving this because you authored the thread.Message ID: @.***>
Add charger detection logic, check whether VBUS exists, delay and wait for the signal to stabilize HAL_Delay(50), check the status of D+ and D- signals, data connection characteristic differential signal, and then modify the startup timing, because if there is an ignorant problem in this code, the device can only be connected to USB in charging mode, and the wrong firmware cannot be updated again, which will make things a little embarrassing ：）Maybe
I also observed this problem with my Bosean FS5000 while connecting to a USB-C port on a Laptop.
Firmware: Rad Pro v3.0.2
PCB:
BSA
KL7.820.530A
@20221215 V1.01
As of 3.0.2 (sorry i couldnt test before). The problem i had is resolved. If the gc01 is off and i plug it in , i can power the unit attached no problem and use it now.
Im curious , what was changed about this as this might help something about the edgetx usb / pd management
Cheers love 3.0.2. process takes a nano second to update .
-n
I can also power from its off state from the powerblocks i used thar were problematic initially. I am also using usb with and without datalines and the unit doesnt shuts off anymore.
I tell ya for my unit this is completely resolved
What usb lib or related was touched i would really love to know?
thank you gissio
I'm glad it works now.
An error in the sleep() function caused USB interrupts to be incorrectly considered timer interrupts, so the CPU would overload as the sleep finished immediately.