Alex__I'd appreciate it if I can get some directions to tackle the following problem:
Alex__I need to interface directly to CAN transceiver and be able to read/write bits from/to the bus
myselfbehind the transceiver, are you planning to use one of the CAN controllers onboard the am335x, or an external (spi-connected) controller? or roll your own in a PRU or something?
Alex__The dcan sounds to be a convenient option. But I need to be able to do something before a frame's transmission is finished
zmattthat sounds like really really tight timing requirements, i.e. using PRU would be your only option
myselfAhh, you're trying to corrupt a frame on the wire and replace it with your own :)
Alex__you got me :)
myselfI previously ran across an opinion from a PRU specialist who said the PRU doesn't have the resources to implement a full CAN controller, but if you look at what a real CAN controller does, there's quite a lot of edge-case handling that you could probably leave right out.
Alex__I've spent like a week trying to figure out PRU and got lost. so I thought there maybe another way. From what you guys said, it seems to be my only option
myselfHere's the problem, though -- the sender of the legit message will know it got corrupted (that's inherent within CAN) and retry immediately, because it knows the arbitration process will grant it access to the bus if it has the lower ID.
myselfThis isn't ethernet. :) It doesn't have a backoff timer..
myselfSo, if you slay that message every single time it appears on the bus, you'll both destroy the bus for anyone else (who has a higher ID and thus loses arbitration), and cause a fault when the sender's retry counter reaches its threshold.
myselfThere are two approaches that actually work:
Alex__but not if I do someing DURING arbitration phase
myselfIf you do something during arbitration, you monopolize the bus and the message just retries a moment later.
Alex__My goal is to target only certain IDs
myselfAnyway. A) let the "wrong" message go out, then the instant it's done, you follow it with the "right" one, and hope to replace it in the receive buffers of whoever you hope to fool.
myselfor B) get out the wire cutters and man-in-the-middle that shit.
Alex__I like that. Could you elaborate on " edge-case handling that you could probably leave right out" please?
myselfsure, one sec.
Alex__sure, thank
myselfError frames and overload frames, for one. They're in the spec but you can probably ignore them.
myselfAlso I think for receiving, if you're only looking at the header, you can leave out all the CRC stuff and let the higher software layers handle that
myselfyou might even be able to leave out the ACK mechanism, or you might find that particularly interesting and want to imbue it with special software hooks :)
Alex__So just to make sure I get it, you're saying that I can modify the controller to only deal with the ID part and ignore the rest to do what I'm trying to achieve. Right?
myselfIf you choose to implement a controller from scratch in the PRU to achieve the level of control you want, you'll find that the PRU probably lacks the resources to implement the whole spec, and to make it fit, you'll have to implement only the parts you care about.
Alex__Thanks for that. Do I have options other than the PRU?
myselfMost existing CAN controllers on the market with these sorts of capabilities are FPGA-based, so there's that route.
myselfI did find some references to a CAN implementation that fits within the PRU of a DA8xx processor, but I'm not clear on whether those are beefier than the PRUs of an AM335x.
myself(that was here: )
myselfwho knows, maybe it would work. I'm out of my depth there.
Alex__I really appreciate your input myself and I'll check it out
myselfI really don't think it's gonna work the way you think it will; CAN is robust against the thing you're trying to do. But I'd love to be wrong. :)
Alex__Suprisingly enough, I've seen people did it with Arduino Uno!!
myselfOoo. Link?
myselfI've seen message replacement, but not overwriting.
myselfi.e. follow it quickly with the desired message and hope the receiver's buffer only has room for one, so the last one transmitted is sitting in the buffer when the software comes to check for it
Alex__You can check it out here:
myselfOkay, that's what I mentioned in "cause a fault when the sender's retry counter reaches its threshold."
myselfyou can kick that ECU off the bus, but it'll be unable to send any of its *other* messages either
myselfIf a given ECU only sent one message, that would be fine, but in real networks, many ECUs are participating in many functions with different IDs
myselfIf that's acceptable in your target architecture, then go for it, but it's not always the cleanest state to get a network into.
Alex__I'm trying to cause the target ECU to retract because I'll be injecting a dominant bit that leads the target ECU to loose arbitration, not to cause a fault.
Alex__I hope this is different from what you're saying
myselfit doesn't lose arbitration, it voluntarily stops talking because its error counter exceeds a threshold
myselflosing arbitration is a normal part of bus operation and it would simply retry once the bus returned to idle
Alex__This is exactly my goal, to make it seem "normal"
myselfattacking it with error bits makes its error counter climb until it disables its transmitter
myselfand it knows about that, that counter within the controller is accessible to software
myselflosing arbitration won't keep the message from being on the bus, it'll simply transmit again as soon as the higher-priority frame is finished
Alex__But isn't possible to keep losing as long as I repeat the injection?
myselfif it keeps losing arbitration, then you've DoS'd the bus for all frames of higher ID (lower priority)
myselfif it keeps getting transmit errors, then the error counter faults it out and it knows it's been messed with
myself(it may not do anything with that knowledge, but it could.)
Alex__I think errors are triggered out of the arbitration phase, right?
myselfit doesn't matter where the error occurs, it'll be counted in the error counter
myselfthe only time it doesn't count as an error is during arbitration if it's just right and happens as a loss of arbitration, but that's not an error
myselfbut because it's not an error, it'll simply retry the instant the bus is free again
Alex__"myself", you're awesome and I really appreciate your time!!
myselfmuch obliged! I'm very curious what you come up with. :)
myselfpop into reddit /r/carhacking sometime
Alex__Sure, will do. Have a great night :)
myselfAha! Here's where they said it's not possible:
myselfMakes me even more curious about that DA8xx implementation
zmattda8xx (omap-L1xx) implementation? its pru subsystem is afaik considerably more limited compared to that of the am335x
AgeonI'm looking for a development board to develop IIOT project
Ageonis beagle board suitable for industrial purposes
snowdogDoes anyone have experience extracting eMMC contents from the BeagleBone Green Wireless?
myselfyou mean like, mounting the partition and reading from it?
snowdogI guess so, I'm trying to follow the instructions here to create an SD card that I can use to flash other boards.
snowdogI have also posted a question here that has a bit more detail with a boot log!category-topic/beagleboard/seeed-beaglebone-green-wireless/boot/u-boot/ZFMBepd9hIo
zmattsnowdog: there's a script that creates a flasher card from eMMC contents, located at /opt/scripts/tools/eMMC/
snowdogzmatt: Thank you, I will take a look at this!
myselfis it fair to say that for most of these things, "beaglebone black" tools apply to all the derivatives (green, green wireless, blue, enhanced, etc)? Basically excluding the white, x15, and original beagleboard. I'm not sure where the pocket fits on the scale of compatibility..
zmattmyself: the pocket has no eMMC
maxtonDoes anyone know if there is a library for the PRU that facilitates accessing the I2C controllers on the L4 interconnect? I have been searching, and found only a project that implements I2C on the PRU via bit-banging the EGPIO pins.
zmattnot specifically, although using the i2c controller from the pru isn't really different from using the i2c controller from the cortex-a8
zmatt(apart from configuring the pru interrupt controller, if you intend to use it)
zmattdo make sure that linux doesn't have an active driver for it at the same time. you can unbind the driver from the peripheral via sysfs (and also force-enable it there, which avoids having to deal with PRCM yourself)
zmatte.g. echo 4802a000.i2c >/sys/bus/platform/drivers/omap_i2c/unbind ; echo on >/sys/bus/platform/devices/4802a000.i2c/power/control
zmatt(this applies only if the peripheral is enabled in linux to begin with, but this is the case in the default setup on beaglebones since a fair time ago)
maxtonOh well, I guess it's back to reading the technical reference manual then. Thanks for the info!