MCU manager with STM32H750B_dk #81421

MaazSk · 2024-11-15T06:50:19Z

MaazSk
Nov 15, 2024

I am using STM32H750B_DK which has an internal flash of 128K, I am trying to use smp_svr example located at subsys/mgmt/mcumgr/smpsvr My overlay file is as below


/ {
	chosen {
		zephyr,code-partition = &storage_partition;
	};
};


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

		slot0_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 DT_SIZE_K(109)>;
		};
		storage_partition: partition@1B400 {
				label = "image-0";
				reg = <0x0001B400 DT_SIZE_M(22)>;
		};
	};
};


&quadspi {
	pinctrl-names = "default";
	pinctrl-0 = <&quadspi_clk_pf10 &quadspi_bk1_ncs_pg6
		     &quadspi_bk1_io0_pd11 &quadspi_bk1_io1_pf9
		     &quadspi_bk1_io2_pf7 &quadspi_bk1_io3_pf6
		     &quadspi_bk2_io0_ph2 &quadspi_bk2_io1_ph3
		     &quadspi_bk2_io2_pg9 &quadspi_bk2_io3_pg14>;
	dual-flash;
	status = "okay";

	mt25ql512ab1: qspi-nor-flash-1@90000000 {
		compatible = "st,stm32-qspi-nor";
		reg = <0x90000000 DT_SIZE_M(64)>; /* 512 Mbits */
		qspi-max-frequency = <72000000>;
		spi-bus-width = <4>;
		reset-cmd;
		reset-cmd-wait = <20>;
		status = "okay";

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

			slot1_partition: partition@0 {
				label = "image-0";
				reg = <0x00000000 0x1000000>;
			};

			//slot3_partition: partition@1000000{
			//	label = "image-1";
			//	reg = <0x1000000 DT_SIZE_M(64)>;
			//};
		};
	};
};

I am able to build the code but I am unable to sign it because of the memory that I have. Also, I am unable the slots to external memory.

The error with the above overlay I get is as below
.

As it exceeded the memory location and If I change storage partition location to external flash I am unable to flash the code the error that I get is as follows Also the updated overlay is as

&quadspi {
	pinctrl-names = "default";
	pinctrl-0 = <&quadspi_clk_pf10 &quadspi_bk1_ncs_pg6
		     &quadspi_bk1_io0_pd11 &quadspi_bk1_io1_pf9
		     &quadspi_bk1_io2_pf7 &quadspi_bk1_io3_pf6
		     &quadspi_bk2_io0_ph2 &quadspi_bk2_io1_ph3
		     &quadspi_bk2_io2_pg9 &quadspi_bk2_io3_pg14>;
	dual-flash;
	status = "okay";

	mt25ql512ab1: qspi-nor-flash-1@90000000 {
		compatible = "st,stm32-qspi-nor";
		reg = <0x90000000 DT_SIZE_M(64)>; /* 512 Mbits */
		qspi-max-frequency = <72000000>;
		spi-bus-width = <4>;
		reset-cmd;
		reset-cmd-wait = <20>;
		status = "okay";

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

			slot1_partition: partition@0 {
				label = "image-0";
				reg = <0x00000000 DT_SIZE_M(5)>;
			};

			storage_partition: partition@500000{
				label = "image-1";
				reg = <0x500000 DT_SIZE_M(5)>;
			};
		};
	};
};

What should be a way forward. Also, if I remove slot0 from internal flash to external flash I am unable to sign this is the error that I get

----UPDATE 1----
When I made the following changes I am able to sign the file even if I change the partition

/ {
	chosen {
		zephyr,code-partition = &slot0_partition;
		zephyr,flash-controller = &mt25ql512ab1;
		zephyr,flash = &mt25ql512ab1;
	};
};

----UPDATE 2----

I am able to update the code to the device but now I am having difficulty using AuTerm or zephyr mcumgr cli. Is there a tutorial or something how to use the mcumgr cli?

When ever I am using Auterm it is giving me a timeout error

JPHutchins · 2024-11-19T06:03:40Z

JPHutchins
Nov 19, 2024

Hi, I'd be happy to help with usage of smpmgr: https://github.com/intercreate/smpmgr

It looks like you're wanting to use a USB CDC ACM transport for SMP? Does it enumerate as a USB device to the OS? I don't see the zephyr,uart-mcumgr chosen defined. Here's an example overlay used for testing UART (not USB), for example: https://github.com/intercreate/smpclient/blob/main/dutfirmware/stm32f4_disco_serial_overlay.dts

Would you like the SMP server to be running on your application, in the bootloader, or both?

31 replies

MaazSk Nov 22, 2024
Author

When did a image read I got the following response which states

No image on device

.\smpmgr.exe --loglevel DEBUG --mtu 1024 --port COM9 image state-read
[20:58:57] INFO Console log level: DEBUG - smpmgr\logging.py:91 logging.py:91
INFO Options(timeout=2.0, transport=TransportDefinition(port='COM9', ble=None), mtu=1024) - main.py:74
smpmgr\main.py:74
INFO Initializing SMPClient with the SMPSerialTransport, options.transport.port='COM9' - common.py:41
smpmgr\common.py:41
DEBUG Initialized SMPSerialTransport - smpclient\transport\serial.py:137 serial.py:137
DEBUG Using proactor: IocpProactor - asyncio\proactor_events.py:634 proactor_events.py:634
DEBUG Connecting to self._conn.port='COM9' - smpclient\transport\serial.py:142 serial.py:142
DEBUG Connected to self._conn.port='COM9' - smpclient\transport\serial.py:147 serial.py:147
DEBUG Sending 9 bytes - smpclient\transport\serial.py:170 serial.py:170
DEBUG Serializing request=b'\x08\x00\x00\x01\x00\x00\x00\x06\xa0' - smp\packet.py:78 packet.py:78
DEBUG Total size of request is 13B - smp\packet.py:84 packet.py:84
DEBUG Total size of b64 encoded request is 20B - smp\packet.py:89 packet.py:89
DEBUG Writing encoded packet of size 23B; self.line_length=1024 - serial.py:174
smpclient\transport\serial.py:174
DEBUG Sent 9 bytes - smpclient\transport\serial.py:185 serial.py:185
DEBUG Waiting for response - smpclient\transport\serial.py:192 serial.py:192
DEBUG Received 27 byte chunk - smpclient\transport\serial.py:291 serial.py:291
DEBUG Response length_and_frame=b'\x00\x10\t\x00\x00\x06\x00\x00\x00\x06\xbfbrc\x08\xffYT' - packet.py:168
smp\packet.py:168
DEBUG length of frame: 16 - smp\packet.py:171 packet.py:171
DEBUG Finished receiving 14 byte response - smpclient\transport\serial.py:198 serial.py:198
WARNING Error reading MCUMgr parameters: header=Header(op=<OP.READ_RSP: 1>, version=<Version.V2: init.py:495
1>, flags=<Flag.UNUSED: 0>, length=6, group_id=0, sequence=0, command_id=6)
version=<Version.V2: 1> sequence=0
smp_data=b'\t\x00\x00\x06\x00\x00\x00\x06\xbfbrc\x08\xff' rc=<MGMT_ERR.ENOTSUP: 8> rsn=None
- smpclient_init.py:495
⠋ Connecting to COM9... OK
DEBUG Sending 9 bytes - smpclient\transport\serial.py:170 serial.py:170
DEBUG Serializing request=b'\x08\x00\x00\x01\x00\x01\x01\x00\xa0' - smp\packet.py:78 packet.py:78
DEBUG Total size of request is 13B - smp\packet.py:84 packet.py:84
DEBUG Total size of b64 encoded request is 20B - smp\packet.py:89 packet.py:89
DEBUG Writing encoded packet of size 23B; self._line_length=1024 - serial.py:174
smpclient\transport\serial.py:174
DEBUG Sent 9 bytes - smpclient\transport\serial.py:185 serial.py:185
DEBUG Waiting for response - smpclient\transport\serial.py:192 serial.py:192
DEBUG Received 51 byte chunk - smpclient\transport\serial.py:291 serial.py:291
DEBUG Response packet.py:168
length_and_frame=b'\x00"\t\x00\x00\x18\x00\x01\x01\x00\xbffimages\x9f\xffksplitStatus\x00\xff
\xd2\xb5' - smp\packet.py:168
DEBUG length of frame: 34 - smp\packet.py:171 packet.py:171
DEBUG Finished receiving 32 byte response - smpclient\transport\serial.py:198 serial.py:198
⠋ Waiting for image states... OK
No images on device!
splitStatus: 0

JPHutchins Nov 22, 2024

I am using a fixed MTU size for now that is 1024. Which is over here what you suggested

Have you set these in your config?

CONFIG_UART_MCUMGR_RX_BUF_SIZE=1024
CONFIG_UART_MCUMGR_RX_BUF_COUNT=1
CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=1024

This log indicates that MCUMgr Params are not enabled:

 _DEBUG Finished receiving 14 byte response - smpclient\transport\serial.py:198 serial.py:198 WARNING Error reading MCUMgr parameters: header=Header(op=<OP.READ_RSP: 1>, version=<Version.V2: **init**.py:495 1>, flags=<Flag.UNUSED: 0>, length=6, group_id=0, sequence=0, command_id=6) version=<Version.V2: 1> sequence=0 smp_data=b'\t\x00\x00\x06\x00\x00\x00\x06\xbfbrc\x08\xff' rc=<MGMT_ERR.ENOTSUP: 8> rsn=None - smpclient__init__.py:495

This option is nice because it prevents the client from having to guess what message sizes to use: https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS

CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS=y

With that enabled, you will see the MTU negotiation succeed and you won't need to use the --mtu flag.

No image on device

This is very odd, given that you are running this code from an image that is on the device! This is the friendly response given by smpmgr for the case that the list of images returned by the device is empty.

At first I wondered if your image was not MCUBoot compatible (no mcuboot metadata, aka header + trailer), but that doesn't seem possible since you are booting into MCUBoot then loading this application from MCUBoot. MCUBoot would not load a non-MCUBoot image AFAIK.

You might consider enabling some logging in MCUBoot, or stepping through MCUBoot with a debugger.

Verify that this is all enabled: https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUMGR_GRP_IMG in your build/zephyr/.config

CONFIG_MCUMGR_GRP_IMG=y

You can find some other relevant options to check on: https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUMGR_GRP_IMG_SLOT_INFO

Is it possible that you are not loading into MCUBoot at all?

MaazSk Nov 25, 2024
Author

Have you set these in your config?

CONFIG_UART_MCUMGR_RX_BUF_SIZE=1024
CONFIG_UART_MCUMGR_RX_BUF_COUNT=1
CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=1024

Yes, I have these configurations.

Verify that this is all enabled: https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MCUMGR_GRP_IMG in your build/zephyr/.config

CONFIG_MCUMGR_GRP_IMG=y

I have this also enabled.

Is it possible that you are not loading into MCUBoot at all?

That won't be the case because I get the following messages which are from the MCU boot only which I belief

*** Using Zephyr OS build v3.7.0-rc3-128-g537277f92558 ***
I: Starting Direct-XIP bootloader
I: Primary slot: version=0.0.7+0
I: Image 0 Secondary slot: Image not found
I: Image 0 loaded from the primary slot
I: Bootloader chainload address offset: 0x0
I: Jumping to the image slot

I am sharing all my configurations which I have in the prj.conf for cross verification in case I missed something

CONFIG_MAIN_STACK_SIZE=4096
CONFIG_BUILD_OUTPUT_META=y
CONFIG_MEMC=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
# CONFIG_MAIN_STACK_SIZE=4096
# CONFIG_NET_BUF_RX_COUNT=16
# CONFIG_NET_BUF_TX_COUNT=16
# CONFIG_MCUMGR_BUF_COUNT=8

# Enable MCUmgr and dependencies.
# CONFIG_ZEPHYR_ZCBOR_MODULE=y
# CONFIG_XIP=y
# CONFIG_STM32_MEMMAP=y
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y
CONFIG_CRC=y
CONFIG_MCUMGR=y
CONFIG_STREAM_FLASH=y
CONFIG_FLASH_MAP=y

# Some command handlers require a large stack.
# CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2304
# CONFIG_MAIN_STACK_SIZE=2048

# Ensure an MCUboot-compatible binary is generated.
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable flash operations.
CONFIG_FLASH=y

# Required by the `taskstat` command.
CONFIG_THREAD_MONITOR=y

# Support for taskstat command
CONFIG_MCUMGR_GRP_OS_TASKSTAT=y

# Enable statistics and statistic names.
CONFIG_STATS=y
CONFIG_STATS_NAMES=y

# Enable most core commands.
CONFIG_FLASH=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_GRP_STAT=y

# Enable logging
CONFIG_LOG=y
CONFIG_MCUBOOT_UTIL_LOG_LEVEL_WRN=y

# Disable debug logging
CONFIG_LOG_MAX_LEVEL=3

# Enable the serial MCUmgr transport.
CONFIG_BASE64=y
CONFIG_CRC=y
CONFIG_MCUMGR_TRANSPORT_UART=y
CONFIG_CONSOLE=y
CONFIG_MCUMGR=y



######
CONFIG_UART_MCUMGR=y
# CONFIG_UART_MCUMGR_RX_BUF_SIZE=128
CONFIG_UART_MCUMGR_RX_BUF_COUNT=1
# CONFIG_UART_SMP_MTU=128

CONFIG_UART_MCUMGR_RX_BUF_SIZE=1024
CONFIG_UART_MCUMGR_RX_BUF_COUNT=1
CONFIG_MCUMGR_TRANSPORT_NETBUF_SIZE=1024

CONFIG_MCUMGR_TRANSPORT_UART_MTU=1024
CONFIG_ZCBOR_MAX_STR_LEN=1024


CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_IMG_UPDATABLE_IMAGE_NUMBER=1
CONFIG_MCUMGR_GRP_IMG_VERBOSE_ERR=y
CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_SECONDARY=y
CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_ANY=y
CONFIG_MCUMGR_GRP_IMG_ALLOW_ERASE_PENDING=y
CONFIG_MCUMGR_GRP_IMG_DIRECT_UPLOAD=y
CONFIG_MCUMGR_LOG_LEVEL_DBG=y

JPHutchins Nov 26, 2024

Seeing the MCUBoot logs is good confirmation that the primary image is being loaded by MCUBoot. Only config to add is:

CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS=y

So that you don't need to specify MTU in SMP clients.

So, the image list (image state-read) still isn't working? Can you try uploading to slot 2 then read the image states again? To upload without "upgrading", use the image management group directly: image upload --slot 2 <path> instead of upgrade --slot 2 <path>.

Unrelated, these options seem risky:

CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_SECONDARY=y
CONFIG_MCUMGR_GRP_IMG_ALLOW_CONFIRM_NON_ACTIVE_IMAGE_ANY=y

MaazSk Nov 26, 2024
Author

Tried to upload but no success it fails it is unable to upload also it fails to read slots. It is unable to open the flash. When I debugged why it is not able to open flash I got the error it is trying to use device_is_ready and it is returning false. When I checked if it is checking for the correct device then it did checked the correct device. But it is not ready the external flash is not ready

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MCU manager with STM32H750B_dk #81421

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 31 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

MCU manager with STM32H750B_dk #81421

MaazSk Nov 15, 2024

Replies: 1 comment · 31 replies

JPHutchins Nov 19, 2024

MaazSk Nov 22, 2024 Author

JPHutchins Nov 22, 2024

MaazSk Nov 25, 2024 Author

JPHutchins Nov 26, 2024

MaazSk Nov 26, 2024 Author

MaazSk
Nov 15, 2024

Replies: 1 comment 31 replies

JPHutchins
Nov 19, 2024

MaazSk Nov 22, 2024
Author

MaazSk Nov 25, 2024
Author

MaazSk Nov 26, 2024
Author