<lemonxah>
good day hope everyone is doing great :) i am trying to write some firmware on nrf52840 using the basic hal stuff everything works the way i want it to work really, but i was looking at embassy and rtic is there something that you could recommend me to look at? embassy looked good but i cant get the usb serial CDC ACM to work
<lemonxah>
tried it with RTIC aswell but the USB descriptor doesn't work seems to be the usb interrupt, but i am not sure what the issue is, if i dont use embedded or RTIC everything just works, wanted to have some sort of RTOS so that i can have multiple things running i want a temp senser sending every 5 seconds using ble and i want to have CDC ACM and HID reports to be in another 2 "threads"
<lemonxah>
ok so no changes to this but still not working, the red led keeps flashing which is what happens in boot loop from what i have seen
<lemonxah>
and the device is not detected
<dirbaio[m]>
what board are you using, how are you flashing it?
<lemonxah>
using the pro micro v2
<lemonxah>
converting it to uf2 and putting it on the device via uf2 bootloader
<lemonxah>
fasling from 0x1000
<dirbaio[m]>
if it has a bootloader you have to change the flash start address in memory.x
<dirbaio[m]>
because your binary goes after the bootloader, not at 0
<dirbaio[m]>
* not at address 0
<lemonxah>
yeah i am using 0x1000 cause i still need the uf2bootloader since i dont have another way of programming them for now
<Kaspar[m]>
<lemonxah> tried it with RTIC aswell but the USB descriptor doesn't work seems to be the usb interrupt, but i am not sure what the issue is, if i dont use embedded or RTIC everything just works, wanted to have some sort of RTOS so that i can have multiple things running i want a temp senser sending every 5...
<lemonxah>
if i am not using embassy and just using the nrf52840_hal and i use usb_serial crate i can get it to work also flashing it the same way
<lemonxah>
Kaspar[m]: reading this, its not really what i am after but interesting to look at
<lemonxah>
mostly i like how embassy is set out i dont mind that, i just want to find out why embassy code is not running on the pro micro v2, only difference is main.rs can cargo.toml
<dirbaio[m]>
I just tried the example to make sure, it works...
<dirbaio[m]>
it must be something specific to the pro micro then
<lemonxah>
dirbaio[m]: you tried on flash address 0x1000
<lemonxah>
not that i think that would make a difference
<dirbaio[m]>
like, the bootloader leaving the chip in a weird state
<dirbaio[m]>
maybe the bootloader doesn't set VTOR?
<dirbaio[m]>
lemonxah: no, i've tried it on address 0x0 because i'm running it on a nrf52840-dk without any bootloader. address 0x1000 won't work if there's no bootloader at address 0x0
<dirbaio[m]>
dirbaio[m]: try enabling the feature `set-vtor` in `cortex-m-rt`
<lemonxah>
dirbaio[m]: it works on address 0x1000 if i dont use embassy
<dirbaio[m]>
that doesn't mean the bootloader isfine
<lemonxah>
this is what is confusing me, i can get a ubs serial working if i just use `[#enrty] fn main { loop { }} `
<dirbaio[m]>
the bootloader could leave the chip in a weird state that affects embassy but not usbd-serial
<lemonxah>
oh ok
<dirbaio[m]>
for example embassy needs interrupts to work
<dirbaio[m]>
which makes me think of VTOR. If you're running from a non-zero address, Interrupts won't work if you don't set VTOR. The bootloader is supposed to set it but some crap bootloaders out there don't
<lemonxah>
so if i decide to program it form 0x0 how would i program it going forward, do i need to have jlink
<dirbaio[m]>
what usbd-serial example are you running? does it use interrupts?
<dirbaio[m]>
lemonxah: yeah you need a debug probe for that
<lemonxah>
the bootloader it came with is the adafruit uf2 one nicenano
<lemonxah>
for convenience i need to have some bootlaoder cause i dont hav ea debug probe, is there a debug probe you can recommend or should i just build one using another nrf or rpi pico like the picoprobe
<dirbaio[m]>
yes, best is get a rpi pico, flash it with the [debugprobe](github.com/raspberrypi/debugprobe) firmware
<lemonxah>
yeah i have a few rpi picos laying around
<dirbaio[m]>
dirbaio[m]: what usbd-serial example are you running?
<lemonxah>
the one you linked me
MartinSivk[m] has joined #rust-embedded
<MartinSivk[m]>
or by the picoprobe, it is not expensive and has proper leads and box so you will not accidentally short it when debugging a mess on the table like I often do :)
<MartinSivk[m]>
s/by/buy/
<lemonxah>
the other one that is working is just some code i wrote a month ago for another project
<dirbaio[m]>
does it use interrupts?
<lemonxah>
no its part of my main loop
<lemonxah>
so that might be the issue then
<lemonxah>
ok let me make a debug probe witha pico as the first step
<lemonxah>
and then figure out how to program the pro micro v2 using that
<dirbaio[m]>
you have to connect it to the DIO, CLK, GND pads in the back
<lemonxah>
yeah i saw then
<lemonxah>
ok let me do that, would be the best i think
<lemonxah>
preferred to use bootloaders? or its always best to not use any bootloader?
<dirbaio[m]>
for developing use a debug probe, otherwise you can't see logs
<lemonxah>
yeah no i get that :)
<lemonxah>
for production ? cause i need to create the actual boards and they need to be programmed initial batch is 500
<dirbaio[m]>
you need a bootloader if you ship a product and want end users (not developers) to be able to update it
<lemonxah>
ah ok
<dirbaio[m]>
for factory programming you typically need a debug probe as well, if you buy bare nrf chips they come with a completely blank flash, no bootloader
<lemonxah>
thanks .. was stupid question
<dirbaio[m]>
so in factory you use a debug probe to program the bootloader and the first version of the firmware, then the end user can use the bootloader to further update the firmware later
<lemonxah>
does any 2040 work?
<lemonxah>
or it has to be the pico
<lemonxah>
"official" pico
<dirbaio[m]>
not sure
<lemonxah>
well i guess let me flash it with the debug probe firmware and check
<lemonxah>
[0]: Debugprobe on Pico (CMSIS-DAP) -- 2e8a:000c:DF609C06E39C2E21 (CMSIS-DAP) <- firmware at least works so let me find out which ports i need to use
<thejpster[m]>
yes, that's re-writing the default target in .cargo/config.toml based on the last target you compiled.
Rahix_ has joined #rust-embedded
<thejpster[m]>
like, yes, I can see why - rust-analyzer is annoying to use for cross-compiled projects - but ... wow.
edm_ has joined #rust-embedded
<lemonxah>
vdd is 5v right? doe the probe work with 5v or 3.3
<dirbaio[m]>
don't connect vdd, just gnd, swdio, swclk
<lemonxah>
and still power it via usb ?
<dirbaio[m]>
yeah, power both the probe and the nrf board independently each
<lemonxah>
was thinking of just powering it off the probe and only have the probe plugged in
<lemonxah>
sure
ni has quit [*.net *.split]
fooker has quit [*.net *.split]
Rahix has quit [*.net *.split]
edm has quit [*.net *.split]
edm_ is now known as edm
<MartinSivk[m]>
you might want to connect a pin to reset too
<dirbaio[m]>
reset is not needed with nrf
<MartinSivk[m]>
in case you accidentally put the board to deep sleep or something (or remap swd), so the probe can connect before the real program starts
<dirbaio[m]>
that's only a problem with stm32's
<MartinSivk[m]>
Ah, really? How do you step from the first instruction when needed?
<dirbaio[m]>
through swd you can "reset and halt"
<MartinSivk[m]>
And it actully works with nRF? Good to know.
<dirbaio[m]>
it works with all chips 🤔
<MartinSivk[m]>
Well.. STM32 was not exactly happy sometimes, the external reset was more reliable for me for some reason
<MartinSivk[m]>
So I always connect it since then.. a habit I guess
<dirbaio[m]>
"reset and halt" is universal to all cortex-m I think. the problem is to issue that you need to first connect through swd, and in some chips (like stm32) you can't during sleep or if swd is remapped, so you fix that with the wired RST pin
<dirbaio[m]>
* "reset and halt" is universal to all cortex-m I think. the problem is to do "reset and halt" that you need to first connect through swd, and in some chips (like stm32) you can't during sleep or if swd is remapped, so you fix that with the wired RST pin
<dirbaio[m]>
* "reset and halt" is universal to all cortex-m I think. the problem is to do "reset and halt" that you need to first connect through swd, and in some chips (like stm32) you can't during sleep or if swd is remapped, so you fix that with the wired RST pin and do --connect-under-reset
<MartinSivk[m]>
Yeah, I definitely remember that part
<dirbaio[m]>
but nrf has no weird states where SWD doesn't work
<dirbaio[m]>
thankfully
<dirbaio[m]>
you can always connect
<dirbaio[m]>
and what's funnier is --connect-under-reset with nrf makes it not work
<dirbaio[m]>
because RST in nrf resets everything including SWD, while in stm32 it resets the core only but keeps SWD working
<dirbaio[m]>
or something like that
<dirbaio[m]>
it's a giant mess 😭
ni has joined #rust-embedded
<lemonxah>
ok all connected up
<MartinSivk[m]>
Haha, that it is
<lemonxah>
let see if it works :P
fooker has joined #rust-embedded
Koen[m] has joined #rust-embedded
<Koen[m]>
It's nice to have one universal standard that works everywhere 🙈
<lemonxah>
not working, must be using wrong gpio pinso n the picoprobe? i am using gpio2 for data and gpio3 as clock
<MartinSivk[m]>
switch them, I think 2 is clock and 3 is io
<lemonxah>
success
<lemonxah>
also SUCCESS !! programming it this way worked with embassy
<lemonxah>
thank you so much for the help fellows
dougli1sqrd has joined #rust-embedded
hmw- has quit [Quit: Bye.]
hmw has joined #rust-embedded
<lemonxah>
hi again :) now i have another issue which i am unsure why its happening
crypt0c4t has joined #rust-embedded
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
<lemonxah>
i had joy for like a few minutes
<lemonxah>
but now it no longer programs the board :/
<JamesMunns[m]>
<lemonxah> hi again :) now i have another issue which i am unsure why its happening
<JamesMunns[m]>
you'll get better input if you actually share what the problem is, instead of just saying you have one. That makes it easier for people to asynchronously make suggestions.
<lemonxah>
yeah sorry, i get distracted
<lemonxah>
its not a very smooth programming experience
<lemonxah>
i am tryinig to read the debug messages but after a embassy_nrf::init() happens then no more messages
<lemonxah>
just a learning curve i have to go through, its working again without me seemingly doing anything so its more me trying to figure out shy sometimes it works