Building for Linux

[MarkMLl]

I've been able to program a CH552T on (Debian) Linux using

$ objcopy -I ihex -O binary tinyspiDw20200623.hex tinyspiDw20200623.bin
$ ./isp55e0 -f tinyspiDw20200623.bin
Found device CH552
Bootloader version 2.5.0
Unique chip ID 44-72-5e-bd
Code flashing successful
Firmware is good
isp55e0: Can't reboot the device

I'm not yet running the Arduaino v2 IDE, but have been trying to build your https://github.com/DeqingSun/dwire-debug/tree/ArduinoProIDEAlphaTest with limited success. The problem is that in src/system/SystemServices.c doctrine appears to have it that #include needs to be replaced by #include <sys/ioctl.h>, but this triggers a redefinition which is beyond my wit to resolve.

[DeqingSun]

Please try again. I pulled some fix.

[MarkMLl]

I'm afraid that's only partial, since you're using library facilities that the upstream project avoided:

# Linux
gcc -std=gnu99 -g -fno-pie -rdynamic -fPIC -Wall -o dwdebug src/dwdebug.c -lusb -ldl
In file included from src/system/system.c:5,
                 from src/dwdebug.c:3:
src/system/SerialPort.c: In function ‘MakeSerialPort’:
src/system/SerialPort.c:81:9: warning: implicit declaration of function ‘ioctl’ [-Wimplicit-function-declaration]
   81 |     if (ioctl(*SerialPort, TCGETS2, &config)) {Close(*SerialPort); *SerialPort = 0; return;}
      |         ^~~~~

I'm very hesitant about my C and unix system programming, but I believe the "correct" fix involves replacing that header with sys/ioctl.h, which (according to https://github.com/pengutronix/microcom/issues/30 ) that introduces some nasty side-effects.

[DeqingSun]

Can you be more specific about "you're using library facilities that the upstream project avoided:" I don't see any difference between my file SerialPort.c and the upstream file.

Also "replacing that header", which header?

[MarkMLl]

I'm sorry, you're absolutely right: I didn't take on board that the ioctl() declaration was being handled as implicit and that the program was actually building successfully.

I can run it, but so far am not confident that it can see the 552... or am I reading too much into your "The dwire-debug binary in this repo was compiled with this branch"? I'll continue tinkering...

Apropos your

Also "replacing that header", which header?

I was referring to the "doctrine" in my first message.

[DeqingSun]

First of all you need to confirm the firmware on CH552 is working or not. Can "lsusb" see the device? Can you use it to flash bootloader or firmware to a AVR? If your answer is yes, then you start to tweak the dwire-debug. Otherwise, check your flashing process, connections and permissions.

[MarkMLl]

lsusb and dmesg definitely see it as 1781:0c9f. I'm working on a cable for an Arduino Uno and will report back.

For completeness, the hardware I'm using is https://github.com/WeActStudio/WeActStudio.CH552CoreBoard, the same people have also cloned your ch55xduino.

An interesting thing about WCH chips is that they don't always run well at more than USB "low speed" and might benefit from being attached to a low-speed USB hub. In the case of this CH552T, it's fine with either the as-shipped or your firmware, but needs to be on a low-speed hub for the loader mode to even be visible to Linux.

[MarkMLl]

I've got a precarious lashup comprising a cheap logic analyser and cheaper probes in front of me, I'd rather not get my better one out since the probes are adorning a development board.

What I'm seeing is that there's a train of RST signals 200 mSec period 50% ratio. After those have completed the Arduino emits 2x break on its Tx. Roughly 3 sec after that there's activity on SCK (which is trivially visible as LED flickers), but I've not caught anything on other signals.

I've been poking around a bit inside the code without finding anything obvious, I've not yet tried stretching those pulses but I've got a vague recollection of some timing dependencies when looking in the startup code a few years ago.

Edited: That should have read "looking in the Arduino startup code". Which of course raises the issue that there are multiple versions and variants of the loader firmware floating around, even on the Uno, and they might not all behave the same as far as timeouts etc. behave.