Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building for Linux #2

Open
MarkMLl opened this issue Mar 19, 2024 · 7 comments
Open

Building for Linux #2

MarkMLl opened this issue Mar 19, 2024 · 7 comments

Comments

@MarkMLl
Copy link

MarkMLl commented Mar 19, 2024

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 <stropts.h> needs to be replaced by #include <sys/ioctl.h>, but this triggers a redefinition which is beyond my wit to resolve.

@DeqingSun
Copy link
Owner

Please try again. I pulled some fix.

@MarkMLl
Copy link
Author

MarkMLl commented Mar 19, 2024

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 pengutronix/microcom#30 ) that introduces some nasty side-effects.

@DeqingSun
Copy link
Owner

DeqingSun commented Mar 19, 2024

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
Copy link
Author

MarkMLl commented Mar 19, 2024

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
Copy link
Owner

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
Copy link
Author

MarkMLl commented Mar 20, 2024

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
Copy link
Author

MarkMLl commented Mar 21, 2024

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.

Screenshot_20240321_163420

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants