Closed mozzwald closed 3 years ago
I have flashed v1.3 hardware (NUC+Daughterboard) successfully on Windows and macOS, not tried it on linux but I suppose I could. Not had any issues once I'd fixed any "hand soldered motes of dust" issues.
If you want to send me a non working one to test, I'm game. If it's only two users it sounds like a them issue, not a you issue, I can try it on various bits of hardware and cabling and see if I can get a fail.
I have flashed v1.3 hardware (NUC+Daughterboard) successfully on Windows and macOS, not tried it on linux but I suppose I could. Not had any issues once I'd fixed any "hand soldered motes of dust" issues.
If you want to send me a non working one to test, I'm game. If it's only two users it sounds like a them issue, not a you issue, I can try it on various bits of hardware and cabling and see if I can get a fail.
One user has received 2 v1.3 units from me that both flash ok on my end and they cannot flash either one. They also have a v1.0 which flashes fine with the same cable/computer. As mentioned, removing the capacitor allows it to sometimes flash meaning we might be able to fix this in hardware. The new wrover-e is supposed to have a silicon fix related to this issue and there may be too much capacitance. I shipped another board yesterday with 0.1uF cap and 10k pull up resistor on EN and will wait to see the results.
Better to make it work now for everyone than after "one billion served" :D
I gained access to a Windows 10 laptop today that exhibited the same problem flashing. After some digging through the CP2102N datasheet I found that v1.3 does not have VIO connected to VDD and it should be. This is likely causing the CP2102-QFN24 to be unstable during reset. I'm not sure why it affects certain computers and not others. This issue is not present in v1.0 FujiNet since it used the QFN28 chip which does not have VIO. A Fix for v1.3 boards is to make a solder bridge on pins 5 and 6 of U2. I have added an image of the bodge to make it work on v1.3 boards in the wild now:
Fixed in 57ebe4f
Reopening until the fix is confirmed by another user with the problem. It worked for me but another user still cannot flash after applying the solder bridge.
How about thinking around the issue? Why not implement OTA or SD based firmware updates then there's no need for the bugfix
Does the person who still has the issue also have a problem with a 1.0 board?
Basically? We didn't do that because that obliterates half of the flash space (you have to essentially keep two copies of the same image on the flash)
-Thom
On Fri, Jan 15, 2021 at 6:17 PM MrRobot notifications@github.com wrote:
How about thinking around the issue? Why not implement OTA or SD based firmware updates then there's no need for the bugfix!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-hardware/issues/5#issuecomment-761269832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZVCKDGFKOGB5SDVSHTS2DLH7ANCNFSM4V6PWUXQ .
Does the person who still has the issue also have a problem with a 1.0 board?
Nope. The v1.0 works absolutely fine.
After some more troubleshooting we've got the v1.3 bodge working except on two different Windows 7 home premium machines. They were able to flash using ubuntu and windows 8.1 and the bodged unit.
You have to have two partitions but is it possible that they don’t have to be the same size?
You could have a small partition that just contains the SD flashing code and another partition that could contain the fujinet system.
Put a file on the SD card, power up with the flash button pressed and have the ESP boot the flash partition which reads the file on the SD card and flashes it to the other partition, then resets itself and boots the main, now updated, partition. I don’t know how big the code to see the SD + flash would be, but it has to be a lot smaller than the whole of the fujinet code.
On Jan 15, 2021, at 18:24, Thomas Cherryhomes notifications@github.com wrote:
Basically? We didn't do that because that obliterates half of the flash space (you have to essentially keep two copies of the same image on the flash)
-Thom
On Fri, Jan 15, 2021 at 6:17 PM MrRobot notifications@github.com wrote:
How about thinking around the issue? Why not implement OTA or SD based firmware updates then there's no need for the bugfix!
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-hardware/issues/5#issuecomment-761269832, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVBYZVCKDGFKOGB5SDVSHTS2DLH7ANCNFSM4V6PWUXQ .
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-hardware/issues/5#issuecomment-761271720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADDUPYQXGQMUZJ2PRH7HLS2DMFHANCNFSM4V6PWUXQ.
Pin 4 & 5 or 5 & 6??
Pin 4 & 5 or 5 & 6??
Typo fixed. It's pins 5 & 6
Confirmed that this fixes the issue for at least 3 users and in my testing. Closing
Reopening.. again.. I missed an important note about the need for a resistor divider on VBUS. While the VIO bodge seems to fix the issue for most users there are likely situations where flashing will not be possible. One user can still not flash with Windows 7 but it now works on their other systems. I will be sending them another bodged unit for testing.
page 8: https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf
Of interesting note is that the v1.0 with QFN28 seems to be more reliable with this issue than the QFN24 used on v1.3. The v1.0 board works on the Win7 machine mentioned above.
Image of the fix done to add the resistor divider on the v1.3 board: https://github.com/FujiNetWIFI/fujinet-hardware/blob/master/FN32ROV-1.3-Q24/CP210x_RESET-BUG_FIX_2.jpg
Well, #$%^&*( me.
On Jan 24, 2021, at 12:39, mozzwald notifications@github.com wrote:
https://github.com/FujiNetWIFI/fujinet-hardware/blob/master/FN32ROV-1.3-Q24/CP210x_RESET-BUG_FIX_2.jpg https://github.com/FujiNetWIFI/fujinet-hardware/blob/master/FN32ROV-1.3-Q24/CP210x_RESET-BUG_FIX_2.jpg
Well, #$%^&*( me. …
Yeah, it's a chore. It might be alright to just do the solder blob fix. That has fixed all but one of the problem units so far.
Does the divider fix the issue? is this final and has the schematic been updated? Here's my schematic change and updated pcb
Image of the fix done to add the resistor divider on the v1.3 board: https://github.com/FujiNetWIFI/fujinet-hardware/blob/master/FN32ROV-1.3-Q24/CP210x_RESET-BUG_FIX_2.jpg
Holy hell!?! That is a lot more than a simple bodge. Ugh, I knew I should not have gotten so many of these boards.
Does the divider fix the issue? is this final and has the schematic been updated? Here's my schematic change and updated pcb
The windows 7 user has not received the replacement yet so I cannot confirm.
This is my updated schematic. I've added and changed the capacitors and added the resistor divider for the CP2102. Also, have added pull up resistor (R17) for SIO_DATAIN as suggested by BigBen.
I was able to get a Windows 7 computer that could not flash any newer FujiNet I plugged into it and this process worked every time:
It's worth noting that v1.0 was able to flash fine on this same computer. Any version I tried v1.2 and up required the use of the above procedure. v1.2 added the open collector buffers for the SIO bus but I'm not sure how this relates to the issue and why it's only affecting some computers/operating systems. Also of note, I made two v1.4 pcbs, one with the qfn24 and another with the qfn28 variant of the CP2102 which made no difference; they both exhibit the same problem.
I'm considering this issue closed as the above workaround should cover anyone with problems. I will leave it open until I finalize the v1.4 files and release them.
This is amazing! This is with or without the hardware fix?
Dr. Marlin “MacRorie” Bates, IV The Brewing Academy https://www.thebrewingacademy.com/
On Feb 12, 2021, at 6:09 PM, mozzwald notifications@github.com wrote:
I was able to get a Windows 7 computer that could not flash any newer FujiNet I plugged into it and this process worked every time:
Plug FujiNet into computer with MicroUSB cable Run FujiNet Flasher Select COM port of FujiNet device Click "Flash FujiNet Firmware" and immediately press and HOLD button A Continue holding button A until you see "Erasing flash (this may take a while)", then release button A Wait for it to finish flashing and you're done It's worth noting that v1.0 was able to flash fine on this same computer. Any version I tried v1.2 and up required the use of the above procedure. v1.2 added the open collector buffers for the SIO bus but I'm not sure how this relates to the issue and why it's only affecting some computers/operating systems. Also of note, I made two v1.4 pcbs, one with the qfn24 and another with the qfn28 variant of the CP2102 which made no difference; they both exhibit the same problem.
I'm considering this issue closed as the above workaround should cover anyone with problems. I will leave it open until I finalize the v1.4 files and release them.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.
This is amazing! This is with or without the hardware fix?
Without the hardware fix it worked for me, YMMV. If you are shipping 1.3 hardware you should apply the hardware fix. Hardware fix is updated in the repo
I see it changed again. I do not mean this to be disrespectful in any way shape or form, I know it is a major pain. Do we know when the fix will be finalized?
-M
On Feb 13, 2021, at 18:44, mozzwald notifications@github.com wrote:
This is amazing! This is with or without the hardware fix?
Without the hardware fix it worked for me, YMMV. If you are shipping 1.3 hardware you should apply the hardware fix. Hardware fix is updated in the repo https://github.com/FujiNetWIFI/fujinet-hardware/blob/master/FN32ROV-1.3-Q24/CP210x_RESET-BUG_FIX_FINAL.jpg — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FujiNetWIFI/fujinet-hardware/issues/5#issuecomment-778712455, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASOU24T2JG6NKTX62VZGTT3S642ITANCNFSM4V6PWUXQ.
Do we know when the fix will be finalized?
I'm waiting for some users to receive units for testing.
The hardware fix has been confirmed working by the windows 7 user.
Works fine on my Macbook Pro as well.
Worked for me with 1.3 and MAcOSX Mojave (though it is written that flasher is for Catalina). I have kept rightmost button C (reset). Button A does nothing. Did not work with 1.0.
However, this cannot be closed until this "problem" turns into "feature" and is mentioned in oficial upgrade procedure. I have spent 3 evenings on this trying various configurations and three operating systems, asking people and nobody knows etc.
Worked for me with 1.3 and MAcOSX Mojave (though it is written that flasher is for Catalina). I have kept rightmost button C (reset). Button A does nothing. Did not work with 1.0.
However, this cannot be closed until this "problem" turns into "feature" and is mentioned in oficial upgrade procedure. I have spent 3 evenings on this trying various configurations and three operating systems, asking people and nobody knows etc.
And you made the changes suggested in the fixes? added and change the caps as well as the bodge wire?
Hello! I have seen no mods for Fujinet 1.0, maybe I have missed something... I have seen mods for 1.3, QFN24 CP2102, but not for 1.0. However, 1.0 still does not upgrade, but I'll check local Fujinet oriented friend yet.
Hello! I have seen no mods for Fujinet 1.0, maybe I have missed something... I have seen mods for 1.3, QFN24 CP2102, but not for 1.0.
Try replacing R3 & R4 with 10K resistors and report back here if it works or not.
Thanks for tip. For now they are 1k. I'll check 10k today evening.
Hello, Unfortunately, after resistors change, still does not upgrade.
Oh, I am sorry, I thought you were talking about the rev 1.3 that has known flashing problems. I haven't had any with 1.0. I am sorry that I was confused.
Hello, Unfortunately, after resistors change, still does not upgrade
Have you tried flashing multiple USB cables and with a different computer?
Before you plug the FujiNet into computer, hold button A. After plugging in, all 3 LEDs should be dimly lit. Then try flashing procedure.
The same cable and the same computer flashed 1.3, but does not want flash 1.0. I have tried several times... The effect is identical like in the movie I have sent you the link to.
BDW, I have swapped ESP32 boards to be sure they are good, and on 1.3 board upgrade ok (with one error with ack, but second time wen OK), but on 1.0 did not.
I have soldered SJ1, just to be sure the switch is ok.
There is a difference between 1.3 and 1.0 - 1.3 has soft reset button which 1.0 does not have, an that button when pressed causses upgrade to run OK.
I have decided to go to my friend that uses the same version and upgrade of 1.0 works under linux for him. Just to be sure.
Thanks for help, unless you have more tips I could do or I miss something. The board looks good, the resistors are consistent with schematics... The board works but... is upgraderesistant.
I have tried 3 different oses (Win10, linux and OSX Mojave) on 3 different computers, two cables of hi quality. About 1.3: you say press and hold button A (Flash) - does not work; when I press and hold button C (Soft Reset) - flashing works. 1.0 is tough as a concrete :/ But let's leave it for now, I'll check another CP2102 chip.
I must get used to that emails go here automatically :)
SUCCESS! I have bought cheap USB-RS232 converter with CP2102 onboard and switched chips. Then flashing begun to work finally! So I confirm, that pressing A button during flashing works with FujiNet 1.0 Pressing C button during flashing works with Fujinet 1.3.
Thanks for help!
However, those instructions should be included in official flashing procedure.
Two users of v1.3 hardware are unable to flash their devices from Windows or Mac computers. Both units were flashed multiple times on my Linux computer before shipping. Replacement units have the same problem. Removing C2 improves likelihood of getting successful reset for flashing. I am investigating component changes.
More info here