<EthanWu[m]>
successfully landed rust code with defmt and embassy on m33 core of stm32mp257 given little public community support and no swd. nxp imx 95 will also be supported. will apache-2.0 when full hil done.
<EthanWu[m]>
informing those in april thinking the repo being ai slop solely because of an em dash and thought hardware must explode.
glitchy has quit [Ping timeout: 254 seconds]
glitchy has joined #rust-embedded
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
_whitelogger has joined #rust-embedded
<ocsel[m]>
i loove em-dashes and refuse to get bullied into abandonning them! 😅
<M9names[m]>
oh, swd? oops, guess i'm bad at parsing today 🤦
<EthanWu[m]>
yeah the on-board swd could hardly take the role of debugging. btw nxp imx95 literally didn't have svd available according to my search :-(
<EthanWu[m]>
s/swd/st-link/
<EthanWu[m]>
so given the combination i took embassy's chiptool as an example for better peripheral reuse
<M9names[m]>
i don't follow. the chip does have swd, is the cm33 not accessable through it?
<EthanWu[m]>
well, it does has a vcp, but st-link couldn
<EthanWu[m]>
* st-link couldn't be used for programming, as per the user manual
<M9names[m]>
i have no idea about imx95. but i do have some familiarity with stm32mp1, and it does have SWD and you can use it to debug the mcu core
<EthanWu[m]>
so all we could do is either let the cm33 write to the shared memory or turn off led (ph6) as far as i know, and eventually it worked
<EthanWu[m]>
* it worked. another option is to implement a driver for uart5 via pac
<EthanWu[m]>
'to debug the on-board stm32, no specific hardware configuration is required. programming through stlink-v3ec is not supported with microprocessor products.' perhaps it really can, but on mac the vcp is also fragile, only turning to windows when necessary
<EthanWu[m]>
btw right now ca35 can kick cm33 interrupt to wake it up. investigating uio to let cm33 successfully kick ca35 up for ipc.
<EthanWu[m]>
* for ipc. ca35 can also forward cm33 defmt message and melt them up together
<M9names[m]>
> programming through stlink-v3ec is not supported with microprocessor products
<M9names[m]>
if you're writing firmware for the CM33 you'd be writing your program into SRAM anyway.
<M9names[m]>
okay, but that's for writing to sdcard/emmc/nor/nand?
<EthanWu[m]>
that's simple, though. just scp elf to the ca35 and remoteproc live switch
<EthanWu[m]>
the only problem is just praying it goes the correct address. whether it enters 0x0 (invalid) or 0x80100000 (valid), dmesg is just successful
<EthanWu[m]>
* the only problem is just praying it goes the correct address. whether it enters 0x0 (invalid) or 0x80100000 (valid), dmesg just tells you 'successful' but gpio never flips
<M9names[m]>
do you get any better feedback if you enable the debugfs tracing logs for remoteproc?
<M9names[m]>
you should also be able to attach to the CM33 via SWD and see the processor state directly
<EthanWu[m]>
yeah. it tells me it loads 0x0 so i started to realize the linker script being wrong. then the led flipped.
renken[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]>
ST posted a series on YouTube on programming the CM33 of stm32mp2 a few days ago. I quickly skimmed it, there's a section on debugging via stm32cubeide.
<M9names[m]>
Might be worth your time to watch it
<EthanWu[m]>
cool. i'll view it once needed. i currently think that forwarding defmt to a35 can be more convenient than swd :-)
<EthanWu[m]>
s/view/watch/
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
bandini has quit [Ping timeout: 252 seconds]
rainingmessages1 has quit [Quit: bye]
rainingmessages1 has joined #rust-embedded
dcz[m]1 has quit [Quit: Idle timeout reached: 172800s]