Hi,I tested the OpenMV N6 CAN firmware you provided, and I found an issue with CAN transmission.The OpenMV N6 can transmit the CAN ID successfully, and PCAN-View can receive the frame with ID 0x125. However, the received frame always has DLC/Length = 0, and the Data field is empty.
Test setup:
- Board: OpenMV N6
- Firmware: the firmware.bin you provided
- CAN tool: PCAN-USB + PCAN-View
- Bitrate: 1 Mbps
- CAN ID: 0x125
Test code:
from machine import CAN
import time
can = CAN(1, bitrate=1_000_000)
can.set_filters(None)
while True:
data = bytes([0x10, 0x12, 0x12, 0x12, 0x12, 0x21, 0x21, 0x02])
ret = can.send(0x125, data, 0)
print(“send ret =”, ret, “len =”, len(data), “data =”, data.hex())
time.sleep_ms(1000)
The serial output is:
send ret = 0 len = 8 data = 1012121212212102
So the Python layer is definitely passing an 8-byte payload to can.send(), and send() does not return None.
But in PCAN-View, the received frame is:
CAN-ID = 125h
Length = 0
Data = empty
Also, when PCAN-View sends a CAN frame to the OpenMV N6, the OpenMV can correctly receive both the CAN ID and the payload data. Therefore, the CAN wiring, transceiver, termination, and bitrate should be correct. The problem seems to be in the OpenMV N6 firmware CAN transmit path.
I suspect this may be a DLC encoding issue in the STM32N6 FDCAN HAL.
Please check this file:
lib/stm32/n6/src/stm32n6xx_hal_fdcan.c
Specifically, the function:
FDCAN_CopyMessageToRAM()
In the MicroPython FDCAN layer, DataLength appears to already be encoded as:
txmsg->DataLength = (dlc << 16)
However, in the STM32N6 HAL, if FDCAN_CopyMessageToRAM() does this again:
(pTxHeader->DataLength << 16U)
then the DLC field will be shifted twice, which would make the actual transmitted DLC become 0. This matches the behavior observed in PCAN-View: correct CAN ID, but Length = 0 and no data.
Suggested fix:
Change this:
TxElementW2 = ((pTxHeader->MessageMarker << 24U) |
pTxHeader->TxEventFifoControl |
pTxHeader->FDFormat |
pTxHeader->BitRateSwitch |
(pTxHeader->DataLength << 16U));
to:
TxElementW2 = ((pTxHeader->MessageMarker << 24U) |
pTxHeader->TxEventFifoControl |
pTxHeader->FDFormat |
pTxHeader->BitRateSwitch |
pTxHeader->DataLength);
And change this:
for (ByteCounter = 0; ByteCounter < DLCtoBytes[pTxHeader->DataLength]; ByteCounter += 4U)
to:
for (ByteCounter = 0; ByteCounter < DLCtoBytes[pTxHeader->DataLength >> 16U]; ByteCounter += 4U)
This should make the STM32N6 FDCAN HAL behavior consistent with the STM32H7 FDCAN HAL implementation.Could you please help rebuild a fixed firmware.bin for me?If possible, please also provide the corresponding .elf and .map files, so that future firmware-level issues can be located more easily.