Git Product home page Git Product logo

candlelight_fw's Introduction

candleLight_gsusb

Build

This is firmware for certain STM32F042x/STM32F072xB-based USB-CAN adapters, notably:

Of important note is that the common STM32F103 will NOT work with this firmware because its hardware cannot use both USB and CAN simultaneously. Beware also the smaller packages in the F042 series which map a USB and CAN_TX signal on the same pin and are therefore unusable !

This implements the interface of the mainline linux gs_usb kernel module and works out-of-the-box with linux distros packaging this module, e.g. Ubuntu.

Limitations

STM32G0B1-based devices are not yet supported by the mainline firmware. Support for these devices is discussed in #139 and #176.

STM32G431-based devices (e.g. CANable-MKS 2.0) are not yet supported.

Currently, the firmware sends back an echo frame to the host when the frame is written to the CAN peripheral, and not when the frame is actually sent successfully on the bus. This affects timestamps, one-shot mode, and other edge cases.

Known issues

Be aware that there is a bug in the gs_usb module in linux<4.5 that can crash the kernel on device removal.

Here is a fixed version that should also work for older kernels: https://github.com/HubertD/socketcan_gs_usb

The Firmware also implements WCID USB descriptors and thus can be used on recent Windows versions without installing a driver.

Building

Building requires arm-none-eabi-gcc toolchain.

sudo apt-get install gcc-arm-none-eabi

mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake

# or,
# cmake-gui ..
# don't forget to specify the cmake toolchain file before configuring.
#
# compile all targets :

make

# OR, each board target is a cmake option and can be disabled before running 'make';
# OR, compile a single target , e.g.
make cantact_fw

#
# to list possible targets :
make help

Download Binaries

Prebuilt binaries can be downloaded by clicking CI. On the workflow overview page, select the latest workflow that ran on master branch. The firmware artifacts can downloaded by clicking them at the bottom of the page.

Flashing

Flashing candleLight on linux: (source: https://cantact.io/cantact/users-guide.html)

  • Flashing requires the dfu-util tool. On Ubuntu, this can be installed with sudo apt install dfu-util.
  • compile as above, or download the current binary release: gsusb_cantact_8b2b2b4.bin
  • If dfu-util fails due to permission issues on Linux, you may need additional udev rules. Consult your distro's documentation and see 70-candle-usb.rules provided here.

recommended simple method

  • If compiling with cmake, make flash-<targetname_fw>, e.g. make flash-canable_fw, to invoke dfu-util.

method for reflashing a specific device by serial

  • when multiple devices are connected, dfu-util may be unable to choose which one to flash.
  • Obtain device's serial # by looking at dfu-util -l
  • adapt the following command accordingly : dfu-util -D CORRECT_FIRMWARE.bin -S "serial_number_here", -a 0 -s 0x08000000:leave
  • note, the :leave suffix above may not be supported by older builds of dfu-util and is simply a convenient way to reboot into the normal firmware.

fail-safe method (or if flashing a blank device)

  • Disconnect the USB connector from the CANtact, short the BOOT pins, then reconnect the USB connector. The device should enumerate as "STM32 BOOTLOADER".

  • invoke dfu-util manually with: sudo dfu-util --dfuse-address -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D CORRECT_FIRMWARE.bin where CORRECT_FIRMWARE is the name of the desired .bin.

  • Disconnect the USB connector, un-short the BOOT pins, and reconnect.

Associating persistent device names

With udev on linux, it is possible to assign a device name to a certain serial number (see udev manpages and systemd.link). This can be useful when multiple devices are connected at the same time.

An example configuration :

 $ cat /etc/systemd/network/60-persistent-candev.link
[Match]
Property=ID_MODEL=cannette_gs_usb ID_SERIAL_SHORT="003800254250431420363230"

[Link]
# from systemd.link manpage:
# Note that specifying a name that the kernel might use for another interface (for example "eth0") is dangerous because the name assignment done by udev will race with the assignment done by the kernel, and only one
#   interface may use the name. Depending on the order of operations, either udev or the kernel will win, making the naming unpredictable. It is best to use some different prefix

Name=cannette99

( The serial number can be found with the lsusb utility). After reloading systemd units and resetting this board :

 $ ip a
....
59: cannette99: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can
 $

Hacking

Submitting pull requests

  • Each commit must not contain unrelated changes (e.g. functional and whitespace changes)
  • Project must be compilable (with default options) and functional, at each commit.
  • Squash any "WIP" or other temporary commits.
  • Make sure your editor is not messing up whitespace or line-ends.
  • We include both a .editorconfig and uncrustify.cfg which should help with whitespace.

Typical command to run uncrustify on all source files (ignoring HAL and third-party libs): uncrustify -c ./uncrustify.cfg --replace --no-backup $(find include src -name "*.[ch]")

Profiling

Not great on cortex-M0 cores (F042, F072 targets etc) since they lack hardware support (ITM and SWO). However, it's possible to randomly sample the program counter and get some coarse profiling info.

For example, openocd has the profile command (see https://openocd.org/doc/html/General-Commands.html#Misc-Commands), e.g.

profile 5 test.out 0x8000000 0x8100000

(from inside gdb, the command needs to be prefixed with monitor to forward it to openocd, i.e. monitor profile 5 ......

The .out file can then be processed with gprof <firmware_name> -l test.out

Links to related projects

  • Cangaroo open source can bus analyzer software
  • Candle.NET .NET wrapper for the candle API

candlelight_fw's People

Contributors

aselstm avatar brandonros avatar brian-brt avatar cdwilson avatar convertdevice avatar daniel-trevitz avatar de-vri-es avatar fenugrec avatar fiurin avatar florolf avatar gemesa avatar gerryqd avatar ghent360 avatar hubertd avatar lichtfeind avatar marckleinebudde avatar mbehensky avatar ndushman avatar nexulm avatar rext3d avatar rickyelopez avatar ryedwards avatar tuna-f1sh avatar vondraussen avatar wardbenjamin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

candlelight_fw's Issues

Multiple device support

The firmware seems not to support multiple candleLight, cantact, CANable interfaces plugged in at the same time.
If I'm using the candleLight build and plug in two USB2CAN devices socketcan (i.e. ip link set can0 up type can bitrate 500000) is coming up with two CAN interfaces (can0 / can1) but in reality only one device is working.

Is there any workaround available?

What do these error frames mean?

I get them back when trying to send a message to a separate CAN controller. I've tried flipping the termination pin and flipping CAN high/CAN low: no avail.

ffffffff0c000020080000000000080000000000
ffffffff0c00002008000000000c080000000000
ffffffff0c000020080000000030080000000000
ffffffff4c00002008000000000c080000000000
ffffffff4c000020080000000030080000000000

They are error frames, I just don't know what they mean.

[RFC] tag new release

As was noted in another issue, there hasn't been a tagged release in a long time, which is annoying for anyone that doesn't want to install gcc-arm and compile themselves.

Do we tag one right now, and also later after the st_libs update; or wait to merge the update before and tag at that time ?

Support for berr-reporting

I've got a project with a CANable clone, and I'd like to get information about what kind of CAN errors it sees. SocketCAN supports this via the berr-reporting (aka CAN_CTRLMODE_BERR_REPORTING) feature. I'm planning to hook that up.

The CAN_ESR register on this hardware has a LEC field which exposes this information. I've worked with the c_can Linux driver before, which uses hardware with a very similar interface for bit errors, so I plan to follow that pattern. I'm planning to expose that information from this firmware, and add support for gs_usb to expose it via the existing SocketCAN APIs. It looks like the existing supported features / enabled features bitmasks should make this easy to implement in a fully backwards-compatible way on both sides.

I don't see a mailing list or anything, so I'm opening this issue to discuss. Is there another place for that? Does anybody here know of any similar or conflicting work? Any suggestions/comments on the order of sending out the changes here and on the kernel side?

Replace ST USB stack?

Hello @HubertD! I saw you mention this in a pull request and it's something I'm likely going to have to address. I haven't dug into it too deeply but tinyusb is a stack that claims to support many STM32 µCs -- I would have to add STM32G support myself, but it has STM32F support.

Anyway, if any of us start any serious work on this, we can use this issue to track it. Thanks!

EDIT: I forgot to mention, the only real problem with it is that the license pollution by adding the restriction that it cannot be used on non-ST products (which seems a tad bit silly to me anyway). As we don't support any non-ST chips (yet), it's only an issue of the license being non-free.

Contract help wanted to port Candlelight to Artery AT32F415

Hello All,

as you know by now STM MCUs are in very short supply and very expensive these days if you can even find them. We have seen prices go from $1.80 -> $10 -> $29 two weeks ago and still rising.

We have been looking a replacing the STM MCUs with the Artery AT32F415. The Artery MCU as very similar in architecture to the STM units. We have been able to load the candlelight firmware onto these units but it fails to run and enumerate.

Here is a link to the Artery MCU programming guide.

https://www.arterytek.com/download/RM_AT32F415_EN_V1.03.pdf

Wondering if anyone in the community would be interested in porting Cadelight to this new platform. If so please contact me with contract terms and availabilty.

Thanks,

--luis

STM32F042x6 series cannot do both USB+CAN+send/receive

TL;DR: Does anybody know a solution to get USB+CAN+dump+send working on the STM32F042G6 with UFQFPN28 packaging ? I'm all ears :)

On the README.md there are several it reads:

Of important note is that the common STM32F103 will NOT work with this firmware because its hardware cannot use both USB and CAN simultaneously.

Isn't it true for the STM32F042x6 series too? According to this source:

The designers of the STMicro STM32F0xx family of parts made the unfortunate decision to assign USB and CAN peripheral functionality to the same pins.

There is an additional pin assignment option, but it is for CAN_RX only. As a result, this implementation is forced to be receive-only (e.g. a sniffer).

I have a small UFQFPN28 4x4 mm package for my STM32F042G6 on a dev board that has 28 pins:

https://github.com/candle-usb/candleLight_fw/blob/master/libs/STM32_HAL/include/stm32f0xx/stm32f0xx_hal.h#L96

Skärmavbild 2020-12-29 kl  16 43 03

And I had to do the following minor changes on the firmware to get the USB working/enumerating:

diff --git a/src/main.c b/src/main.c
index 47b63b5..22c28f8 100644
--- a/src/main.c
+++ b/src/main.c
@@ -215,6 +215,8 @@ void SystemClock_Config(void)

        HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);

+       __HAL_REMAP_PIN_ENABLE(HAL_REMAP_PA11_PA12);
+
        /* SysTick_IRQn interrupt configuration */
        HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
 }
diff --git a/src/can.c b/src/can.c
index 80c0a54..235ea14 100644
--- a/src/can.c
+++ b/src/can.c
@@ -32,7 +32,7 @@ void can_init(can_data_t *hcan, CAN_TypeDef *instance)
        __HAL_RCC_CAN1_CLK_ENABLE();

        GPIO_InitTypeDef itd;
-       itd.Pin = GPIO_PIN_8|GPIO_PIN_9;
+       itd.Pin = GPIO_PIN_3|GPIO_PIN_4;
        itd.Mode = GPIO_MODE_AF_PP;
        itd.Pull = GPIO_NOPULL;
        itd.Speed = GPIO_SPEED_FREQ_HIGH;

But AFAICT it's game over for this IC/package if I want to have a functional send/receive USB+CAN board, right? Perhaps it should be stated in the README alongside the STM32F103 remark?

Wronge Controller in Makefile

Currently it is:

candleLight:
        $(MAKE) CHIP=STM32F042x6 BOARD=candleLight bin

flash-candleLight:
        $(MAKE) CHIP=STM32F042x6 BOARD=candleLight board-flash

cantact:
        $(MAKE) CHIP=STM32F072xB BOARD=cantact bin

flash-cantact:
        $(MAKE) CHIP=STM32F072xB BOARD=cantact board-flash

but it has to be vice versa. Cantact uses F042 and candelight uses F072.

Build Error

I'm using the same toolchain i use to build canable firmware, trying to make BOARD=all i have the error:

arm-none-eabi-gcc: error: nano.specs: No suche file of directory

CandleLight, CANtact and CAN 2.0b messages

Dear Hubert,
I've been trying to interface with a CAN bus that uses the CAN 2.0b 29bit header format instead of the more typical CAB 2.0a 11bit format.
I'm trying to understand from docs or other if CANtact and CandleLight should be able to process these packets. Could you give me some pointers if this hould work out of the box, or if I need to take any special steps.

Yours,
Hrob.

/usr/bin/objcopy: Unable to recognise the format of the input file `candleLight_fw'

 CC='/usr/bin/arm-none-eabi-gcc' CFLAGS="--specs=nosys.specs" CMAKE_OBJCOPY="/usr/lib/arm-none-eabi/bin/objcopy" cmake .
make VERBOSE=1
/usr/bin/cmake -S/home/brandon/candleLight_fw -B/home/brandon/candleLight_fw --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/brandon/candleLight_fw/CMakeFiles /home/brandon/candleLight_fw/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory '/home/brandon/candleLight_fw'
make -f libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/build.make libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/depend
make[2]: Entering directory '/home/brandon/candleLight_fw'
cd /home/brandon/candleLight_fw && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/brandon/candleLight_fw /home/brandon/candleLight_fw/libs/STM32_HAL /home/brandon/candleLight_fw /home/brandon/candleLight_fw/libs/STM32_HAL /home/brandon/candleLight_fw/libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/brandon/candleLight_fw'
make -f libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/build.make libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/build
make[2]: Entering directory '/home/brandon/candleLight_fw'
make[2]: Nothing to be done for 'libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/build'.
make[2]: Leaving directory '/home/brandon/candleLight_fw'
[ 23%] Built target STM32_HAL_STM32F072xB
make -f libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/build.make libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/depend
make[2]: Entering directory '/home/brandon/candleLight_fw'
cd /home/brandon/candleLight_fw && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/brandon/candleLight_fw /home/brandon/candleLight_fw/libs/STM32_USB_Device_Library /home/brandon/candleLight_fw /home/brandon/candleLight_fw/libs/STM32_USB_Device_Library /home/brandon/candleLight_fw/libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/brandon/candleLight_fw'
make -f libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/build.make libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/build
make[2]: Entering directory '/home/brandon/candleLight_fw'
make[2]: Nothing to be done for 'libs/STM32_USB_Device_Library/CMakeFiles/STM32_USB_Device_Library_STM32F072xB.dir/build'.
make[2]: Leaving directory '/home/brandon/candleLight_fw'
[ 26%] Built target STM32_USB_Device_Library_STM32F072xB
make -f CMakeFiles/candleLight_fw.dir/build.make CMakeFiles/candleLight_fw.dir/depend
make[2]: Entering directory '/home/brandon/candleLight_fw'
cd /home/brandon/candleLight_fw && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /home/brandon/candleLight_fw /home/brandon/candleLight_fw /home/brandon/candleLight_fw /home/brandon/candleLight_fw /home/brandon/candleLight_fw/CMakeFiles/candleLight_fw.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/home/brandon/candleLight_fw'
make -f CMakeFiles/candleLight_fw.dir/build.make CMakeFiles/candleLight_fw.dir/build
make[2]: Entering directory '/home/brandon/candleLight_fw'
[ 27%] Linking C executable candleLight_fw
/usr/bin/cmake -E cmake_link_script CMakeFiles/candleLight_fw.dir/link.txt --verbose=1
/usr/bin/arm-none-eabi-gcc --specs=nosys.specs  -mcpu=cortex-m0 -mthumb -O -Wall -Wextra -g3 -nostartfiles -Xlinker --gc-sections --specs=nano.specs -T /home/brandon/candleLight_fw/ldscripts/ldscript.ld CMakeFiles/candleLight_fw.dir/src/usbd_desc.c.o CMakeFiles/candleLight_fw.dir/src/usbd_gs_can.c.o CMakeFiles/candleLight_fw.dir/src/usbd_conf.c.o CMakeFiles/candleLight_fw.dir/src/can.c.o CMakeFiles/candleLight_fw.dir/src/dfu.c.o CMakeFiles/candleLight_fw.dir/src/flash.c.o CMakeFiles/candleLight_fw.dir/src/gpio.c.o CMakeFiles/candleLight_fw.dir/src/led.c.o CMakeFiles/candleLight_fw.dir/src/queue.c.o CMakeFiles/candleLight_fw.dir/src/timer.c.o CMakeFiles/candleLight_fw.dir/src/util.c.o CMakeFiles/candleLight_fw.dir/src/main.c.o CMakeFiles/candleLight_fw.dir/src/interrupts.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_can.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_cortex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_dma.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_flash.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_flash_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_gpio.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_i2c.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_i2c_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_pcd.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_pcd_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_pwr.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_pwr_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_rcc.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_rcc_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_tim.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal_tim_ex.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/newlib/assert.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/newlib/_exit.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/newlib/_sbrk.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/newlib/_startup.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/newlib/_syscalls.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/cortexm/exception_handlers.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/cortexm/_initialize_hardware.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/cortexm/_reset_hardware.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/cmsis/system_stm32f0xx.c.o libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/cmsis/startup_stm32f072xb.S.o  -o candleLight_fw libs/STM32_USB_Device_Library/libSTM32_USB_Device_Library_STM32F072xB.a 
/usr/bin/objcopy -O binary candleLight_fw candleLight_fw.bin
/usr/bin/objcopy: Unable to recognise the format of the input file `candleLight_fw'
make[2]: *** [CMakeFiles/candleLight_fw.dir/build.make:320: candleLight_fw] Error 1
make[2]: *** Deleting file 'candleLight_fw'
make[2]: Leaving directory '/home/brandon/candleLight_fw'
make[1]: *** [CMakeFiles/Makefile2:106: CMakeFiles/candleLight_fw.dir/all] Error 2
make[1]: Leaving directory '/home/brandon/candleLight_fw'
make: *** [Makefile:84: all] Error 2

It's very odd how CMAKE_OBJCOPY is not successfully being set and /usr/bin/objcopy is being used instead.

proper way to use echo_id

async sendCanFrame(arbitrationId, data) {
    const frame = Buffer.alloc(0x14)
    frame.writeUInt32LE(0xFFFFFFFF, 0x00) // echo_id
    frame.writeUInt32LE(arbitrationId, 0x04) // can_id
    frame.writeUInt8(0x08, 0x08) // can_dlc
    frame.writeUInt8(0x00, 0x09) // channel
    frame.writeUInt8(0x00, 0x0A) // flags
    frame.writeUInt8(0x00, 0x0B) // reserved
    frame.writeUInt8(data[0], 0x0C)
    frame.writeUInt8(data[1], 0x0D)
    frame.writeUInt8(data[2], 0x0E)
    frame.writeUInt8(data[3], 0x0F)
    frame.writeUInt8(data[4], 0x10)
    frame.writeUInt8(data[5], 0x11)
    frame.writeUInt8(data[6], 0x12)
    frame.writeUInt8(data[7], 0x13)
    return this.device.transferOut(this.outEndpoint.endpointNumber, frame)
  }

When I write a CAN frame over USB, it gets echoed back to me. Is there a way to not do this?

STM32F407VG support

I bought stm32f4discovery + SN65HVD230

what do I need to change in this repo to compile this firmware for this device to make it support the STM32F407VG chip?

CANable Pro & candleLight_fw: doesn't work anymore

I used this CAN adapter (CANable PRO) with candleLight fw to develop my thesis project. It has worked well.

I tested the system today but seems that the CAN adapter has a problem with last Linux/firmware (or both):

  1. I'm running fedora 33 with Linux vaio 5.10.19-200.fc33.x86_64 #1 SMP Fri Feb 26 16:21:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  2. Looking into kernel commit I noted this -> can: gs_usb: fix endianess problem with candleLight firmware
  3. Canble pro update page reports new firmware availble:
  4. I tested both (a8a0757 and 68df7d5 1/3/21 BETA) and doesn't work.

~ $ dmesg  | tail -n 7
[59704.827955] usb 3-2: new full-speed USB device number 15 using xhci_hcd
[59704.955316] usb 3-2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[59704.955323] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[59704.955326] usb 3-2: Product: canable gs_usb
[59704.955328] usb 3-2: Manufacturer: canable.io
[59704.955330] usb 3-2: SerialNumber: 00020009524E430220373533
[59704.957981] gs_usb 3-2:1.0: Configuring for 1 interfaces

Left term candump, right term cangen.
ezgif com-video-to-gif

PS: it works fine with slcand

objcopy should use arm-linux-eabi-objcopy

Compilation fails on Ubuntu 19.10 with the following error :

/usr/bin/objcopy: Unable to recognise the format of the input file `canable_fw'
make[3]: *** [CMakeFiles/canable_fw.dir/build.make:320: canable_fw] Error 1
make[3]: *** Deleting file 'canable_fw'
make[2]: *** [CMakeFiles/Makefile2:150: CMakeFiles/canable_fw.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:162: CMakeFiles/canable_fw.dir/rule] Error 2
make: *** [Makefile:144: canable_fw] Error 2

In CMakeFiles/canable_fw.dir/build.make:320 the command should use the cross-compiler provided objcopy as follows:
arm-none-eabi-objcopy -O binary canable_fw canable_fw.bin

Then compilation succeeds:

romain@romain-PC:~/candleLight_fw/build$ make canable_fw
[ 58%] Built target STM32_HAL_STM32F042x6
[ 67%] Built target STM32_USB_Device_Library_STM32F042x6
[ 70%] Linking C executable canable_fw
   text	   data	    bss	    dec	    hex	filename
  15407	    536	   2012	  17955	   4623	canable_fw
[100%] Built target canable_f

It might be fixed in the CMakeLists.txt but I'm not CMake-literate...

cc: error: unrecognized command line option ‘-mthumb’; did you mean ‘-mtbm’?

sudo apt-get install gcc-arm-none-eabi
git clone https://github.com/candle-usb/candleLight_fw.git
cd candleLight_fw/
cmake .
make
$ make
[  1%] Building C object libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal.c.o
cc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
cc: error: unrecognized command line option ‘-mthumb’; did you mean ‘-mtbm’?
make[2]: *** [libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/build.make:63: libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/src/stm32f0xx/stm32f0xx_hal.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:410: libs/STM32_HAL/CMakeFiles/STM32_HAL_STM32F072xB.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
$ uname -a
Linux debian 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

It seems something wrong with version.h in my build

When I do lsusb -d 1d50:606f -v I get:

...
  iSerial                 3 000500125746430120333932
    iConfiguration          4 fw_9195f08_%as+
...

The same value contain in the file version.h:

$ cat version.h 
#define GIT_HASH "fw_9195f08_%as+"

As I correct recognize the file version.h is automated generate file and "%as+" in define of GIT_HASH looks strange (it seems substitute "%as+" don't pass)

Whats is main goal of "%as+" ?
Is it normal if I see in output of lsusb the value fw_9195f08_%as+?

meaning of PRIMASK in the enable/disable irq logic is reversed

The meaning of primask in the enable/disable irq logic in util.c is backwards. Primask is 1 when IRQs are disable, and 0 when they are enabled. The enable_irq function in util.c enables interrupts when primask is 1, and leaves them disabled when 0. As a result, every queue operation toggles whether interrupts are enabled. The code works since there are so many queue operations, but interrupts are only enabled for about half the time they should be.

Multiple can interfaces showing up

Hello,
I updated my two CANtact with your latest firmware and all looks good except when I plug in one of the boards to my machine (Linux Mint 18) I get can0 and can1 while one board is plunged in.
If I plug another board at the same time (two boards are plunged in) I see can0, can1, can2 and can3.
Did you ever encountered this? I can make can0 work just fine but the other board I am never sure if it is can1 or can2

$ uname -a
Linux oxWorkBox 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

EDIT:
So it looks like when I plug in first board can0 is actual interface. When I plug in second board then can2 is actual interface. So not sure what can1 and can3 is for.

$ dmesg | grep can
[ 0.000000] mtrr_cleanup: can not find optimal value
[ 0.000000] Scanning 1 areas for low memory corruption
[ 0.618381] Scanning for low memory corruption every 60 seconds
[ 0.658720] rtc_cmos 00:02: RTC can wake from S4
[ 0.711672] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 34.866347] usb 3-1.3: Product: cantact gs_usb
[ 591.417142] usb 3-1.2: Product: cantact gs_usb

$ lsusb
Bus 003 Device 007: ID 1d50:606f OpenMoko, Inc.
Bus 003 Device 008: ID 1d50:606f OpenMoko, Inc.

WinUSB driver support

Have you attempted to write a driver for candleLight on Windows? I'm wondering how easy it would be to write a Python library that interfaces with the WinUSB device to add candleLight to python-can on Windows. Any suggestions?

https://github.com/hardbyte/python-can/

when 32 bit ms counter folded, led may be ON by mistake? how to avoid that?

candleLight_fw/src/led.c

Lines 94 to 98 in e6b9724

static void led_update_normal_mode(led_state_t *led)
{
uint32_t now = HAL_GetTick();
led_set(led, led->off_until < now);
}

49.7 days, after that, folding will happens on an uint32_t counter, ticking every 1ms.
2 ** 32 / 1000 / 60 / 60 / 24 = 49.7 Days

Image this 2 cases:

assert( now == 0x0000'FFF3 );
off_until = now + 0x80;
assert( off_until == 0x0001'0073 );
assert( (off_until  < now) == false);

assert( now == 0xFFFF'FFF3 );
off_until = now + 0x80;  // folding happens
assert( off_until == 0x0000'007 );
assert( (off_until  < now) == true);

led may be ON by mistake when foding happed in case 2.

May this worry realy happens in chance?
Any solution, pattern to solve this folding problem, other than extend 32 bit counter to an endless 64 bit one?

How about:

bool is_former_nearly_beyound_by_later(uint32_t former, uint32_t later);
led_set(led, is_former_near_beyound_by_later(led->off_until, now));   

"nearly" means diff is not more than half of UINT32_MAX, namely 24.85 days.

bool is_former_near_beyound_by_later(uint32_t former, uint32_t later)
{
    uint32_t diff = later - former;
    return (diff & 0x8000'0000) == 0 ? true : false;
}

We have cons now: 1) half duration range; 2) slower beyounding detection; however archived "zero mistake chance".

Some experimens shows that folding will not case error any more, after some folding resist way applyed:
https://onlinegdb.com/D2ZBIRjp3

Cmake scripts, clear code in main loop, led ... candleLight shows an good study example, I learned a lot from this amazing project.
Thanks!

Device crashes when many messages transmitted with no ACK received

Hi there

Firstly, thank you for making this great open source project. It's wonderful to have a range of open source high performance CAN devices which are enabled by this firmware.

I am testing here with the Canable Pro sending instructions to a network of motors (the project can be seen here https://github.com/elliotwoods/MuscleMemory ).

I am using this API for sending on Windows 10 x64:
https://github.com/elliotwoods/Candle.NET/tree/main/Candle

I'm trying to debug an issue where the Canable-candlelight device stops sending messages during long sessions.

Specifically, the issue seems to be if I send many messages (e.g. perhaps 32,000,000) with no ACK response (e.g. the target device is not connected/isn't ready to receive CAN), then the Canable-candlelight device stops responding.

The only way to fix it is to power cycle the Canable-candlelight device.
Restarting the software, or disabling/enabling the Canable-candlelight USB in device manager does not fix the problem.

Given these symptoms, it appears that the issue is not in the driver, but is in the firmware (or the hardware).
Perhaps the firmware's Tx buffer becomes full as it tries to re-send the failed messages.

Is this a known issue? Is there a way to either:

  1. Reset the firmware from the driver
  2. Reset the Tx re-send buffer
  3. Set a maximum number of send retries

Thank you
Elliot

[RFC] add git commit hash to USB serial / product string

I'm working with 2 devices and jumping accross many branches, rebasing, etc, and I'm easily confused as to which build my devices are actually running.

I'm thinking it might be nice to add a short git hash (as produced by git rev-parse --short HEAD to one of the USB strings, but I'm not sure which one

  • iSerial is already the built-in ID of the chip, and I think it's not the right place for a fw version anyway
  • append to iProduct ? ugly, and irrelevant..
  • add another USB string ID ? haven't looked into this, might be the way to go...
  • some other mechanism ?
  • is it even a good idea ?

STM32F105 compatibility

I am considering the possiblity of putting candleLight on a board with STM32F105RBT6 and two tranceivers and, knowing of the incompatibilty with STM32F103, I am wondering if the same kind of issues stand for STM32F015.

That board is the maybe-some-of-you-already-know-about "18 in 1 canbus filter" which actually have no default breakout usb so feasibility of the whole operation is not obvious, even if the firmware and the silicon are compatible.

Looking at the documentation my guess is that it does not have the same issues of STM32F103 because buffer RAM is not shared. Also USB is Full Speed and OTG, so capable to act as a device.

image

Are there any other problem preventing candleLight usage on STM32F015, e.g. library incompatibility?

CAN able pro flashed with latest version of firmware no windows drivers

I recently received 2 new CANable devices and flashed the latest firmware using the webpage app on the canable website. The firmware flashes without error but when re insert the devices i get two usb devices under win7 without drivers. The first is gs usb and the 2nd is a programming port. Win7 reports that no drivers are installed and cangroo does not see any devices.

LEDs on CANable

The LEDs on the CANable with candlelight can be a bit confusing (no LEDs illuminated on powerup)--I've updated it in my forked repo (which is way behind) but I would like to get some changes in the upstream repo if possible.

I'll pull a PR together for the LED state changes, but I would also like to add blinking of both LEDs on powerup. Is there a preferred place I should add this to the CANable-specific code? This could also apply to other boards if that would make sense.

FYI, for the LEDs I simply swapped the polarity for the Green LED.

  • Interface down: Blue LED is "on", Green LED is "off" (indicates that the device is powered up)
  • Interface up: Blue LED is "off", Green LED is "on" (indicates that the interface is up)

Thanks!

Supporting different processor families

Hey! I'm working on porting candlelight firmware to another processor of a different family (specifically the G431).

I have adapted the existing cmake build system to compile for multiple targets of different processor types/families, pulling in the correct CMSIS, HAL libraries, startup files, linker files, etc for each. It's a bit rough around the edges at the moment, but it does work!

Is there any interest in mainlining support for processors from other families using cmake? It would be great to merge in this work once I have it cleaned up a bit more. I was initially planning on forking for the G431 processor, but keeping a common codebase between processors would be fantastic.

dfu-util : can't detach, device does not revert to application code after reflash

Quite annoying. Tried with and without -R, tried a fix suggested at https://community.st.com/s/question/0D50X00009XkhcT/application-fails-to-start-after-dfu-leave (forcing a reset of the USB peripheral), no success : device still boots right back into DFU mode.

dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
dfu-util: can't detach


$ dfu-util -l

Found Runtime: [1d50:606f] ver=0000, devnum=105, cfg=1, intf=1, path="1-3", alt=0, name="cannette firmware upgrade interface", serial="003800254250431420363230"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=1, name="@Option Bytes  /0x1FFFF800/01*016 e", serial="FFFFFFFEFFFF"
Found DFU: [0483:df11] ver=2200, devnum=12, cfg=1, intf=0, path="5-1", alt=0, name="@Internal Flash  /0x08000000/032*0001Kg", serial="FFFFFFFEFFFF"

Beginning work on porting to STM32G4x for FD CAN

I'm currently using candleLight in a commercial project (that will hopefully release by next year) but I'm already looking at CAN FD since vehicles will be using that soon (or some now I guess). Has anybody looked at doing a similar project with the STM32G series that does CAN FD?

Interestingly the STM32G47x µCs have 3 CAN FD controllers. That might pair up nicely with the Microchip dual can transceiver as a dual CAN FD to USB interface.

Clean software reset canable

In our system, we have three STM32F042C4 microcontrollers running canable. In our work, we often will trigger a software reset of the system (our main CPU is running Linux kernel version 4.9.133).

Every once in a while (the average failure rate is around 10%), one of the three chips will not get through the initialization process. This problem only seems to occur when we do a software reset. If you trigger a complete reset (by, say, doing a full power cycle), all three devices will always initialize properly.

Our hunch is that there are variables keeping their state in memory, and that after the reset, this dirty state is causing it to hang.

For example, when the request comes in to set the HOST_FORMAT to 0x0000BEEF, the canable device accepts the input happily. But, when the BITTIMING request comes in, which follows a very similar logic path, we (when the failure occurs) get nothing but not-ready NAK responses.

I've attached the portion of USB communication logs between the host and our canable device where most of the initialization is performed, and the trouble spot where we get endless NAKs. Please let me know if I can give any other useful information! I have limited ability to debug things further with the packet sniffer used to get these logs, but I do have the ability to iterate and change the firmware code itself.
USBLog_SoftRebootLostAddr3.txt

candleLight for BluePill

Hello guys, i tried porting this project to stm32f103/bluePill with no success since I can't find a compatible HAL lib. (on their website there is only the newest version which is not compatible/has other function signatures)

Do you have any ideas where I can find an HAL lib which works with this project and stm32f1xx cores? Or are there any plans to support these cores? They seem to be pin compatible.

Udev rules to bind specific dongle's SN to specific interface name

Hi and thanks for that great work (including awesome approach to getting uniq SN).

In my setup I have several CAN-to-USB dongles (500k, 125k), and AFAIK CAN bus environment very sensitive with CAN controller setting (esp. bus speed setting).

I need some approach to udev rules for binding dongles with specific Serial Numbers with specific interface's names.
I case for using dongles based on SLCAN it simple task with following solution /etc/udev/rules.d/cantact.rules:

KERNEL=="ttyUSB*",  ATTRS{serial}=="000500127746430120333937", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="606f", MODE:="0777", SYMLINK+="ttyCAN0_500k"

KERNEL=="ttyUSB*",  ATTRS{serial}=="000500127746430120333939", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="606f", MODE:="0777", SYMLINK+="ttyCAN0_125k"

For gs_usb dongles I would like to have something similar to:

ACTION=="add" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="606f", ATTRS{serial}=="000500127746430120333937", MODE="660", GROUP="users", TAG+="uaccess", RUN+="ip link set canX type can bitrate 500000 && ifconfig canX up"

ACTION=="add" SUBSYSTEMS=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="606f", ATTRS{serial}=="000500127746430120333939", MODE="660", GROUP="users", TAG+="uaccess", RUN+="ip link set canY type can bitrate 125000 && ifconfig canY up"

But I don't know the way to define canX and canY.
How can I do binding SN=000500127746430120333937 to can0 (for example) and SN=000500127746430120333939 to can1?

Canable at 1mbps gives CRC errors

I noticed a constant issue with the canable when using it at 1mbps giving constant CRC errors. I'm not sure if its due to the lack of an oscillator or an issue with the clock frequency. Just wanted to let you know. I tested an MCP2515 based interface and had no problems.

Where to find documentation of gs_usb iterface?

Hi!
I'd like to use the firmware with libusb e.g. from MacOS. Is there some documentation of the gs_usb interface that you implemented? With libusb I can directly send requests to the usb device so all I need is to set the data rate (e.g. to 500kHz for OBDII) and then send and receive data packets.

Thanks!

Nonfunctional with kernel 4.9+

Have you attempted to use the candleLight with kernels 4.9 and later? I get a stack trace and error when running on these kernels. I have tested across multiple hardware versions and kernel versions, and the problem occurs beginning with kernel 4.9.

[   43.354559] usb 2-2: new full-speed USB device number 3 using ohci-pci
[   43.666367] CAN device driver interface
[   43.667960] ------------[ cut here ]------------
[   43.667967] WARNING: CPU: 1 PID: 872 at drivers/usb/core/hcd.c:1584 usb_hcd_map_urb_for_dma+0x42a/0x550 [usbcore]
[   43.667968] transfer buffer not dma capable
[   43.667970] Modules linked in: gs_usb(+) can_dev cfg80211 rfkill crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul snd_intel8x0 glue_helper ablk_helper snd_ac97_codec cryptd ppdev snd_pcm psmouse i2c_piix4 input_leds snd_timer e1000 video fjes intel_agp intel_gtt joydev intel_cstate intel_rapl_perf snd soundcore mousedev ac97_bus led_class pcspkr mac_hid battery ac parport_pc parport evdev button acpi_cpufreq tpm_tis tpm_tis_core tpm sch_fq_codel vboxvideo(O) ttm drm_kms_helper drm syscopyarea sysfillrect sysimgblt fb_sys_fops vboxsf(O) vboxguest(O) ip_tables x_tables ext4 crc16 jbd2 fscrypto mbcache hid_generic usbhid hid sr_mod sd_mod cdrom ata_generic pata_acpi ohci_pci serio_raw atkbd libps2 ehci_pci ahci ata_piix libahci ehci_hcd ohci_hcd libata
[   43.668009]  usbcore usb_common scsi_mod i8042 serio
[   43.668014] CPU: 1 PID: 872 Comm: systemd-udevd Tainted: G           O    4.9.11-1-ARCH #1
[   43.668016] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[   43.668017]  ffffc90005333760 ffffffff81305830 ffffc900053337b0 0000000000000000
[   43.668020]  ffffc900053337a0 ffffffff8107eb3b 0000063000000000 ffff8801fab356c0
[   43.668022]  0000000000000000 ffff8802157ff800 0000000000000001 ffff8802141cb000
[   43.668025] Call Trace:
[   43.668029]  [<ffffffff81305830>] dump_stack+0x63/0x83
[   43.668032]  [<ffffffff8107eb3b>] __warn+0xcb/0xf0
[   43.668034]  [<ffffffff8107ebbf>] warn_slowpath_fmt+0x5f/0x80
[   43.668039]  [<ffffffffa00a189a>] usb_hcd_map_urb_for_dma+0x42a/0x550 [usbcore]
[   43.668042]  [<ffffffff8118a9f5>] ? __alloc_pages_nodemask+0xf5/0xef0
[   43.668045]  [<ffffffffa00a28c5>] usb_hcd_submit_urb+0x335/0xb30 [usbcore]
[   43.668047]  [<ffffffff810b5d7a>] ? update_curr+0x6a/0x190
[   43.668051]  [<ffffffffa00a4274>] usb_submit_urb+0x2f4/0x560 [usbcore]
[   43.668053]  [<ffffffff813061f2>] ? get_from_free_list+0x42/0x50
[   43.668056]  [<ffffffffa00a4a1e>] usb_start_wait_urb+0x6e/0x170 [usbcore]
[   43.668060]  [<ffffffffa00a4bfc>] usb_control_msg+0xdc/0x120 [usbcore]
[   43.668063]  [<ffffffffa038922b>] gs_usb_probe+0x7b/0x5b0 [gs_usb]
[   43.668065]  [<ffffffff8145e6f0>] ? __pm_runtime_set_status+0x1c0/0x270
[   43.668076]  [<ffffffffa00a9459>] usb_probe_interface+0x159/0x2d0 [usbcore]
[   43.668079]  [<ffffffff81452713>] driver_probe_device+0x223/0x430
[   43.668081]  [<ffffffff814529ff>] __driver_attach+0xdf/0xf0
[   43.668083]  [<ffffffff81452920>] ? driver_probe_device+0x430/0x430
[   43.668085]  [<ffffffff8145024c>] bus_for_each_dev+0x6c/0xc0
[   43.668088]  [<ffffffff81451e5e>] driver_attach+0x1e/0x20
[   43.668090]  [<ffffffff81451880>] bus_add_driver+0x170/0x270
[   43.668092]  [<ffffffff814533c0>] driver_register+0x60/0xe0
[   43.668095]  [<ffffffffa00a7fa1>] usb_register_driver+0x81/0x140 [usbcore]
[   43.668097]  [<ffffffffa007c000>] ? 0xffffffffa007c000
[   43.668100]  [<ffffffffa007c01e>] gs_usb_driver_init+0x1e/0x1000 [gs_usb]
[   43.668102]  [<ffffffff81002190>] do_one_initcall+0x50/0x180
[   43.668105]  [<ffffffff8117f6ee>] do_init_module+0x5f/0x1f1
[   43.668108]  [<ffffffff8110d364>] load_module+0x2384/0x2a50
[   43.668110]  [<ffffffff8110a240>] ? symbol_put_addr+0x50/0x50
[   43.668113]  [<ffffffff811cb32a>] ? vmap_page_range_noflush+0x25a/0x350
[   43.668115]  [<ffffffff8110dba4>] SyS_init_module+0x174/0x190
[   43.668117]  [<ffffffff81003b64>] do_syscall_64+0x54/0xc0
[   43.668119]  [<ffffffff8160abab>] entry_SYSCALL64_slow_path+0x25/0x25
[   43.668145] ---[ end trace 9f8b0186c8e48867 ]---
[   43.668149] gs_usb 2-2:1.0: Couldn't send data format (err=-11)
[   43.668155] gs_usb: probe of 2-2:1.0 failed with error -11
[   43.668216] usbcore: registered new interface driver gs_usb

Trace from kernel 4.9.11-1-ARCH
Reproduced on VirtualBox VM
Reproduced on 2013 Macbook Pro

Maintainer / which clone to use

Hi, first of all thanks for this project. It seems a much better approach for Linux then the slcan driver. There are some trivial issues / merge request open here for more then half a year, which I can happily send a fix for and add some other improvements, but makes me wonder if we shouldn't use another fork as "upstream" of someone who has some time (and skills) to maintain it more actively.

@HubertD , @normaldotcom, @nexulm any thoughts about that? or are you all fine with randomly merging from other forks?

Cantable clone fw

Hi i've made a canable clone and i've tryed to flash both the binaries avilable but i have no usb device showing up nor any led activity, i guess that the problem is that canable has StM32F04 with internal oscillator, while candlelight board has F07 internal oscillator and cantact has F04 external oscillator, i guess in the makefile there is the need of a new board definition ? Sorry i'm not very much into making firmwares.
Thanks.

canable device hangs after the host computer reboot

Hi All,

I have a very strange issue. I am using a canbale clone hardware with candlelight firmware. The clone is a part of another pcb and the STM32F0 is powered separately in stead of usb 5v. Therefore while using the device communicating with another can device, if the host computer reboots, the canbale device gets hanged. The device is correctly getting configured on the host computer. But I cannot send/receive any data until I reset the power of STM32F0.

The probable solution is to power the STM32F0 by USB 5v which is now not possible as the STM32F0 is part of another board. My question is is there a way to reset the STM32F0 from the USB side from the HOST computer? or Is this the expected behavior?

Firmware Error Handling

There seems to be a problem with the firmware after an error on the CAN Bus occured:

 (2020-08-26 10:16:07.727451)  can0  RX - -  0030A301   [0]                            ''
 (2020-08-26 10:16:07.727922)  can0  RX - -  00316F13   [8]  43 53 CE C0 03 51 00 00   'CS...Q..'
 (2020-08-26 10:16:09.812794)  can0  RX - -  2000000C   [8]  00 00 04 00 00 00 00 00   ERRORFRAME
	controller-problem{}
	protocol-violation{{bit-stuffing-error}{}}

which leads to any valid CAN frame afterwards will be attended by

 (2020-08-26 10:16:09.813001)  can0  RX - -  2000000C   [8]  00 00 02 00 00 00 00 00   ERRORFRAME
	controller-problem{}
	protocol-violation{{frame-format-error}{}}

and later attended by

 (2020-08-26 10:17:30.235544)  can0  RX - -  20000004   [8]  00 0C 00 00 00 00 00 00   ERRORFRAME
	controller-problem{rx-error-warning,tx-error-warning}

or

(2020-08-26 10:17:49.675803)  can0  RX - -  20000004   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
	controller-problem{}

Some additional frames later these error frames disappear and the CAN adapter seems to work as expected.
Checked with usbmon that the wrong error frames come from the USB device.

This error is reproducible.

Environment:

actual candlelight_fw/cantact firmware on Electrodragon cantact clone
Ubuntu Linux 20.04 Linux 5.4.0-42-generic with
sudo ip link set can0 up type can bitrate 250000 restart-ms 100

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.