Bootloader DFU transport - transfer of init packet

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Wed, 22 May 2024 08:55:15 GMT

Hi Matej,

It's good to hear that things are working now. Regarding your question about dual and single bank updates, the bootloader will automatically perform a single bank update if the app is too large to fit in bank 1 as long as you have not enabled this configuration setting in your bootloader:

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Wed, 22 May 2024 04:45:57 GMT

Hi Vidar,

Most of things are working now, decryption and flashing etc... but I have one additional question about max app size. Bootloader is configured to use dual bank, but in case that someday application won't fit in memory for dual bank I'm expecting to perform update using a single bank.

Now I'm wondering if this is done automatically, or is there need to update bootloader in case that application won't fit anymore? I found some posts which are quite old (post1, post2)

Thank you for all your support!

Best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Fri, 03 May 2024 07:38:00 GMT

Hi Matej,

I see. The bootloader is configured to run with the 'NRF_CRYPTO_BACKEND_CC310_BL_ENABLED' variant of the cc310 runtime library. This is a stripped down version compared to the cc310 library used in our application examples and only includes the features necessary for DFU. The full version of the library is located in /external/nrf_cc310/lib.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Fri, 03 May 2024 07:18:11 GMT

Hi Vidar,

I made some initial dfu packets capture on pca10040, but for project i'm using nRF52840... I'm planning to use AES in bootloader. The scenario is following in post build step application will be encrypted since it's stored in external flash. Then main MCU reads encrypted image and send it to nRF bootloader which will decrypt image.

By default NRF_CRYPTO_BACKEND_CC310_BL_ENABLED is enabled and once I'm trying to enable also NRF_CRYPTO_BACKEND_CC310_ENABLED there is problem with mutex.

Most probably I will implement aes-ctr independent of sdk since the most of things is now working with NRF_CRYPTO_BACKEND_CC310_BL_ENABLED. I have already spent quite some time around this and I'm not sure if there will be so much benefit for switching to CC310 and struggling with new issues, since update will be performed only few times in lifetime of product.

Best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Fri, 03 May 2024 06:49:28 GMT

Hi Matej,

I thought you were using the nRF52832. The bootloader projects for the nRF52840 defaults to using the cc310 to take advantage of the HW accelerated crypto services. Are you attempting to use AES in your application, or in the bootloader?

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Thu, 02 May 2024 15:27:58 GMT

Hi Vidar,

No problem at all... I have switched from uecc to cc310_bl and used prebuild library from sdk and set bootloader settings to version 2 and now signature and verification works as expected...

Unfortunately I have a new problem, with aes-ctr encryption... Since aes-ctr is supported within cc310, but once I enable both of them cc310 and cc310_bl there is problem with mutex...

Do you have any suggestion how to proceed with this? Since cc310_bl is working without problem with signature and verification, most probably I will implement aes-ctr independent of sdk.

BR,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Thu, 02 May 2024 12:39:17 GMT

Hi Matej,

Sorry for the delay. I've been out of the office for a few days. Have you made any progress on this in the meantime. The byte ordering/endianess should be correct when using the default configurations. You can test your uecc library with the BLE bootloader projects to verify if it is working or not.

Did you build the bootloader with your generated public key, and did you use the corresponding private key when signing the FW update?

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Thu, 25 Apr 2024 07:41:29 GMT

Hi Vidar,

Thank you for inputs, will check later in afternoon...

In between I have also tried with required signing of app and unfortunately I hit to another issue with prevalidation.

Init packet is ok transferred - content match to dat file, crc response also match, but on execute command I receive response 5, since ecdsa_verify function returns 0 - meaning signature is not valid (0x8542). I'm using micro ECC library.

I have noticed that there is quite some posts around generating keys with some versions of nrfutil had some problems around byte order and there are also some variations how crypto library is compiled.

devzone.nordicsemi.com/.../key-pair-generation-with-edcsa-secp256k1

devzone.nordicsemi.com/.../prevalidation-failure-on-init-packet-attempting-in-app-dfu-signature-failed-err_code-0x8542

Therefore I kindly ask, if you can provide generated key pair (private+public) for debugging purposes only and prebuild micro_ecc library for nrf52840, to isolate at least this part.

Thank you in advance.

Beste regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Thu, 25 Apr 2024 06:36:44 GMT

I would recommend you try to place a breakpoint at this line in your bootloader:

to confirm if the postvalidation is being run on the first round. This is where the hash of the receivied image is being verified. The image will not be marked as ready for activation if the validation fails.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Wed, 24 Apr 2024 17:42:46 GMT

On first attempt, there is nothing about validation... right after crc response has jumped to 0xa80 and after that boots up like nothing happend - except that app is missing... in next try everything looks like expected.

BR,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Tue, 23 Apr 2024 12:21:12 GMT

Hi Matej,

Did the log indicate if the post-validation step failed or passed on your first attempt (the image hash is validated in this step)?

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Mon, 22 Apr 2024 12:34:34 GMT

Hi Vidar,

I have performed some additionall tests, also switched to single bank update and figured out that "no jump" or switching to new app happens in case that there is already valid application. And this shows up like at first need to perform one update to invalidate current image, the second round of updated it works properly...

Attaching part of logs

1st round - "Invalidating" app

<info> nrf_dfu_serial_uart: Allocated buffer 200005B8
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
<debug> nrf_dfu_req_handler: Offset:155648, CRC:0x4D88F134
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]

At this point stopping at mbr's reset handler 0xa80, pressing continue/play button as suggested

<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<info> app: Boot validation failed. No valid app to boot.
<debug> app: DFU mode because app is not valid.
<info> nrf_bootloader_wdt: WDT is not enabled
<debug> app: in weak nrf_dfu_init_user
<debug> app: timer_stop (0x20000028)
<debug> app: timer_activate (0x20000028)
<info> app: Entering DFU mode.
<debug> app: Initializing transports (found: 1)
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init()
<debug> nrf_dfu_serial_uart: serial_dfu_transport_init() completed
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_validation: PB: Init packet data len: 64
<debug> app: Enter main loop

And nothing happens, app is not working, while performing same procedure once again, when I stop at at 0xa80, then I receive execute cmd response and app starts working...

<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
<debug> nrf_dfu_req_handler: Offset:155648, CRC:0x4D88F134
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]

At this point stopping at mbr's reset handler 0xa80, pressing continue/play button as suggested

<info> nrf_dfu_serial_uart: Allocated buffer 200005B8
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
<debug> nrf_dfu_req_handler: Whole firmware image received. Postvalidating.
<debug> nrf_dfu_validation: Hash verification. start address: 0x27000, size: 0x26000
<debug> nrf_dfu_validation: Invalidating old application in bank 0.
<debug> nrf_dfu_serial: Sending Response: [0x4, 0x1]
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, src=0x20000A44, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FE000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FE000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FE000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FE000, src=0x200006C4, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x000FE000, pending 0
<debug> nrf_dfu_req_handler: All flash operations have completed. DFU completed.
<debug> app: Shutting down transports (found: 1)
<debug> app: Resetting bootloader.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<debug> app: Valid App
<debug> app: Enter nrf_dfu_app_continue
<debug> app: No copy needed
<debug> app: Setting app as valid
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FF000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FF000, len=1 pages), queue usage: 0
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FF000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FF000, src=0x20000A44, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x000FF000, pending 0
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Writing settings...
<debug> nrf_dfu_settings: Erasing old settings at: 0x000FE000
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x000FE000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x000FE000, pending 0
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x000FE000, src=0x200006C4, len=896 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x000FE000, pending 0
<debug> app: Resetting bootloader.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> app: Inside main
<debug> app: In nrf_bootloader_init
<debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
<debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
<debug> nrf_dfu_settings: Using settings page.
<debug> nrf_dfu_settings: Copying forbidden parts from backup page.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Enter nrf_bootloader_fw_activate
<info> app: No firmware to activate.
<debug> app: App is valid
<warning> nrf_dfu_settings: No additional data erased
<info> nrf_dfu_settings: Backing up settings page to address 0xFE000.
<debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
<debug> app: Running nrf_bootloader_app_start with address: 0x00001000
<debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0

Any idea? In both cases same length and crc are calculated.

Thank you for additional inputs.

Best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Matej — Fri, 19 Apr 2024 06:23:15 GMT

Not completly sure (will perform detail test in afternoon), if I'm not wrong I have tried and it seems like reset occur and bootloader boots up normally like nothing happend an previous/old application is booted...

When I perform flash readout - the new image is stored at 0x4d000 and completely the same as was sent over, on 0x27000 is old application which boots up

I'm expecting at least a message like whole firmware image is received, but in this case nothing. Are there any differencies how last execute CMD is processed?

Any idea how to proceed?

BR,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Fri, 19 Apr 2024 05:59:02 GMT

[quote user="Matej"]In case that image is valid and sending algorithm is completly the same, I don't get a message that whole firmware is received and bootloader stops at 0xa80[/quote]

0xA80 is the address of the mbr's reset handler, and the program should not hang there unless you have this breakpoint enabled in SES:

Have you tried to see what happens if you continue execution by pressing the 'play' button in SES?

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Fri, 19 Apr 2024 04:50:30 GMT

True, there was an error of sending one 64 byte to much within 4k chunks.

I made a bit of rework and I'm able to transffer image, but at the end of transfer when I send out execute cmd I have a bit weird situation:

In case that image is not valid I receive a message that whole firmware image is received, but hash verfication failed - it seems ok, since hash is not matching
In case that image is valid and sending algorithm is completly the same, I don't get a message that whole firmware is received and bootloader stops at 0xa80

Would you be please so kind and check attached logs? Where is the reason that I don't get any response on execute command in case that image transfer is valid? I have also performed readout and images are completly the same and in both cases I see with logic analyzer that execute cmd (0x04, 0xc0) is sent out.

Thank you for your support!

Best regards,

Matej

devzone.nordicsemi.com/.../dfu_5F00_log_5F00_hangs.log

devzone.nordicsemi.com/.../dfu_5F00_log_5F00_hash.log

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Thu, 18 Apr 2024 12:45:40 GMT

Hi Matej,

The error below suggests that the bootloader is receiving a packet that is too large:

[quote user="Matej"]<error> nrf_dfu_req_handler: Write request too long[/quote]

There is also this one that indicates that it is receiving packets that are >64 bytes:

[quote user="Matej"]<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F040, src=0x2000063C, len=129 bytes), queue usage: 1[/quote]

Does your client verify that the reported CRC during DFU is correct?

BR,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Thu, 18 Apr 2024 05:06:43 GMT

Hi Vidar,

I was a bit to fast with reseting and didn't check for execute response; and then i noticed that there is hash error... now I have reworked quite some things... and when I'm sending 64 byte long chunks, now I'm getting an error that allocating buffer has failed.

Any idea? I'm attaching bootloader log:

<info> nrf_dfu_serial_uart: Allocated buffer 20000530
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004EFC0, src=0x2000063C, len=64 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0004EFC0, pending 0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<error> nrf_dfu_req_handler: Write request too long
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x3
<warning> nrf_dfu_serial: DFU request completed with result: 0x3
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_CRC_GET (data)
<debug> nrf_dfu_req_handler: Offset:8192, CRC:0x9C7914AB
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x3, 0x1]
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_EXECUTE (data)
<debug> nrf_dfu_serial: Sending Response: [0x4, 0x1]
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> app: timer_stop (0x20000028)
<debug> app: timer_activate (0x20000028)
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_SELECT (data)
<debug> nrf_dfu_req_handler: crc = 0x9C7914AB, offset = 0x2000, max_size = 0x1000
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x6, 0x1]
<info> nrf_dfu_serial_uart: Allocated buffer 20000638
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_CREATE (data)
<debug> nrf_dfu_flash: nrf_fstorage_erase(addr=0x0x0004F000, len=1 pages), queue usage: 1
<debug> nrf_dfu_flash: Flash erase success: addr=0x0004F000, pending 0
<debug> nrf_dfu_req_handler: Creating object with size: 4096. Offset: 0x00002000, CRC: 0x9C7914AB
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<debug> nrf_dfu_serial: Sending Response: [0x1, 0x1]
<error> nrf_dfu_serial_uart: Failed to allocate buffer
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F000, src=0x2000063C, len=64 bytes), queue usage: 1
<debug> nrf_dfu_flash: Flash write success: addr=0x0004F000, pending 0
<debug> nrf_dfu_req_handler: Request handling complete. Result: 0x1
<info> nrf_dfu_serial_uart: Allocated buffer 20001DF0
<debug> nrf_dfu_req_handler: Handle NRF_DFU_OP_OBJECT_WRITE (data)
<debug> nrf_dfu_flash: nrf_fstorage_write(addr=0x0004F040, src=0x2000063C, len=129 bytes), queue usage: 1
<error> app: Received a fault! id: 0x00004002, pc: 0x00000000, info: 0x2003FF48
<error> nrf_dfu_serial_uart: Failed to allocate buffer
<error> nrf_dfu_serial_uart: Failed to allocate buffer

Thank you in advance!

BR,
Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Wed, 10 Apr 2024 11:50:37 GMT

Hello Matej,

The new app should be activated automatically after the last Execute request. I recommend you enable logging over RTT from the target bootloader to see if there are any errors reported during the pre- or post-validation step.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Wed, 10 Apr 2024 03:22:36 GMT

Hello Vidar,

I have managed to transfer image and it boots up if I have flashed only bootloader and softdevice. If I have also application, then always old application boots up.

If I refer to picture above - I'm at the state in the middle column... Is there any command that needs to be sent over to actually switch/replace old application with the new one?

Thank you and best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Fri, 05 Apr 2024 07:46:56 GMT

Hello Matej,

The content of the update is transparent to the sender. It is the bootloader that know where to place the image in flash based on the update type specified in the transferred init command (the *.dat file). The DFU controller cannot instruct the DFU target to place the image at a specific address.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Thu, 04 Apr 2024 10:19:48 GMT

Hello Vidar,

This is the case why I was wondering for protocol documentation and request sequence...

As mentioned I'm implementing dfu flashing on external MCU via UART. Therefore I'm interested in packets description at least a list of min required requests.

I have checked about following commands; ping, get mtu, and set receipt notification and I think its everything clear...

Now I'm wondering of usage of select, create, write and execute... Could you please provide me a bit info how app/SD is selected, is there option to define also start address?

Thank you for support.

Best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Thu, 04 Apr 2024 06:28:26 GMT

Hello Matej,

The object_type should probably have been declared as a uint8_t to indicate that it's only 1 byte. As shown in the code snippet below, we extract the object type from the second byte of the request.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Wed, 03 Apr 2024 21:13:02 GMT

Hello Vidar,

thank you for your reply. Sorry for a bit of delay. Now I',m back and looking forward to understand communication protocol. Now I'm wondering about following request:

it seems that this is create request according to

but according to struct description two arguments of type of uint32_t are expected

but this somehow does not match with captured traffic (flashing blinky example via nrfutil) - or did I missed something?

Thank you for your reply.

Best regards,

Matej

RE: Bootloader DFU transport - transfer of init packet

Vidar Berg — Thu, 14 Mar 2024 13:52:50 GMT

Hi Matej,

The message sequence chart shows the required requests to perform an update. However, this doesn't mean the controller can't send other requests, such as a ping request, before starting the transfer.

[quote user="Matej"]

On "Get MTU" request 0x07, 0xC0, i get response:

0x60 (indicating response)
0x07 (get mtu rsp)
0x01, 0x83 (size)
0x00 status?
0xc0 (slip end)

[/quote]

0x1 is the response code and corresponds it to NRF_DFU_RES_CODE_SUCCESS. The MTU size is 0x0083 = 131 bytes.

Best regards,

Vidar

RE: Bootloader DFU transport - transfer of init packet

Matej — Thu, 14 Mar 2024 06:45:12 GMT

Vidar, thank you, for your response.

I see, there are listed different OpCodes, for several requests. Is there any list of requests order (collected at one place), that needs to be sent for successful update?

What is the timeout between request, before dfu is aborted?

On "Get MTU" request 0x07, 0xC0, i get response:

0x60 (indicating response)
0x07 (get mtu rsp)
0x01, 0x83 (size)
0x00 status?
0xc0 (slip end)

while on ping req i get response i get

0x60 (indicating response)
0x09 (ping request)
0x01 ping id
0x01 status?
0xc0 (slip end)

Now i'm wondering about bold status bytes? are those really status or something else? where can i find byte-to-byte overview?

Thank you in advance for additional support

Best regards,

Matej