Closed PUF52 closed 2 years ago
Bit depth of the system? 32 or 64
@PUF52 I cannot remotely connect to a computer for security reasons. I can connect to @PUF52 PC, if there is way to get any logs at all. Or list of what to try.
@PUF52 I don't know if it can help, try to put TS100_EN.hex to the root of C:\ drive before flashing. Maybe cyrillic chars interfere somehow? Try the same with blank.hex first maybe?
@PUF52 I cannot remotely connect to a computer for security reasons. I can connect to PUF52 PC if there is a way to get any logs somehow. Or what to debug. Is it possible to connect to TS100 GD32 DFU with regular micro-usb cable?
On Tue, Feb 08, 2022 at 01:22:13AM -0800, JugglerLKR wrote:
I can connect to PUF52 PC if there is a way to get any logs somehow. Or what to debug. Is it possible to connect to TS100 DFU with regular usb cable ?
Yes, you can take a regular USB cable, cut it and attach to an SWD debugger, see https://github.com/Ralim/IronOS/blob/master/Documentation/Flashing.md "On v2.51A PCB revision USB_D+ is shorted to SWDIO and USB_D- is shorted to SWCLK so debugging works without disassembly (attach while staying in the bootloader)".
On Tue, Feb 08, 2022 at 01:22:13AM -0800, JugglerLKR wrote: I can connect to PUF52 PC if there is a way to get any logs somehow. Or what to debug. Is it possible to connect to TS100 DFU with regular usb cable ? Yes, you can take a regular USB cable, cut it and attach to an SWD debugger, see https://github.com/Ralim/IronOS/blob/master/Documentation/Flashing.md "On v2.51A PCB revision USB_D+ is shorted to SWDIO and USB_D- is shorted to SWCLK so debugging works without disassembly (attach while staying in the bootloader)".
Thank you. I've seen this, but it requires SWD debugger hardware which we don't own.
On Tue, Feb 08, 2022 at 01:28:36AM -0800, JugglerLKR wrote:
Yes, you can take a regular USB cable, cut it and attach to an SWD debugger, see [1]https://github.com/Ralim/IronOS/blob/master/Documentation/Flashing.md "On v2.51A PCB revision USB_D+ is shorted to SWDIO and USB_D- is shorted to SWCLK so debugging works without disassembly (attach while staying in the bootloader)".
Thank you. I've seen this, but it requires SW debugger hardware which we don't own.
Just about any SBC (including raspberrypi) can bitbang SWD.
Does not help
Ralm, by the way, what version of Windows are you using when testing? Its rank?
I test on Windows 10 x64, Arch Linux and Manjaro Linux as my main "test" setups. For testing the new bootloader I verified everything on Windows as that is what I assume most people are running.
Honestly the most likely next steps are to use a debugger to read back out what is going on.
Short of that, there is another option, though it will take a bit of work if you are on windows.
So I've been working on IronOS-dfu after some poking from @discip.
If you are willing to download dfu-util
and use the command line, you could try using the RUNTIME (not bootloader) version of IronOS-dfu to (a) test flashing the .hex file and (b) take a backup of your bootloader.
Then you could email me the backup of your bootloader and I can load it here and try and reproduce your issue.
If you are willing to do this; you will need to download dfu-util and then follow these steps https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/BackUp.md
Guys, sorry for my illiteracy, but the thought that came to my mind is the problem is simpler - how to install firmware 2.16 from ralim on dfu3.48 with a gd32 chip? And any advice about the dfy-util debugger - it.d. they don't say anything to me.
Guys, sorry for my illiteracy, but the thought that came to my mind is the problem is simpler - how to install firmware 2.16 from ralim on dfu3.48 with a gd32 chip? And any advice about the dfy-util debugger - it.d. they don't say anything to me.
If you can flash runtime.hex from IronOS-dfu, then you will be able to access iron using dfu-util. Then you can flash TS100_EN.bin to the iron (I hope Ralim will be able to provide bin version too for you).
I told you that for me it is a "dark forest" and useless advice.
ok thanks wait
Guys, if you solve the problem, please write here
@Ralim would you please provide latest build for TS100_EN flashable with dfu-util? or can we try to flash included .dfu files in current release?
On Tue, Feb 08, 2022 at 06:14:21AM -0800, JugglerLKR wrote:
@.*** would you please provide latest build for TS100_EN flashable with dfu util? or can we try to flash included .dfu files in current release?
Did you manage to install DFU bootloader now? Great.
The latest version from master should include everything needed:
From https://github.com/Ralim/IronOS/actions/runs/1811536243#artifacts
On Tue, Feb 08, 2022 at 06:14:21AM -0800, JugglerLKR wrote: @.*** would you please provide latest build for TS100_EN flashable with dfu util? or can we try to flash included .dfu files in current release? Did you manage to install DFU bootloader now? Great. The latest version from master should include everything needed: From https://github.com/Ralim/IronOS/actions/runs/1811536243#artifacts https://pipelines.actions.githubusercontent.com/DdYJPragYZbW1sDdZ5pOjpHq7tU9f2Xn5oR6fWFuQK0qjFlgzP/_apis/pipelines/1/runs/2403/signedartifactscontent?artifactName=TS100&urlExpires=2022-02-08T14%3A23%3A29.5294616Z&urlSigningMethod=HMACV2&urlSignature=WAIgBKh3MBaM%2BOSQQ3A%2F4joAPC9BMUvuRn76h7jVDXU%3D
yes, successfully flashed runtime.hex and now backed up bootloader. second link expired. first link is release file with .hex and .dfu - is dfu flashable with dfu-util (we don't have STM's DFUSE)? what addresses to use so we won't overwrite stock dfu?
On Tue, Feb 08, 2022 at 06:29:54AM -0800, JugglerLKR wrote:
second link expired. first link is release file with .hex and .dfu - is dfu flashable? what addresses to use so we won't overwrite stock dfu?
dfu should be flashable and the right address is embedded in the file. DFU bootloader by Ralim won't allow to overwrite itself. Make sure you're running real bootloader, not the "RUNTIME" one which is only used once for upgrading the bootloader.
On Tue, Feb 08, 2022 at 06:29:54AM -0800, JugglerLKR wrote: second link expired. first link is release file with .hex and .dfu - is dfu flashable? what addresses to use so we won't overwrite stock dfu? dfu should be flashable and the right address is embedded in the file. DFU bootloader by Ralim won't allow to overwrite itself. Make sure you're running real bootloader, not the "RUNTIME" one which is only used once for upgrading the bootloader.
hmm, it is not very good idea then. PUF52 will have hard time flashing it with dfu-util every release. will this work: install real bootloader, flash Ralim's firmware with dfu-util. then, flash back stock dfu with Ralim's bootloader?
On Tue, Feb 08, 2022 at 06:42:38AM -0800, JugglerLKR wrote:
hmm, it is not very good idea then. PUF52 will have hard time flashing it with dfu-util everytime.
FFS! dfu-util is awesome and implements proper DFU. Works reliably and fast.
will this work: install real bootloader, flash Ralim's firmware with dfu-util. then, flash back stock dfu with Ralim's bootloader?
No.
On Tue, Feb 08, 2022 at 06:42:38AM -0800, JugglerLKR wrote: hmm, it is not very good idea then. PUF52 will have hard time flashing it with dfu-util everytime. FFS! dfu-util is awesome and implements proper DFU. Works reliably and fast. will this work: install real bootloader, flash Ralim's firmware with dfu-util. then, flash back stock dfu with Ralim's bootloader? No.
Is it safe to downgrade bootloaders using Ralim's runtime? PUF52 has GD32 version with DFU 3.48. I have 3.45 backup from my TS100 but with original STM32 mcu. If bootloder fails to load, then we will not have access to flashed runtime too?
On Tue, Feb 08, 2022 at 06:55:00AM -0800, JugglerLKR wrote:
Is it safe to downgrade bootloaders using Ralim's runtime? PUF52 has GD32 version with DFU 3.48. I have 3.45 backup from my TS100 but with original STM32 mcu. If bootloder fails to load, then we will not have access to flashed runtime too?
Not safe, you'll have to use SWD to recover.
Is it safe to downgrade bootloaders using Ralim's runtime? PUF52 has GD32 version with DFU 3.48. I have 3.45 backup from my TS100 but with original STM32 mcu.
I don't recommend doing this.
If bootloder fails to load, then we will not have access to flashed runtime too?
That's absolutely true. But it is possible to revive it using a st-link, however I don't know if it will work for the GD32 chip.
Ok, not an option. Next idea: since runtime.hex flashed ok (but only for the second time), is it possible to cut firmware in .hex format to multiple chunks, and flash it using those chunks one after another?
On Tue, Feb 08, 2022 at 06:59:54AM -0800, discip wrote:
But it is possible to revive it using an st-link, however I don't know of it will work for the GD32 chip.
A word of warning: stlinkv3 supports only st-made targets. Shame on ST firmware team.
stlinkv2 or other methods should handle gd32 fine.
On Tue, Feb 08, 2022 at 07:04:30AM -0800, JugglerLKR wrote:
Next idea: since runtime.hex flashed ok (but only for the second time), is it possible to cut firmware in .hex format to multiple chunks, and flash it using those chunks one after another?
Ralim made a nice proper bootloader for you and a way to flash it easily. What else do you need, seriously?..
On Tue, Feb 08, 2022 at 07:04:30AM -0800, JugglerLKR wrote: Next idea: since runtime.hex flashed ok (but only for the second time), is it possible to cut firmware in .hex format to multiple chunks, and flash it using those chunks one after another? Ralim made a nice proper bootloader for you and a way to flash it easily. What else do you need, seriously?..
I agree. Two concerns - hard to use dfu-util for a non-computer guy PUF52. Second, will bootloader work on GD32 firmware ok? Or working runtime 100% proof it is working?
hard to use dfu-util for a non-computer guy PUF52.
@JugglerLKR Since you seem to be in the position to help him, I recommend to write a batch file which he will have to click every time he downloads a new .dfu to flash it.
hard to use dfu-util for a non-computer guy PUF52.
@JugglerLKR Since you seem to be in the position to help him, I recommend to write a batch file which he will have to click every time he downloads a new .dfu to flash it.
This is my last resort :-D But I'm a bit afraid flashing bootloader. If anything goes wrong I will be responsible for damage.
p.s. Flashing firmware cut to parts is not working. first file gave an error! (ofcourse in newlines boundaries)
On Tue, Feb 08, 2022 at 06:42:38AM -0800, JugglerLKR wrote: hmm, it is not very good idea then. PUF52 will have hard time flashing it with dfu-util everytime. FFS! dfu-util is awesome and implements proper DFU. Works reliably and fast. will this work: install real bootloader, flash Ralim's firmware with dfu-util. then, flash back stock dfu with Ralim's bootloader? No.
Is it safe to downgrade bootloaders using Ralim's runtime? PUF52 has GD32 version with DFU 3.48. I have 3.45 backup from my TS100 but with original STM32 mcu. If bootloder fails to load, then we will not have access to flashed runtime too?
GD32 cant run the older bootloaders, 3.47+ is the only option for GD32 TS100's
Second, will bootloader work on GD32 firmware ok?
It should but I only have a sample size of 1 (me) to confirm this.
Reporting back. Live CD of Ubuntu 18 solved the flashing issue - just drag'n'drop .hex to iron mount, the same like done in windows.
This makes it very suspect that it was your Windows install after all.
Reporting back. Live CD of Ubuntu 18 solved the flashing issue - just drag'n'drop .hex to iron mount, the same like done in windows.
This makes it very suspect that it was your Windows install after all.
Not mine, mine flashed ok, it was PUF52 WIN7 + GD32 iron. But I think th
you are right. There might be some sort of incompatibility of GD32 with newest DFUs and windows installations. It looks like dfu crashes while receiving file. When I tried smaller chunks - it did't crash, but always returned with .ERR. It is strange, when oem 2.20 flashes ok, but I didn't test that. I believe issue can be closed. Thanks to everone who helped !
So in the end, how to flash a soldering iron then? give me a working way!:-)
So in the end, how to flash a soldering iron then? give me a working way!:-)
Boot with Ubuntu desktop 18+ (live version will do)
friends, so how to treat the absence of any information on the screen?
@Eugene-Market If your not seeing anything on the screen, is the unit still operating (but screen not working)? You can test this by pressing the front button and checking if tip heats up.
if the tip does heat up, its possibly you have a poorly soldered OLED module on your iron.
If it does not heat up, you may have a bad flash of the firmware.
@Ralim Heating on your firmware works (but just a black screen). The official firmware works (the screen also works)
Your issue is different to this git issue then. Most likely you have a poorly soldered OLED screen.
even if the official firmware works?
I'm afraid to ask, but how to solve this?)
The official firmware does not use all the features that IronOS does.
9 times out of 10, its open up the iron, and re-melt the joins from the PCB to the OLED carefully
Which iron do you have? If it is a TS80 or a TS80P, see here https://github.com/Ralim/IronOS/issues/630#issuecomment-809748658.
ts100, I have already disassembled, but in appearance, the contact points are well soldered
well, I accidentally overheated the road, and almost made a fatal mistake, however, it did not help (
as a hint, some firmware still showed something, it was running pixels, as if mmm ... the processor thinks that the width of the pixels is 64, but in fact there are 63 of them, something like that, on some firmware there was a clear picture, but it did not changes, and when switching the menu, it also starts to run mixed with the menu item.
I really hope that this is not a marriage, please make me happy, I have been collecting for this soldering iron for a long time)
Can you provide a photo of the inside's We can try and look for possibly causes
![Uploading 20220210_145922.jpg…]()
Ralim, hello. You probably know that with a lot of help from Juggler, I was able to flash my soldering iron at 2.16. But sometimes this screen pops up when you turn it on. Somewhere 1 time out 10. What could it be?
I also have
Ralim, although you closed this problem, it remained for me. Not a single firmware is loaded on the soldering iron, except for the Chinese stock 2.20, including your 2.16. after downloading and copying. I can not solve this problem myself and I ask for your help. On two other soldering irons with DFU 3.45, everything happens normally and without problems. I also loaded your corrected firmware - the behavior is similar, the soldering iron falls off the computer.
https://user-images.githubusercontent.com/86562320/152643926-54741d50-3938-4459-bd7e-053a178e74a2.mp4