Running Zephyr CANopennode example project on alternate boards

[Eqqm4n]

Using a setup with the Kvaser Leaf3, Nucleo-G01BRE board, and a CANopennode project compiled using the CubeMX IDE, successful CAN communications take place with both reading and writing the object dictionary on the STM32. So, it is known that the wiring for the CAN bus and test scripts running on the Windows PC end are correct. Now it is desired to switch over to Zephyr so that eventually MCUboot can be used to receive new image updates over CAN.

Following the directions from this site:

https://docs.zephyrproject.org/latest/samples/modules/canopennode/README.html

An overlay and config file are created for the STM32G0B1RE, with the fdcan1 set up to match the pin settings from the Cube project:

&fdcan1 {
	clocks = <&rcc STM32_CLOCK_BUS_APB1 0x00001000>,
		 <&rcc STM32_SRC_PLL_Q FDCAN_SEL(1)>;
	pinctrl-0 = <&fdcan1_rx_pc4 &fdcan1_tx_pc5>;
	pinctrl-names = "default";
	status = "okay";
};

But there is an issue compiling the samples/modules/canopennode Zephyr project. The handful of chips that the example has been tested on all apparently have on-chip EEPROMs, but the STM32G0B1RE doesn't seem to. In the example's main.c there is this section of code:

#ifdef CONFIG_CANOPENNODE_STORAGE
				ret = canopen_storage_save(
					CANOPEN_STORAGE_EEPROM);
				if (ret) {
					LOG_ERR("failed to write to EEPROM");
				}
#endif /* CONFIG_CANOPENNODE_STORAGE */

So obviously since there is no EEPROM on the chip, the output terminal just spams "failed to write to EEPROM" over and over. Some of the other example chips have CONFIG_MPU_ALLOW_FLASH_WRITE=y in their config overlays, so if this is added to the STM32G0B1RE overlay along with this in the DTS file:

/delete-node/ &storage_partition;

&flash0 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 DT_SIZE_K(48)>;
			read-only;
		};

		slot0_partition: partition@C000 {
			label = "image-0";
			reg = <0x0000C000 DT_SIZE_K(200)>;
		};

		slot1_partition: partition@3E000 {
			label = "image-1";
			reg = <0x0003E000 DT_SIZE_K(200)>;
		};

		/* next 32KiB reserved for mcuboot scratch space */
		scratch_partition: partition@70000 {
			label = "image-scratch";
			reg = <0x00070000 DT_SIZE_K(32)>;
		};

		/* final 32KiB reserved for app storage partition */
		storage_partition: partition@78000 {
			label = "storage";
			reg = <0x00078000 DT_SIZE_K(32)>;
		};
	};
};

It might be expected that the writes will now be successful after updating CANOPEN_STORAGE_EEPROM to CANOPEN_STORAGE_ROM, however, they still fail. What is the correct way then to get the Zephyr CANopen stack to use the flash storage_partition area to store the object dictionary?

It is possible to remove this error by doing the above and changing the storage type to CANOPEN_STORAGE_RAM, but then a new error pops up, now the terminal just spams <err> canopen_driver: failed to send CAN frame (err -114) and the Python scripts running on the PC end fail to connect to the node. What might be causing this issue?

As a side note, the exact same problems appear to be happening as expressed in this thread...

https://lists.zephyrproject.org/g/users/topic/103148791#msg3307

...the counter example works but the CANopen one does not. Presumably the reason is that the counter example is using a base-level CAN driver rather than CANopen.

[kartben]

@henrikbrixandersen

[henrikbrixandersen]

Not sure where to start here.

There is no EEPROM involved, the Zephyr port of CANopenNode uses the settings subsystem for storing what CANopenNode refers to as "EEPROM" storage location. If your board does not support using the settings subsystem (e.g. if it has no storage partition in flash) you can disable this by setting CONFIG_CANOPENNODE_STORAGE=n.

[Eqqm4n]

Thanks for the reply. As can be seen in the DTS overlay file posted above, there is a storage_partition defined. And with the board config file set to use CONFIG_MPU_ALLOW_FLASH_WRITE=y, the program just spams "failed to write to EEPROM" every loop.

Your note that Zephyr is using flash in place of EEPROM begs the question as to what is to be happening when the CANOPEN_STORAGE_ROM is used instead with the canopen_storage_save call.

I probably should have written this out as two separate questions, but also as stated I have the same issue as outlined in that link where the basic CAN counter project works but the CANopennode project does not, the latter just gives <err> canopen_driver: failed to send CAN frame (err -114) over and over. Using the Kvaser Leaf 3 as a CAN bus sniffer I see the frames going out on the counter example so it's not clear what to troubleshoot on the CANopen side. Given that the original message with the similar problem is over a year old and didn't post a resolution to the issue, this seems to be a long-standing item. I couldn't see any way to send a DM to the author of that thread to ask if they found a solution or not.

[Eqqm4n]

No clue as to what actually happened, but the project just started working on its own even though nothing is apparently different from any of the failures. Despite building the project with the -p "pristine" flag every time, one day it never worked and the next day it suddenly did after numerous recompiles.

Just mentioning this for the sake of completeness. The lingering problem now is finding an object dictionary editor tool that is compatible with the version of the CANopenNode stack used by Zephyr.

[Eqqm4n]

Whoops, I was wrong, it was working because I had that CANOPEN_STORAGE_RAM option set in the main.c file instead of CANOPEN_STORAGE_EEPROM. But the problem though is that the generated object dictionary files don't link up with the Zephyr NVS system, so items that should be getting stored in the flash are all going to RAM anyway.

[Eqqm4n]

Alright so the build log spits this out:

warning: The choice symbol SETTINGS_NVS (defined at subsys/settings/Kconfig:82) was selected (set
=y), but SETTINGS_NONE (defined at subsys/settings/Kconfig:112) ended up as the choice selection.
See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_SETTINGS_NVS and/or look up
SETTINGS_NVS in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.

Given that the flash storage seems to be exactly what I'm having trouble with, in my context this would be more of a fatal error than a warning. After some guesswork adding CONFIG_FLASH_MAP=y to the local prj.conf resolved that warning and the "can't write to EEPROM" error goes away when the code is running. This leaves this last warning:

warning: CAN_MAX_FILTER (defined at drivers/can/Kconfig.mcux:42, drivers/can/Kconfig.mcp2515:30,
drivers/can/Kconfig.loopback:15, drivers/can/Kconfig.native_linux:23,
drivers/can/Kconfig.sja1000:11, drivers/can/Kconfig.mcp251xfd:54, drivers/can/Kconfig.xmc4xxx:38,
drivers/can/Kconfig.max32:13) was assigned the value '13' but got the value ''. Check these
unsatisfied dependencies: ((CAN_MCUX_FLEXCAN && CAN) || (CAN_MCP2515 && CAN) || (CAN_LOOPBACK &&
CAN) || (CAN_NATIVE_LINUX && CAN) || (CAN_SJA1000 && CAN) || (CAN_MCP251XFD && CAN) || (CAN_XMC4XXX
&& CAN) || (CAN_MAX32 && CAN)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_CAN_MAX_FILTER and/or look up
CAN_MAX_FILTER in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too.