找回密码
 立即注册

微信扫码登录

查看: 350|回复: 17

Device OTA upgrade

[复制链接]

10

主题

18

回帖

158

积分

注册会员

积分
158
发表于 2024-10-31 05:25:38 | 显示全部楼层 |阅读模式
本帖最后由 wes58 于 2024-10-31 06:06 编辑

I use ZigBee BLE concurrent SDK on the Gateway. I can comumicate/connect to the gateway with my phone via BLE or via UART from the ESP32.
How can I upgrade any device firmware from the Gateway via OTA?
Is there eny example available?

I have noticed that ZGC_TOOL has the tab for OTA. And there is another tab called HCI_OTA - which has an option to load the image. When I connect to the gateway from ZGC_TOOL, can I upgrade any device via OTA? How to do it?


zgcota.png
hciota.png

27

主题

121

回帖

447

积分

版主

积分
447
发表于 2024-10-31 18:44:26 | 显示全部楼层
Hi,
Please refer to sections 2.3 and 6.4. (https://wiki.telink-semi.cn/doc/ ... eloper%20Manual.pdf)
After importing the firmware of the device to be upgraded into GW, wait for the remote device to actively query and obtain it.
Of course, you can also directly click on "image notify" to notify the remote device to query immediately.

10

主题

18

回帖

158

积分

注册会员

积分
158
 楼主| 发表于 2024-11-1 13:27:57 | 显示全部楼层
TL_YB 发表于 2024-10-31 18:44
Hi,
Please refer to sections 2.3 and 6.4. (https://wiki.telink-semi.cn/doc/an/AN-19052900-E_Telink%2 ...

Hi,
I have read section 6.4 of the manual, but I have still one more question before I start testing it:
#1. I download the required OTA file using ZGC_TOOL and HCI_OTA tab into the OTA-Image area in the Flash of the OTA server (gateway)..
#2. I select device address and EP and click "Image Notify" in OTA tab in ZGZ_TOOL
- Do I have to do anything in the Gateway? Or does the Gateway transfer the firmware when it is ready?
- If I don't do step #2 what do I have to do in the gateway to start transfer? You wrote "wait for the remote device to actively query and obtain it". So what does it mean "and obtain it" - is there something I have to do?
That's what is not clear to my about this process of the firmware transfer from Gateway to the device
There is the following in the manual for the server:
After the OTA server invokes the ota_init function, it will automatically load the information of the OTA image.

And for the Client/device the following:
After invoking the ota_init function, the OTA Client will automatically reload the last OTA progress information.
If joining in a network successfully, it will start the OTA request after the set seconds.


And that is all information in the manual.
What are the messages in section 8.7 8.7 HCI serial port upgrade command for?
Are they the messages send from ZGC_TOOL to the gateway?

10

主题

18

回帖

158

积分

注册会员

积分
158
 楼主| 发表于 2024-11-2 09:50:53 | 显示全部楼层
本帖最后由 wes58 于 2024-11-2 15:10 编辑

I have decided to do some tests. I made a new gateway and one router device.
I used ZGC_TOOL HCI_OTA tab. I have tried a couple of times but it gets to 15%, 22% etc. and it fails.
Here are the last messages from the csv log file.
There are messages with response: ZBHCI_MSG_STATUS_BAD_MSG
And in the end: ZBHCI_OTA_GET_BLOCK_TIMEOUT
You can see that message with file_offset 0x9948 is sent couple of times. Why?


24-11-02 12:02:24:325894
55 02 11 00 2e c1 00 00 00 99 20 28 09 fa e1 41 ae 49 eb 49 1b f2 33 03 1a 00 22 42 1b fa 63 42 a0 42 e1 42 22 43 63 43 e8 48 e0 44 fd 97 d7 99 00 a8 51 c1 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9920 block_len:0x28

24-11-02 12:02:24:797887
55 80 00 00 04 97 02 11 00 00 aa
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_SUCCESS
"        msgtype:0x211 status:0x0(ZBHCI_MSG_STATUS_SUCCESS)"

24-11-02 12:02:24:799888
55 82 11 00 05 6f 00 00 99 48 28 aa
ZBHCI_CMD_OTA_BLOCK_REQUEST
file_offset:0x9948 block_len:0x28

24-11-02 12:02:24:801891
55 02 11 00 2e a8 00 00 00 99 48 28 a0 4c a3 48 e1 48 09 f2 19 03 23 49 62 49 12 f2 1a 03 fd 97 42 9a 00 a8 58 c0 2a 49 6b 49 1b f2 13 03 a3 43 1b fa e3 43 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9948 block_len:0x28

24-11-02 12:02:24:802887
55 82 11 00 05 6f 00 00 99 48 28 aa
ZBHCI_CMD_OTA_BLOCK_REQUEST
file_offset:0x9948 block_len:0x28

24-11-02 12:02:24:804886
55 02 11 00 2e a8 00 00 00 99 48 28 a0 4c a3 48 e1 48 09 f2 19 03 23 49 62 49 12 f2 1a 03 fd 97 42 9a 00 a8 58 c0 2a 49 6b 49 1b f2 13 03 a3 43 1b fa e3 43 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9948 block_len:0x28

24-11-02 12:02:25:283204
55 80 00 00 04 97 02 11 00 00 aa
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_SUCCESS
"        msgtype:0x211 status:0x0(ZBHCI_MSG_STATUS_SUCCESS)"

24-11-02 12:02:25:776089
55 80 00 00 04 74 02 11 e3 00 aa
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_BAD_MSG
"        msgtype:0x211 status:0xe3(ZBHCI_MSG_STATUS_BAD_MSG)"

24-11-02 12:02:25:778092
55 82 11 00 05 6f 00 00 99 48 28 aa
ZBHCI_CMD_OTA_BLOCK_REQUEST
file_offset:0x9948 block_len:0x28

24-11-02 12:02:25:780089
55 02 11 00 2e a8 00 00 00 99 48 28 a0 4c a3 48 e1 48 09 f2 19 03 23 49 62 49 12 f2 1a 03 fd 97 42 9a 00 a8 58 c0 2a 49 6b 49 1b f2 13 03 a3 43 1b fa e3 43 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9948 block_len:0x28

24-11-02 12:02:25:782087
55 82 11 00 05 6f 00 00 99 48 28 aa
ZBHCI_CMD_OTA_BLOCK_REQUEST
file_offset:0x9948 block_len:0x28

24-11-02 12:02:25:784087
55 02 11 00 2e a8 00 00 00 99 48 28 a0 4c a3 48 e1 48 09 f2 19 03 23 49 62 49 12 f2 1a 03 fd 97 42 9a 00 a8 58 c0 2a 49 6b 49 1b f2 13 03 a3 43 1b fa e3 43 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9948 block_len:0x28

24-11-02 12:02:26:313212
55 80 00 00 04 74 02 11 e3 00 aa
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_BAD_MSG
"        msgtype:0x211 status:0xe3(ZBHCI_MSG_STATUS_BAD_MSG)"

24-11-02 12:02:26:314213
55 82 11 00 05 6f 00 00 99 48 28 aa
ZBHCI_CMD_OTA_BLOCK_REQUEST
file_offset:0x9948 block_len:0x28

24-11-02 12:02:26:316213
55 02 11 00 2e a8 00 00 00 99 48 28 a0 4c a3 48 e1 48 09 f2 19 03 23 49 62 49 12 f2 1a 03 fd 97 42 9a 00 a8 58 c0 2a 49 6b 49 1b f2 13 03 a3 43 1b fa e3 43 aa
ZBHCI_CMD_OTA_BLOCK_RESPONSE
status: 0x0(ZBHCI_OTA_SUCCESS) send_offset:0x9948 block_len:0x28

24-11-02 12:02:26:833203
55 82 12 00 09 18 00 02 a1 f2 00 00 99 48 01 aa
ZBHCI_CMD_OTA_END_STATUS
ZBHCI_OTA_GET_BLOCK_TIMEOUT
total_size:0x2a1f2 file_offset:0x9948 status:ZBHCI_OTA_GET_BLOCK_TIMEOUT

24-11-02 12:02:27:329207
55 80 00 00 04 97 02 11 00 00 aa
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_SUCCESS
"        msgtype:0x211 status:0x0(ZBHCI_MSG_STATUS_SUCCESS)"

I wasted half a day and with no luck

27

主题

121

回帖

447

积分

版主

积分
447
发表于 2024-11-4 14:38:58 | 显示全部楼层
What is your SDK version and ZGC version?

10

主题

18

回帖

158

积分

注册会员

积分
158
 楼主| 发表于 2024-11-4 14:54:26 | 显示全部楼层
TL_YB 发表于 2024-11-4 14:38
What is your SDK version and ZGC version?

ZGC version is 1.3 and SDK is version 3.7.1.0. I was using the Sample gateway example from this SDK without any modification. The chip is TLSR8258.
I have also tried one of the previous versions on the SDK. And the same thing happened

I have attached the whole capture file so you can see that towards the end of the capture "BAD MESSAGE" occured coupled of times then it contiunued with the next block and then it happened again and finally it stopped.
If you have any suggestion what I could add to the code to see what happens when this occurs please let me know. You could probably do the test yourself and see if it works for you.

all_packets.zip

647.95 KB, 下载次数: 1

27

主题

121

回帖

447

积分

版主

积分
447
发表于 2024-11-4 15:57:18 | 显示全部楼层
Hi,

I tried the HCI OTA function with sampleGW(ZBHCI_UART set to 1) and sampleLight in V3.7.1.0, and there were no abnormalities during uploading.

微信截图_20241104154948.png

From the log you provided, it appears that the response data received by GW requesting UART data was abnormal, causing the request to time out.


10

主题

18

回帖

158

积分

注册会员

积分
158
 楼主| 发表于 2024-11-5 05:58:40 | 显示全部楼层
本帖最后由 wes58 于 2024-11-5 09:22 编辑

Hi,
I have tried five times before and it didn't work.
Toady I decided to use another module. I have flashed it with the gateway firmware and tried ZGC HCI_OTA 4 times. And it failed all the time. So it wasn't bad board. I have tried different USB converters as well.
I put some code in hci_uart.c to see what is happening when ZBHCI_MSG_STATUS_BAD_MSG is set.

Here is uartRxBuf
Good message before  ZBHCI_MSG_STATUS_BAD_MSG received:
[11:38:12]:
128  bytes have finished!     

042560:  35 00 00 00 55 02 11 00 2e d5 00 00 00 ae 88 28
042570:  32 c0 01 bd 2d f6 2d fe 01 39 6d e8 2d f6 2d fe
042580:  01 bb 43 0a 92 58 55 85 1e a2 8f 85 00 a0 34 85
042590:  01 38 00 a8 ab c0 00 a1 aa 00 00 00 00 00 00 00
0425a0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0425b0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0425c0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0425d0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Total Time: 24 ms     

Status set to  ZBHCI_MSG_STATUS_BAD_MSG
[11:38:14]:
128  bytes have finished!     

0425e0:  6a 00 00 00 55 02 11 00 2e 87 00 00 00 ae b0 28
0425f0:  3b ec 2f ec 0d ec 99 06 06 78 ff a1 10 a2 05 90
042600:  d4 9b ec e9 44 04 06 78 21 ec 10 a2 05 90 eb 9b
042610:  3b 08 06 79 22 ec 1d 90 aa 55 02 11 00 2e 87 00
042620:  00 00 ae b0 28 3b ec 2f ec 0d ec 99 06 06 78 ff
042630:  a1 10 a2 05 90 d4 9b ec e9 44 04 06 78 21 ec 10
042640:  a2 05 90 eb 9b 3b 08 06 79 22 ec 1d 90 aa 00 00
042650:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Total Time: 23 ms     

[11:38:16]:

0426e0:  2e 35 35 a9 2e 35 6a 00
Total Time: 20 ms     

The values in 8 bytes data mean:
for Good Message:

pktLen = 0x2e
pktLen + ZBHCI_MSG_HDR_LEN = 0x35
rxData->dataLen = 0x35

total BAD_MSG count = 0xa9

for "BAD_MSG"
pktLen = 0x2e
pktLen + ZBHCI_MSG_HDR_LEN = 0x35
rxData->dataLen = 0x6A -> that's why ZBHCI_MSG_STATUS_BAD_MSG is generated. There are two packets in the rx buffer.

I have attached part of the log when the first "BAD_MSG" happened - I don't know if it helps.


packets1.zip

4.59 KB, 下载次数: 0

27

主题

121

回帖

447

积分

版主

积分
447
发表于 2024-11-5 19:21:47 | 显示全部楼层
From the .scv file you provided, it seems that your environment frequently experiences serial port congestion, resulting in many request timeouts. Ultimately, it was due to reaching the maximum retransmission request count of HCI_OTA_BLOCK_REQUEST_RETRY_CNT_MAX = 5 times and exiting the process. You can adjust the HCI_OTA_BLOCK_REQUEST_RETRY_CNT_MAX and try it out.
In addition, the reason for ZBHCI_MSG_STATUS_BAD_MSG is that there are two packets in the DMA buffer at the same time, so it is considered that the length is abnormal. We will handle this with fault tolerance in the future.

10

主题

18

回帖

158

积分

注册会员

积分
158
 楼主| 发表于 2024-11-6 05:33:19 | 显示全部楼层
本帖最后由 wes58 于 2024-11-6 10:28 编辑
TL_YB 发表于 2024-11-5 19:21
From the .scv file you provided, it seems that your environment frequently experiences serial port c ...

Hi,
Thanks for your help so far.
I don't think that there is any serial port congestion. You can see that there aren't any messages except one send to the gateway and 2 send back to ZGC. And as I said, there is only gateway and one device - that doesn't send any reports. What if you had 20 devices sending reports all the time?
The reason that there are 2 packets in the rx buffer is because gateway didn't receive/process the first packet - didn't send ZBHCI_CMD_ACKNOWLEDGE. And because of that, g_hciOtaTimer time was never cancelled and another ZBHCI_CMD_OTA_BLOCK_REQUEST was made.
I have noticed that sometimes the same packet (file offset) is sent 3 to 5 times.

ZBHCI_CMD_OTA_BLOCK_REQUEST
ZBHCI_CMD_OTA_BLOCK_RESPONSE
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_CMD_OTA_BLOCK_REQUEST
ZBHCI_CMD_OTA_BLOCK_RESPONSE
ZBHCI_CMD_OTA_BLOCK_REQUEST
ZBHCI_CMD_OTA_BLOCK_RESPONSE
ZBHCI_CMD_ACKNOWLEDGE
ZBHCI_MSG_STATUS_BAD_MSG

Anyway, I can't fix it. And the only reason I tried ZGC_TOOL was because I needed to know what messages are sent and what responses are received during OTA process.
I can't use ZGC_TOOL with my main gateway, because I have uart connected to ESP32 which communicates with the gateway.

That's why I need to write my own code to do all this. And becase I am using ZigBee BLE concurrent SDK I will most likely do it via ZBHCI_BLE.
Since, the part that I tried with ZGC_TOOL is only part of the OTA process - transferring firmware to the gateway - I assume that next part will be to  select which device OTA upgrade will be sent to - via "Image Notify" message - Am I correct?
And then would I have to do HCI_OTA again with ticked "Localbinfile"?
I don't know and I can't test it.

Would you have (or could you make) a complete packet log for the whole OTA process? That would help me a lot.

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Telink forum ( 沪ICP备17008231号-1 )

GMT+8, 2024-11-24 05:59 , Processed in 0.092557 second(s), 21 queries .

Powered by Telink 隐私政策

泰凌微电子版权所有 © 。保留所有权利。 2024

快速回复 返回顶部 返回列表