Skip to content

Switched to embassy_time 0.4.0 and embassy_executor 0.7.0 #95

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

Merged
merged 10 commits into from
Jul 6, 2025

Conversation

joao404
Copy link
Contributor

@joao404 joao404 commented May 10, 2025

Hello,

I have adapted time_driver_tim.rs in the same manner as time_driver.rs is for stm32 in embassy repo. embassy_time with version 0.4.0 should now be possible as requested by #82

@joao404 joao404 changed the title Switched to embassy_time 0.2.0 and embassy_executor 0.7.0 Switched to embassy_time 0.4.0 and embassy_executor 0.7.0 May 10, 2025
return false;
}

// Write the CCR value regardless of whether we're going to enable it now or not.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation should be fixed here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thank you. Used an auto formatter.

@romainreignier
Copy link
Contributor

romainreignier commented May 12, 2025

I @joao404 Nice changes!

I have tested on CH32V003 and a basic blinky and it freezes after a couple of seconds:

Example from ch32-hal-template:

#![no_std]
#![no_main]
#![feature(type_alias_impl_trait)]

use embassy_executor::Spawner;
use embassy_time::Timer;
use ch32_hal::gpio::{AnyPin, Level, Output, Pin};
use ch32_hal::println;
use panic_halt as _;


#[embassy_executor::task]
async fn blink(pin: AnyPin, interval_ms: u64) {
    let mut led = Output::new(pin, Level::Low, Default::default());

    loop {
        led.set_high();
        Timer::after_millis(interval_ms).await;
        led.set_low();
        Timer::after_millis(interval_ms).await;
    }
}


#[embassy_executor::main(entry = "qingke_rt::entry")]
async fn main(spawner: Spawner) -> ! {
    ch32_hal::debug::SDIPrint::enable();
    let p = ch32_hal::init(ch32_hal::Config::default());

    // Adjust the LED GPIO according to your board
    spawner.spawn(blink(p.PC4.degrade(), 1000)).unwrap();
    loop {
        Timer::after_millis(1000).await;
        println!("tick");
    }
}

Output:

2025-05-12 14:30:19.500134051 +02:00: tick
2025-05-12 14:30:20.498323020 +02:00: tick
2025-05-12 14:30:21.496440003 +02:00: tick
2025-05-12 14:30:22.495185681 +02:00: tick
2025-05-12 14:30:23.493594200 +02:00: tick
2025-05-12 14:30:24.492035937 +02:00: tick
2025-05-12 14:30:25.490735536 +02:00: tick
2025-05-12 14:30:26.489222521 +02:00: tick
2025-05-12 14:30:27.488140784 +02:00: tick
[stuck]

Edit: I have tried on a CH32V307 and it seems to work (ran for 2 hours before I stopped).

Edit 2: In the case of the V003 freeze:

wlink regs
dpc(pc):   0x0000099c
x0   zero: 0x00000000
x1     ra: 0x000009b6
x2     sp: 0x200007e8
x3     gp: 0x20000800
x4     tp: 0xa0c87054
x5     t0: 0x40000000
x6     t1: 0x00000008
x7     t2: 0x20000148
x8     s0: 0x00000000
x9     s1: 0x00000008
x10    a0: 0x00000000
x11    a1: 0x00000000
x12    a2: 0x200007f8
x13    a3: 0x0089583e
x14    a4: 0x00000000
x15    a5: 0x00000000
marchid  : 0xdc68d841
mimpid   : 0xdc688001
mhartid  : 0x00000000
misa     : 0x40800014
mtvec    : 0x00000003
mscratch : 0x42314b2c
mepc     : 0x00000992
mcause   : 0x80000026
mtval    : 0x00000000
mstatus  : 0x00001888
dcsr     : 0x400000c3
dpc      : 0x0000099c
dscratch0: 0x00000000
dscratch1: 0x00000000
gintenr  : 0x00000000
intsyscr : 0x00000003
corecfgr : 0x00000000
wlink status
wlink status
16:36:51 [INFO] Connected to WCH-Link v2.12(v32) (WCH-LinkE-CH32V305)
16:36:52 [INFO] Attached chip: CH32V003 [CH32V003F4U6] (ChipID: 0x00310500)
16:36:52 [INFO] Chip ESIG: FlashSize(16KB) UID(cd-ab-2b-23-56-bc-4e-8b)
16:36:52 [INFO] Flash protected: false
16:36:52 [INFO] RISC-V ISA(misa): Some("RV32CEX")
16:36:52 [INFO] RISC-V arch(marchid): Some("WCH-V2A")
16:36:52 [WARN] The halt status may be incorrect because detaching might resume the MCU
16:36:52 [INFO] Dmstatus {
    .0: 0x4c0382,
    allhavereset: true,
    anyhavereset: true,
    allresumeack: false,
    anyresumeack: false,
    allunavail: false,
    anyunavail: false,
    allrunning: false,
    anyrunning: false,
    allhalted: true,
    anyhalted: true,
    authenticated: true,
    version: 0x2,
}
16:36:52 [INFO] Dmcontrol {
    .0: 0x80000001,
    haltreq: true,
    resumereq: false,
    ackhavereset: false,
    ndmreset: false,
    dmactive: true,
}
16:36:52 [INFO] Hartinfo {
    .0: 0x2120f4,
    nscratch: 0x2,
    dataaccess: true,
    datasize: 0x2,
    dataaddr: 0xf4,
}
16:36:52 [INFO] Abstractcs {
    .0: 0x8000002,
    progbufsize: 0x8,
    busy: false,
    cmderr: 0x0,
    datacount: 0x2,
}
16:36:52 [INFO] haltsum0: 0x1
`mepc : 0x00000992`
000008b2 <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7>:
     992: 00062023      sw      zero, 0x0(a2)
     996: c199          beqz    a1, 0x99c <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7+0xea>
     998: 8004a073      csrs    0x800, s1
     99c: d575          beqz    a0, 0x988 <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7+0xd6>
     99e: 8004b5f3      csrrc   a1, 0x800, s1
     9a2: 4910          lw      a2, 0x10(a0)
     9a4: 4940          lw      s0, 0x14(a0)
     9a6: 89a1          andi    a1, a1, 0x8
     9a8: 9a75          andi    a2, a2, -0x3
     9aa: c910          sw      a2, 0x10(a0)
     9ac: c199          beqz    a1, 0x9b2 <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7+0x100>
     9ae: 8004a073      csrs    0x800, s1
     9b2: 4d4c          lw      a1, 0x1c(a0)
     9b4: 9582          jalr    a1
     9b6: 8522          mv      a0, s0
     9b8: d861          beqz    s0, 0x988 <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7+0xd6>
     9ba: b7d5          j       0x99e <embassy_executor::arch::thread::Executor::run::hc2505085baeb64d7+0xec>
     9bc: 00000097      auipc   ra, 0x0
     9c0: 5a2080e7      jalr    0x5a2(ra) <core::panicking::panic_fmt::h562158adaf807ac7>

@joao404
Copy link
Contributor Author

joao404 commented May 12, 2025

Hi,

unfortunately I do not have a wch-link to try it out myself. I thought I could use my ST-Link and did not order one. I have a ch32v307vct6 dev board and use wchisp (which works great by the way, thank you for providing it). I tried it using a blocking and async UartTx connection and had no problem for 10 minutes(then I stopped testing).
I tried it with SDIPrint but it blocks immediately (probably because I have no wch link).
As project base I am using your hal template with nightly toolchain and "wchisp flash" as runner. Besides switching to embassy executor 0.7.0 and embassy time 0.4.0, I deleted option "task-arena-size-192" of embassy-executor.

I will try to find a solution with your debug information

@romainreignier
Copy link
Contributor

Ok, I see.
First, I think that we need to understand mcause : 0x80000026.
But we might need the expertise of @andelf or @Codetector1374

@joao404
Copy link
Contributor Author

joao404 commented May 13, 2025

If I understand documentation correctly, highest bit set means that we have an interrupt and 0x26 is number of interrupt. Compared with https://github.com/ch32-rs/ch32-data/blob/main/data/interrupts/CH32V0.yaml it should be TIM2, which has thrown interrupt. This fits to our Cargo.toml where "time-driver-tim2" is activated for ch32 hal.
mtvec should define address of interrupt but is set to zero. Lower to bites are accessing mode of interrupt.
Edit:
I have ordered a Wch Link

@romainreignier
Copy link
Contributor

Hi @joao404
I don't know if you have managed to debug it further?
I have tested it on a CH32V203C8T6 and to seems it work without issue.

@romainreignier
Copy link
Contributor

I have tested it on CH23X035 too but currently the examples do not set any time-driver-* feature so the time_driver_systick.rs is used and this file needs to be ported to in order to build.

When using the time-driver-tim2 feature, the blinky code works as expected.

@joao404
Copy link
Contributor Author

joao404 commented Jun 13, 2025

Hello,

I received the wlink but was not able to test it with sdi print yet. I checked systick file before but it looks not like an easy merge/change. I will take a look at it after my vacation.

Best regards

@joao404
Copy link
Contributor Author

joao404 commented Jun 16, 2025

Hi,

I made the first changes to adapt time_driver_systick, but it does not work yet. I also included changes of #88. Maybe someone can have a second look. SDI print does not work with my probe so I have no good way to debug it at the moment.

@joao404
Copy link
Contributor Author

joao404 commented Jun 30, 2025

Hello,

I was able to make systick work but with a change to embassy_time. From my point of view we have a timing problem. Default frequency of hclk(and thereby cpu) is 8Mhz so systick runs with 1 Mhz. Default embassy tick frequency is 1 Mhz. Thereby we have to check for ready futures every systick. The problem occurs from my point of view at the end of on_interrupt. The next interrupt is only fired, if we hit new compare register value. If counter value is already higher, no interrupt is given. So IMHO we only have 7 cpu cycles to calculate the next cmp register value which is only 1 counting value away of systick timer.

Only if I reduce embassy_tick to lower values does it work properly. I debugged it using println! which showed that otherwise we often have a cmp register value higher than current counting value.
How do we want to proceed?

@romainreignier
Copy link
Contributor

Hi @joao404

It seems that SysTick can be driven by HCLK or HCLK/8. Maybe we can use it with HCLK directly without the divider when the systick feature is used for embassy_time?
And we can add documentation about this fact.
The user can use a real timer instead of the systick or decrease embassy tick frequency or increase the system clock frequency with PLL.

@joao404
Copy link
Contributor Author

joao404 commented Jun 30, 2025

Hi @romainreignier ,
What irritates me is that we should have the same problem in the previous implementation. I will investigate that.

@Codetector1374
Copy link
Member

I think your assessment of the problem is correct, we should not attempt to run at 1MHz tick rate when our clock is only 8Mhz. That's insane overhead and almost guarantee we don't be running efficiently or even on time.
We should document this quirk and advise people choose a reasonable tick rate for the CPU speed we are running at.

@joao404
Copy link
Contributor Author

joao404 commented Jun 30, 2025

I would propose to switch to a default tick of 10kHz, change Cargo.toml of every example for that and mention it in Readme. 10kHz worked for me during debugging. Do you agree?

P.s.: also previous versions used 1Mhz tick. That it works irritates me a little.

I also tried to make example spi-lcd-st7735-cube build for ch32v003 work, but I am not able to make it fit into flash even with optimization level z. All other versions are ok.

@joao404
Copy link
Contributor Author

joao404 commented Jul 2, 2025

Hello,

I am able to build spi-lcd-st7735-cube for ch32v003 in release mode now but as before, it is a tight fit. Only a few bytes left. This seems to be a base embassy problem as mentioned in embassy-rs/embassy#4290.
Please trigger a new build.

@romainreignier
Copy link
Contributor

I have started the workflow.
I will try to test theses changes on some boards soon.
Have you managed to fix the freeze issue on V003?

@joao404
Copy link
Contributor Author

joao404 commented Jul 2, 2025

I understand now, that the failing action is not building examples but repo without any features. I thereby removed my compiler warning because it was not present before. Tried it with the same commands as github action.
@romainreignier regarding ch32v003 freeze I tried replicating the problem with my ch32v307 and have found an issue. When I use the same options inside Cargo.toml for ch32v307 like with ch32v003, it does not work. When I remove task-arena-size-128 from embassy-executor, it works. Could you please confirm with ch32v003?

@romainreignier
Copy link
Contributor

The alternative to remove your warning would be to add time driver features in CI for targets without 64-bit systick.
I think it was a good idea.

I have tried again on the V003 and indeed, I had to increase the arena-size to 256 for it to run, we should increase the default value (it also means the new embassy stack uses more stack than before because it used to work with 128 I think).

But now, I have this runtime error:

2025-07-02 14:28:13.154651948 +02:00: panicked at /home/romain/ch32/rust/ch32-rs/ch32-hal/src/embassy/time_driver_tim.rs:256:46:
2025-07-02 14:28:13.157689656 +02:00: already borrowed: BorrowMutError

@joao404
Copy link
Contributor Author

joao404 commented Jul 2, 2025

Changing arena-size to 256 does not work for me. Blinky does not work when I add it. @romainreignier can you tell me, how I should configure my workspace so that I can see such a panic with Wch linkE?
I am only using "runner = "wlink flash --enable-sdi-print --watch-serial"" in config.toml for debugging.

@romainreignier
Copy link
Contributor

I use the default config:

cd examples/ch32v003
cargo +nightly run --release --bin embassy_blinky

I have not tested the V307 with the latest version of this PR but last time, it was working on V307 and only failed on V003.

@joao404
Copy link
Contributor Author

joao404 commented Jul 2, 2025

Ok. So I am using the same mechanism but getting no error. ch32v307 run for 3 hours today without any problem. Because I have no ch32v003 I cannot debug it's problem. How do we want to proceed?

@Codetector1374
Copy link
Member

Actually took a closer look with @Dummyc0m, the time_driver_systick.rs is actually quite broken and we will try to rewrite a fix in the next couple of days. After some thinking, realized that the 8Mhz/1Mhz tick rate should not be the root cause.

@Codetector1374
Copy link
Member

@joao404 / @romainreignier

We have a patch here: https://gist.github.com/Codetector1374/880a58c69127c540747b8acbf1183fbb

feel free to update your PR with this and test it on the boards you have (As @Dummyc0m and I only have CH32V305/307). We have verified this patch works with a simple embassy blinky example (like the one you have above) on our board.

Let me know how it goes, would like to get this fixed/merged soon as well!

@Dummyc0m
Copy link
Member

Dummyc0m commented Jul 4, 2025

#95 (comment)

Please take a look at this comment. Can you also rebase your patches on top of the upstream main branch? The merge commit cannot be rebased.

Also please see the build error.

@joao404
Copy link
Contributor Author

joao404 commented Jul 4, 2025

Build error is fixed but I am fighting with the rebase. I am sorry. This is the first rebase I'm doing.

@Dummyc0m
Copy link
Member

Dummyc0m commented Jul 4, 2025 via email

Marcel Maage and others added 8 commits July 5, 2025 10:45
@joao404
Copy link
Contributor Author

joao404 commented Jul 5, 2025

Hello, it looks, like I have done it

@Codetector1374 Codetector1374 merged commit 2b8e1c8 into ch32-rs:main Jul 6, 2025
11 checks passed
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

Successfully merging this pull request may close these issues.

4 participants