Some problems on flashing with Linux or Windows

[shadow2560]

Before explaining my problem note that on my Windows system this seems to work properly, the test is made on a friend computer.

Without connecting any adapter on the computer I tried to launch the command "gnwmanager --verbosity debug unlock". On my computer this display a list of tries with all adapter and say that it couldn't find any adapter, normal. On my friend computer when I try the same thing it try to launch the stlink.cfg config and just after that it try to reset the device with the "reset_and_halt()" function, that's not normal because like I said no adpater is connected; and the program seems totaly frozen after that because even with "ctrl+c" shortcut it doesn't terminate it.

A classic flash work perfectly (old Game-and-watch-patch for example) so I realy don't understand what could cause this problem or what/where to search to find some clues on the error. I've tried to search in the Devices Manager and I don't see anything suspect, I've also searched in programs installed but nothing here also.

I've tried the unlock command from a classic Python installation and Chocolated install of Openocd with "gnwmanager install openocd". Our two Windows system are the same (Windows 11 Pro last version), we have the same STlink drivers installed, realy I don't understand...

Thanks.

[BrianPugh]

hmmm, definitely odd. Please follow up if you get more concrete information! Also maybe try rebooting your windows machine.

[shadow2560]

Reboot has already been tried.
Can you indicate me how the program detect an adapter (more precisly for Stlink because it seems to detect a ghost Stlink) and maybe where to search into the source code for important variables or functions for this? During my research I've founded strange globals vars into my friend's computer, maybe the problem is there but it's only integer's vars and I haven't noted anything related to the program.

I'll continue to search and I'll tell you if I find something.
Edit: Trying to del the strange globals variables but doesn't change anything. Here is the debug output for command "gnwmanager --verbosity debug unlock":

2024-04-29 14:01:05,654 - INFO: Attempting to launch openocd: openocd -c tcl_port 6666 -c adapter speed 4000 -c source [find interface/stlink.cfg] -c transport select hla_swd -c source [find target/stm32h7x.cfg]
2024-04-29 14:01:05,659 - DEBUG: Performing device reset and halt.

[shadow2560]

I've tried to launch this command on the two computers:

openocd -c "tcl_port 6666" -c "adapter speed 4000" -c "source [find interface/stlink.cfg]" -c "transport select hla_swd" -c "source [find target/stm32h7x.cfg]"

Result in my computer:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 4000 kHz

hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1800 kHz
Error: open failed

Now on my friend's computer:

Open On-Chip Debugger 0.12.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
adapter speed: 4000 kHz

hla_swd
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Error: couldn't bind tcl to socket on port 6666: No error

I looked into path global variable to see if something could interfer but nothing. Realy I don't understand, it seems to be an Openocd problem but it seems to freeze also gnwmanager when it occures; and also I don't understand why it works with old methods of flash.

[BrianPugh]

This code (and the functions above it) iterate over the various openocd configurations until it successfully connects to a debug probe.

[shadow2560]

This code (and the functions above it) iterate over the various openocd configurations until it successfully connects to a debug probe.

I've looked into it (that's how I have constructed my Openocd's test commands) but unfortunatly I don't know what I could search now with this, I'm not familiar with this type of hardwares. I think my next test will be a test on an other fresh Windows computer that I own, I'll post my results when it will be done.

[shadow2560]

On my fresh Windows computer this seems to work, I desesperate...

[shadow2560]

OK I finaly fix the problem by using "netstat /q /b" to list the port used on the computer, then I have identified that the port 6666 was used by a program (with the netstat command you only have the exe filename so you must identify the process with the task manager), for me it was the program Minitool Shadow Maker witch causing the bug, after uninstalling it it works. Maybe having the possibility to specify a port number with a param in the gnwmanager command could be a good function to add.

But now I have an other problem, I have tried to flash Retro-go but every 11 parts the program freeze. Do you think that it's a Retro-go problem? Should I open an other issue for that?

[BrianPugh]

does it continue to make progress (i.e. 11 more chunks each flash attempt)? Some people experience this, but there's been no solid leads on the cause. Not a retro-go issue.

[shadow2560]

Yes, the flash progress, I can make it completly by relaunching the make command without clean. We will make some more tests in the next days, I'll inform you if I progress on this.

[shadow2560]

Some infos on my tests, on windows this doesn't progress, every 11 shunks the program stop to work properly and need to be stoped and relaunched to continue the flash (inside or outside Msys2 it's the same). Next test will be to use Pyocd outside Msys2, I've successfuly installed it so I think I could do some tests with it later.
On Ubuntu 22.04 the flash has worked with Pyocd but with Openocd it doesn't, it wait for booting the GnW and stop worked after the time out, with the custom Openocd and official installed by Gnwmanager. And an other strange thing, when trying the unlock process it doesn't work, when the program say to reboot the GnW to have the blue screen it reboot normaly and it seems to brake the flasher (seems to be in a sort of deep sleep state, the flasher is detected but don't want to comunicate with the memory or reset the connection (For the Stlink it ended with an error 9 with Pyocd)), we have lost a Stlink and a Pico yesturday and re-flashing the firmware on them doesn't helped, we have flashed severals GnW before and no problems like that have appened. If I press "enter" even if the blue screen doesn't show I obtain an error of hash mismatch. I haven't ried the unlock process on Windows but for now I will not, don't want to brake some more lfashers.
Last thing that I have tried, the compilation of the firmware doesn't work, with Gcc-arm-none-eabi-10.3-2021.10 and last mingw64 arm toolchain package on mingw64 this always do that except that with latest mingw64 arm toolchain package I have warnings:

   text    data     bss     dec     hex filename
  36628  944276    2316  983220   f00b4 build/gnwmanager.elf
copy from `build/gnwmanager.elf' [elf32-littlearm] to `build/gnwmanager.bin' [binary]
make: copy: No such file or directory
make: *** [Makefile:245: gnwmanager/firmware.bin] Error 127

And with latest mingw64 arm toolchain:

c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-closer.o): in function `_close_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/closer.c:47:(.text+0xc): warning: _close is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-fstatr.o): in function `_fstat_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/fstatr.c:55:(.text+0x12): warning: _fstat is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-signalr.o): in function `_getpid_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/signalr.c:83:(.text+0x2c): warning: _getpid is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-isattyr.o): in function `_isatty_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/isattyr.c:52:(.text+0xc): warning: _isatty is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-signalr.o): in function `_kill_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/signalr.c:53:(.text+0x12): warning: _kill is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-lseekr.o): in function `_lseek_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/lseekr.c:49:(.text+0x14): warning: _lseek is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-readr.o): in function `_read_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/readr.c:49:(.text+0x14): warning: _read is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libc_nano.a(libc_a-writer.o): in function `_write_r':
c:\m\b\src\newlib-4.4.0.20231231\newlib\libc\reent/writer.c:49:(.text+0x14): warning: _write is not implemented and will always fail
c:/msys2/mingw64/bin/../lib/gcc/arm-none-eabi/12.2.0/../../../../arm-none-eabi/bin/ld.exe: warning: build/gnwmanager.elf has a LOAD segment with RWX permissions
   text    data     bss     dec     hex filename
  38556  944268    2660  985484   f098c build/gnwmanager.elf
copy from `build/gnwmanager.elf' [elf32-littlearm] to `build/gnwmanager.bin' [binary]
make: copy: No such file or directory
make: *** [Makefile:245: gnwmanager/firmware.bin] Error 127

See you for the nex report...

[BrianPugh]

And an other strange thing, when trying the unlock process it doesn't work

Currently the unlock process doesn't work with pyocd; there are some upstream issues.

If everything seems to "freeze", try removing and replugging in the battery to your gnw. I doubt your debug probes are actually broken.

It seems like it mostly built fine; it seems like this last copy call failed. Maybe try replacing this line with something else. I rarely use windows, so I'm not too much help 🙈 .

[shadow2560]

We have disconected the GnW (from power and even from the flasher) but they are not working anymore and with the same reactions with the same scenario. Maybe the problem comes from an other source (bad wires for example but the person witch made it has largely enough competences to do it corectly, no doubt about it), for now I tried to analyse what I have done and what happened and the only thing witch is the same is that the problem comes after the failed flash (without error said by the program like I have explained in my last comment) during unlock process.
I'll try compiling on Linux when I can and I will try what you suggest on Windows.
But my question now is why on Linux Openocd doesn't want to flash, it's realy strange because old flash method with Retro-go work on the same config?

[shadow2560]

So I have finaly ended my project. Here are the problems encountered and not resolved:

• Flashing with Openocd work on Windows but it doesn't seems to comunicate properly with Gnwmanager, it freeze more or less randomly (every 11 or 13 shunks with Retro-go, doesn't end the CFW patch properly because the reset seems to freeze the app), just need to launch again the command to continue the flash process. With Pyocd the problem is not present, this work perfectly but it is more difficult to install it on some environement, on Msys I can't install it.
• On Linux Openocd doesn't want to comunicate properly with Gnwmanager, it reboot the GnW in flash screen but doesn't want to flash (it says it waits the device boot and end with the time out). With Pyocd it work but not possible for me to unlock (Pyocd not supported for now to unlock in Gnwmanager) because of the Openocd problem, need to unlock with the old method; I've not retried the unlock process because I suspect it to brake my programers, we are not sure it is that witch brake the devices but I don't want to brake others programers.
• After flashing CFW and Retro-go the commands only want to launch if the GnW is on Retro-go main screen, I doesn't know why (error "No cores were discovered").

I think I can't help more than that, I'll follow the differents projects, thanks for your work on them.