ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <@walstib-alex:matrix.org> Is CAN working with the USB peripheral disabled and the USB cable/transciever disconnected and is USB working with the CAN peripheral disconnected and the CAN network/transciever disconnected?
<re_irc> Sorry if I missed that part of the conversation.
<re_irc> Did you probe both sides of the differentials to see if either are misbehaving (i.e being pulled high/low inadvertedly)?
<re_irc> Ripping out either to try the other is probably a start if the major difference from previous designs is using the same pins and having chips routed to common nets.
<re_irc> <@walstib-alex:matrix.org> +(as mentioned)
<re_irc> <@walstib-alex:matrix.org> Some CAN peripherals also support setting the tx line high and low manually (usually it requires a test mode), make suee that you see these transitions both on the differential anf logical lines while toggling it.
<re_irc> <@walstib-alex:matrix.org> * sure
<re_irc> <@walstib-alex:matrix.org> * and
<re_irc> <@walstib-alex:matrix.org> * logic
<re_irc> <@firefrommoonlight:matrix.org> alexandra: CAN is working with the USB peripheral disabled (And the USB cable still connected to the CAN TX line).
<re_irc> I haven't tried disconnecting the CAN tranceiver, but agree that's a good place to start. I'll desolder it tomorrow and see if that does it; should be instructive if that's the problem.
<re_irc> Did not probe, but good place to start! I do actually have the shared line connected to a logic analyzer, so should be straightfwd. Of note, it looks normal when inspecting CAN signals, so I don't think it's being pulled.
<re_irc> <@firefrommoonlight:matrix.org> I'll post once I try the desolder, but am working some other issues that need CAN working, so am trying to finish that up first
<re_irc> <@firefrommoonlight:matrix.org> I wonder if your manual setting would help TS without pulling the part though
<re_irc> <@walstib-alex:matrix.org> Do you have a sleep/power-off pin for the CAN transciever, it may be enough for testing
<re_irc> <@walstib-alex:matrix.org> Which one are you using btw?
<re_irc> <@firefrommoonlight:matrix.org> Unfortunately, I have it tighed to enabled
<re_irc> <@firefrommoonlight:matrix.org> NXP TJA1051
<re_irc> <@walstib-alex:matrix.org> I'll have a look-see, but you'll probably want that inverted to your USB enable not to ruin life for the other peers on the CAN net
<re_irc> I might be wrong of course
<re_irc> <@firefrommoonlight:matrix.org> That's a great idea
<re_irc> <@firefrommoonlight:matrix.org> I'll wire it to a GPIO on next build; would be an easy fix!
<re_irc> <@firefrommoonlight:matrix.org> Probably with a hardware PU so DFU will work
<re_irc> <@firefrommoonlight:matrix.org> Would love if that solved it
<re_irc> <@firefrommoonlight:matrix.org> RN I am dealing with a weird ghost bug that probably involves the write buffer being dropped before the CAN finishes loading to its own RAM, and would love to try the desolder once that's fixed
<re_irc> <@firefrommoonlight:matrix.org> (Probably can fix by using a static buf)
<re_irc> <@walstib-alex:matrix.org> Do you have sonething like a 5V detect on the USB power line? It might be enough to know if sonething is connected
<re_irc> <@firefrommoonlight:matrix.org> No
<re_irc> <@firefrommoonlight:matrix.org> The USB is just +/-, 5v and gnd
<re_irc> <@walstib-alex:matrix.org> I'm not a hardware designer, but a transistor on the 5V line may be enough
<re_irc> <@firefrommoonlight:matrix.org> Valid; yea or a voltage div to a GPIO
<re_irc> <@firefrommoonlight:matrix.org> Plan based on our convo:
<re_irc> - Try desoldering the tranceiver
<re_irc> - If that works, make next edition of board connect the power-down line to GPIO, and/or USB voltage detection
<re_irc> <@firefrommoonlight:matrix.org> I appreciate it!
<re_irc> <@walstib-alex:matrix.org> Depending on the package, you might be able to lift the enable pin and solder it to a gpio, to try it out
<re_irc> <@walstib-alex:matrix.org> On TJA1051, that is
<re_irc> <@firefrommoonlight:matrix.org> Probably not doable unfortunately; QFN
<re_irc> <@walstib-alex:matrix.org> As it is 😔
<re_irc> <@walstib-alex:matrix.org> But you'll know once you've desoldered it, so let's hooe that works 👍
<re_irc> <@walstib-alex:matrix.org> * hope
<re_irc> <@firefrommoonlight:matrix.org> Yea def!
<re_irc> <@nvsd:matrix.org> I'm pretty new to embedded and i'm trying to use cargo embed with a feather_m0 and jlink but I'm getting "Failed to erase flash sector at address 0x00000000" is anyone familiar with this error? If this isn't the right place to ask this question I'm happy to move it elsewhere
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
cr1901_ has joined #rust-embedded
lehmrob has joined #rust-embedded
mattgirv has quit [Ping timeout: 255 seconds]
dreamcat4 has joined #rust-embedded
thomas25 has quit [Ping timeout: 248 seconds]
<re_irc> <@ryan-summers:matrix.org> Hmm, I'm noticing that my Element chat on PC seems to pause while I have my PC offline, so I don't see chat from e.g. when I was asleep, but I see all of it on Mobile. Anyone else notice this and/or know how to fix it?
<re_irc> <@k900:0upti.me> Just restart Element or refresh the page
<re_irc> <@k900:0upti.me> It gets confused about catching up sometimes
<re_irc> <@ryan-summers:matrix.org> Restarting the app didn't work, and not sure how to refresh it (For context, I'm using the Windows desktop app)
<re_irc> <@ryan-summers:matrix.org> F5 doesn't seem to do it like I'd expect with an electron app
<re_irc> <@diondokter:matrix.org> I don't seem to have any issue with the Windows app
<re_irc> <@k900:0upti.me> Huh, I haven't tried the Windows version specifically but on Linux F5 works I think
<re_irc> <@diondokter:matrix.org> Nope
<re_irc> <@ryan-summers:matrix.org> Weird, I don't see any settings for this anywhere in Element either, and there's no mention of refresh keys in the shortcut list
<re_irc> <@ryan-summers:matrix.org> I always wondered why there was no chat from the US after I signed off for the day :P
<re_irc> <@adamgreig:matrix.org> I've seen this a few times on webapp and android app, using the "clear cache" button in the element settings seemed to fix it.... annoying though
<re_irc> <@ryan-summers:matrix.org> Is that the "Message Search" cache? I haven't found another cache to clear
thomas25 has joined #rust-embedded
lehmrob has quit [Ping timeout: 265 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> No, just "clear cache", general settings on android and maybe advanced on web app?
limpkin has quit [Remote host closed the connection]
limpkin has joined #rust-embedded
<re_irc> <@vollbrecht:matrix.org> : while espflash --help in version 2.0.0-rc3 looks cleaner compared to version 1.7 . where are the colors gone? 🤔
<re_irc> <@vollbrecht:matrix.org> ups wrong channel sry :D
lehmrob has joined #rust-embedded
<re_irc> <@ryan-summers:matrix.org> Ah that indeed took some looking, but did fix the problem, thanks :)
lehmrob has quit [Ping timeout: 246 seconds]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
cr1901_ is now known as cr1901
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> Ok super weird general question. I am hitting a bizarre bug, possibly UB or something, with CAN. It seems like the sort of thing you get with DMA when you don't carefully manage lifetimes (which in practice I deal with using static buffesr)
<re_irc> <@firefrommoonlight:matrix.org> I set up a buffer to xmit. Can print it and it's normal. But when I send it down the wire, the receiver is missing most of the data! I am using packed struct. I tried a static buffer and compiler fence, and the bytes I edit manually work, but the ones from packed struct are missing most! So bizarre
<re_irc> <@firefrommoonlight:matrix.org> let payload = fix_dc.pack().unwrap();
<re_irc> // unsafe { CAN_BUF_PVT[0..protocol::GNSS_PAYLOAD_SIZE].clone_from_slice(&fix_dc.pack().unwrap()) };
<re_irc> for i in 0..payload.len() {
<re_irc> CAN_BUF_PVT[i] = payload[i];
<re_irc> unsafe {
<re_irc> }
<re_irc> }
<re_irc> unsafe {
<re_irc> CAN_BUF_PVT[3] = 69;
<re_irc> CAN_BUF_PVT[12] = 69;
<re_irc> CAN_BUF_PVT[13] = 70;
<re_irc> CAN_BUF_PVT[14] = 71;
<re_irc> CAN_BUF_PVT[20] = 69;
<re_irc> }
<re_irc> <@firefrommoonlight:matrix.org> So, all the bytes I manually set there get received, but most of the ones from the "packed_struct" don't!
<re_irc> <@firefrommoonlight:matrix.org> Like I figured putting the data into the static buff would prevent this sort of things, but still some of the bytes are getting dropped and some aren't. I don't think I provided enough info to solve this, but am open to ideas
<re_irc> <@firefrommoonlight:matrix.org> let payload = fix_dc.pack().unwrap();
<re_irc> // unsafe { CAN_BUF_PVT[0..protocol::GNSS_PAYLOAD_SIZE].clone_from_slice(&fix_dc.pack().unwrap()) };
<re_irc> for i in 0..payload.len() {
<re_irc> CAN_BUF_PVT[i] = payload[i];
<re_irc> }
<re_irc> unsafe {
<re_irc> }
<re_irc> unsafe {
<re_irc> CAN_BUF_PVT[3] = 69;
<re_irc> CAN_BUF_PVT[12] = 69;
<re_irc> CAN_BUF_PVT[13] = 70;
<re_irc> CAN_BUF_PVT[14] = 71;
<re_irc> CAN_BUF_PVT[20] = 69;
<re_irc> }
<re_irc> println!("Broadcast payload: {}", unsafe { CAN_BUF_PVT });
<re_irc> <@firefrommoonlight:matrix.org> Could maybe troubleshoot further by seeing if I can "pack" directly into the static buf
<re_irc> <@firefrommoonlight:matrix.org> But I don't think that lib's API does that
<re_irc> <@firefrommoonlight:matrix.org> And that struct is too big and non-u8-aligned to pack it manually
<re_irc> <@firefrommoonlight:matrix.org> Example of part of a buffer before broadcasting:
<re_irc> Broadcast payload: [189, 198, 45, 69, 0, 0, 0, 128, 228, 55, 30, 231, 69, 70, 71, 0, 0, 0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 2, 98, 247, 255, 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 15, 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 194]
<re_irc> <@firefrommoonlight:matrix.org> Example received buffer on the other device:
<re_irc> Buf: [114, 243, 94, 69, 0, 0, 0, 0, 0, 0, 0, 0, 69, 70, 71, 0, 0, 0, 0, 0, 69, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 215]
<re_irc> <@firefrommoonlight:matrix.org> So weird!!!
<re_irc> <@firefrommoonlight:matrix.org> * weird taht the bytes I manually add are there, but the ones from the packed struct are hit and mostly miss!!!
<re_irc> <@firefrommoonlight:matrix.org> Oh god. Not actually UB magic. Solvedish. It had to do with interactions between the CAN busses that I didn't see when only debugging one at a time. Ie it was actually a heisenbug
<re_irc> <@firefrommoonlight:matrix.org> -Ie it was actually a heisenbug
<re_irc> <@firefrommoonlight:matrix.org> The receving device was sending a signal that the transmitting device ended up interrupting its process and not preparing the payload properly; I didn't see in teh print statementse because I only have 1 debugger :/
<re_irc> <@walstib-alex:matrix.org> Are you running a network between two nodes on the same chip, or wdym? Like, what kind of interactions are you talking about?
<re_irc> What happens if you put the sending peripheral into local loopback and do try receiving the data?
<re_irc> <@walstib-alex:matrix.org> -do
<re_irc> <@firefrommoonlight:matrix.org> 2 nodes on 2 sep chips
<re_irc> <@firefrommoonlight:matrix.org> I'm not sure actually. Now I can't get it to work lol. But this is some weird, heisenbug stuff!
<re_irc> <@firefrommoonlight:matrix.org> Works in loopback mode
<re_irc> <@firefrommoonlight:matrix.org> *It does appear you need static bufs or other lifetime management though
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@nvsd:matrix.org> I'm pretty new to embedded and i'm trying to use cargo embed with a feather_m0 and jlink but I'm getting Failed to erase flash sector at address 0x00000000 is anyone familiar with this error? If this isn't the right place to ask this question I'm happy to move it elsewhere
<re_irc> <@walstib-alex:matrix.org> : Yeah, you never want things to move when involving dma :D
<re_irc> <@walstib-alex:matrix.org> nvsd: Feather_m0 sounds familiar, same5x?
<re_irc> <@walstib-alex:matrix.org> 0x0 (null) is usually protected, what are you doing since you're trying to erase it?
<re_irc> <@firefrommoonlight:matrix.org> alexandra: USB works, including in DFU mode, after ripping out the tranciever!
<re_irc> <@firefrommoonlight:matrix.org> alexandra: I guess I don't have a good model of how USB and CAN work, but it seems similar to DMA in that the peripheral transfers passively (?)
<re_irc> <@joelsa:fehler-in-der-matrix.de> : That was my guess as well
<re_irc> <@firefrommoonlight:matrix.org> I guess the next step is, as discussed, see if the tranciever in low power mode still causes trouble
<re_irc> <@joelsa:fehler-in-der-matrix.de> Yeah, and one thing about the TJA1051: Don’t tie the S Pin (Pin 8) directly to VCC/GND/Floating but at least put a 0 Ohm or DNP Resistor to GND.
<re_irc> <@joelsa:fehler-in-der-matrix.de> That way you can use SN65HVD or MCP2551 which have a slope set resistor on Pin 8 just by changing populate options
<re_irc> <@joelsa:fehler-in-der-matrix.de> Even though CAN Transceivers are Obtanium right now, always good to have options
<re_irc> <@walstib-alex:matrix.org> : Think of dma as a coprocessor that mostly does copies, it's asynchronous to the main processor but usually shares the same memory
<re_irc> In CAN you either have an exclusive RAM for messages or as a reserved part of the main RAM. The peripheral itself (in both USB and CAN) uses an exclusive DMA to shuffle data, so you need to be a little more careful with ownership.
mightypork_ has joined #rust-embedded
mightypork has quit [Ping timeout: 265 seconds]
<re_irc> <@firefrommoonlight:matrix.org> joelsa: Interesting!
<re_irc> <@firefrommoonlight:matrix.org> alexandra: Ok sure, but... What about CAN?
<re_irc> <@firefrommoonlight:matrix.org> Same caveats as DMA?
<re_irc> <@firefrommoonlight:matrix.org> alexandra: Makes sense! So, even though I'm not invoking the DMA periph directly, the same caveats about buffer longevity apply?
<re_irc> <@firefrommoonlight:matrix.org> joelsa: Interesting! I have it tied to gnd
<re_irc> <@firefrommoonlight:matrix.org> Will change up next revision. I appreciate all the help here! Very instructive
<re_irc> <@firefrommoonlight:matrix.org> I have it tied to gnd
<re_irc> <@firefrommoonlight:matrix.org> joelsa: This stuff is v important these days!
<re_irc> <@firefrommoonlight:matrix.org> From S tied high: > A HIGH level on pin S selects Silent mode. In Silent mode the transmitter is disabled,
<re_irc> releasing the bus pins to recessive state
<re_irc> <@firefrommoonlight:matrix.org> From DS:
<re_irc> > A HIGH level on pin S selects Silent mode. In Silent mode the transmitter is disabled,
<re_irc> > releasing the bus pins to recessive state
<re_irc> <@firefrommoonlight:matrix.org> Sounds like it might do the trick
<re_irc> <@rjmp:matrix.org> It doesn't sound to me like that will disable the can_tx output pin :
<re_irc> <@rjmp:matrix.org> Just the bus lines
<re_irc> <@rjmp:matrix.org> In fact it can't because in silent nice the transceiver still sends bus state to the rxd pin so they CAN controller can listen to bus traffic.
<re_irc> <@rjmp:matrix.org> * mode
<re_irc> <@firefrommoonlight:matrix.org> It is kind of a gamble, but I want to believe; would be such a nice soln if it worked.
<re_irc> <@firefrommoonlight:matrix.org> Oh :(
<re_irc> <@firefrommoonlight:matrix.org> So, would need a transistor or analog switch then
<re_irc> <@firefrommoonlight:matrix.org> On the TX line
<re_irc> <@firefrommoonlight:matrix.org> * RX
<re_irc> <@walstib-alex:matrix.org> Look at the truth table for silent mode
<re_irc> <@walstib-alex:matrix.org> It still looked like it might drive the bus recessive
<re_irc> <@walstib-alex:matrix.org> I.e. high
<re_irc> <@walstib-alex:matrix.org> * high, even if weakly
<re_irc> <@firefrommoonlight:matrix.org> Your idea about lifting a pin would sort this out
<re_irc> <@firefrommoonlight:matrix.org> The equivalent, bodge-wiring the QFN, I think is beyond my skill
<re_irc> <@walstib-alex:matrix.org> You might want to look into a prototype breakout board
<re_irc> <@firefrommoonlight:matrix.org> Yea true. Or I end up yoloing the updated design, and am out $ and 🕑 when it doesn't work
<re_irc> <@walstib-alex:matrix.org> It do be like that sometimes