在DFU OTA时MAC地址被覆盖

嗨，也许这是FW V1.33的正常行为。在RN4020网页上，下载了V1.33更新：RN4020固件更新V1.10-1.33 BECA文档解释了一些随机MAC地址是根据操作规范生成的。



      以下为原文

    Hi,
Maybe this is a normal behaviour for fw v1.33. Some features ave been changed with regards to MAC address.
On the RN4020 webpage, download the v1.33 update : 
RN4020 Firmware Update v1.10-1.33BEC
A document explains that some random MAC addresses are generated depending on operation mode
Regards

感谢您的反应RISC，我们要求并行芯片支持，我们还在搜索。事实上，他们在测试的过程中并没有遇到这样的问题。当我们做了两次升级，改变了MAC地址时，我们遇到了蓝牙连接的问题：它失败了，然后我们重新连接设备，然后重新启动（按程序的愿望）。我们还检查了1.33固件二进制，有一种与新MAC地址的匹配：（i）从固件升级的第一百一十七个字符：FFFF1F660600回复：06066 F1FFFF，并根据4×4位交换，我们得到新的MAC地址。但是…为什么固件重写MAC地址存储区？*正如发行说明所做的那样，微芯片支持告诉我们一个“RN4020设备固件更新。PDF”，我们没有发现在网络Y.Br。



      以下为原文

    Thanks for your reactivity RISC, we asked in parallel to microchip support and we're still searching. Indeed, they didn't had such a problematic while testing by now. When we did the two upgrades that changed the mac address, we had a trouble with the bluetooth connection : it  failed , then we reconnected the devices and we started again (as the procedure's wishes).
 
Also we checked on the 1.33 firmware binary, there's a sort of match with the new mac address : (in hex) 0006661FFFFF
and from the 117th character of the firmware upgrade : FFFF1F660600 reverted : 006066F1FFFF and according to a 4 by 4 bit swap we get the new mac adress. But ... why do the firmware overwrites the mac address memory zone?
 
* as the release notes did, the microchip support told us about a "RN4020 Device Firmware Update.pdf" we didn't found on the web yet.
 
BR

我已经使用OTA方法从版本1.23到1.33更新了22个设备（21个成功），并且MAC地址在它们中没有改变。可能在更新过程中发生了一个问题；您使用硬件流控制吗？如果该设备在正常情况下运行在固件1.33上，则可以使用ANP命令；



      以下为原文

    I've update 22 devices (21 successfully) from version 1.23 to 1.33 using the OTA method, and the MAC address did not change on any of them. Perhaps an issue occurred during your update; were you using hardware flow control?

If the device is otherwise functioning normally and is on firmware 1.33, you can change the MAC Address back using the & command.
&,001EC03077E4

事实上，我们在哪里使用硬件流控制（作为SR命令中的设置位），但没有特定的板上连接。请注意，我们有相同的麻烦在PiT尾与UART连接（和观看），但只用于电源。你能告诉我们你的配置吗？你有没有投票反应（从RTS/CTS）到主机C？事实上，我们并没有按照我们的需要去尝试标准程序。我们的DFU必须以智能手机（Android和iOS）为中心（DFU发送器）和RN4020作为外围设备进行空中操作。而在标准程序中使用两个RN4020。我们告诉微芯片支持它，他们回答：



      以下为原文

    Indeed, we where using hardware flow control (as a set bit in sr command) but no particular on board connection for it. Note that we had the same trouble on the pictail with uart connected (and watched) but used for power supply only. Can you tell us about your configuration? did you had to poll for a reaction (from rts / cts) with the host µC?
 
Actually we did not try the standard procedure because of our needs. Our DFU has to be performed over the air with a smartphone (android and ios) as central (dfu sender) and a RN4020 as peripheral. Whereas two RN4020 are used in the standard procedure. We told microchip support about it and they replied :

BR

对于我的接收器模块（一个被编程），我把它连接到一个微控制器。微执行使用HW/SW唤醒线在RN4020上进行工厂复位，然后将其设置为通过启用自动广告、MLDP和OTA（SR，32008000）来编程，并保持CTS线低。此后，微集在更新过程的其余部分空闲。对于我的发送器模块，我有一个USB和LT；-＆GT；UART板直接连接到RN4020（CTS，RTS，TX，RX，地面和电源）。这是用于更新的RN4020。我设置SET特征命令来设置这个模块为中心，启用MLDP，UART流控制，并启用OTA（SR，92008000）。即使设置了位，您仍然可以与此设置进行通信，而不使用流量控制，但在实际发送编程文件时需要流量控制。但是如果你使用智能手机来执行OTA更新，这个信息是不必要的。如果你在OTA更新中使用的应用程序是在Android上可用的，我想尝试一下，看看是否有同样的问题出现在我的终端上。你是否能够使用ANP命令来进行手工设置？MAC地址？



      以下为原文

    For my receiver module (the one being programmed), I have it connected to a microcontroller. The micro performs a factory reset on the RN4020 using the HW/SW wake lines, then sets it up to be programmed by enabling Auto-advertise, MLDP, and OTA (SR,32008000) and holding the CTS line low. After this, the micro sets idle during the rest of the updating process.

For my sender module, I have a USB<->UART board tied directly to the RN4020 (CTS,RTS,TX, RX, ground and power). This is the RN4020 used for doing the update. I set the set features command to set up this module as Central, Enable MLDP, UART Flow Control, and Enable OTA (SR,92008000). You can still communicate with this setup without using flow control even though the bit is set, but flow control is required when actually sending the programming file. But this info isn't necessary if you are using a smartphone to perform the OTA update.

If the app you are using for the OTA update is available on Android, I'd like to try it out to see if the same issue occurs on my end. 

Were you able to make a workaround using the & command to manually set the MAC address?

事实上，我们实现了一个备份MAC地址来防止发行。然而，我们使用的应用程序是：HTTPS://GITHUBCOM/XODEADIMON/MLDPNETALLIOOOTAUDFUF，如果DFU正确，问题不会被追加。但是如果它出了问题，你就必须对你的RN4020充满关心。没有重新启动它，你将不得不继承另一个DFU发送。在第二DFU成功后，RN4020将重新启动自己，错误的MAC地址将出现。谢谢这些细节，你所说的“空闲”是什么意思？=设置引脚CTS自由，没有建立的张力？



      以下为原文

    Indeed, we implemented a backup MAC address to prevent the issue.
 
however, the app we used is there :
https://github.com/XenoDaimon/MLDPTerminal_OTA_DFU
the issue doesn't appends if the DFU goes right. But if it goes wrong, you will have to be care full with your RN4020. Without rebooting it you'll have to succeed an other DFU send. After the 2nd DFU succeed, the rn4020 will reboot itself and the wrong mac address will appear.
 
thank you for those details,what did you mean by "idle" ? = set the pin CTS free, with no established tension?

嗨，这个链接提供了许多文件：HTTPS://www. GoGoLe.Fr/Stand？Q= RN4020+设备+固件+更新。PDF和OF= RN4020+设备+固件+更新。PDF＆AQS＝Chro.69I57.1060J0J7＆SoSeCIDID＝Chrome and IE＝UTF-8，特别是在Microchip开发者帮助网站上：http://MicroChIPDeavics/COML:RN4020应用示例DFU UARTTTP: //MicroChIPDeals/COML:RN4020 APP-E德福



      以下为原文

    Hi,
This link gives many documents :
https://www.google.fr/search?q=RN4020+Device+Firmware+Update.pdf&oq=RN4020+Device+Firmware+Update.pdf&aqs=chrome..69i57.1060j0j7&sourceid=chrome&ie=UTF-8
 
Especially on the microchip developer help website :
http://microchipdeveloper.com/ble:rn4020-app-example-dfu-uart
http://microchipdeveloper.com/ble:rn4020-app-example-dfu-ota
Regards
 

在空闲状态下，它保持CTS线低，而忽略了UART上的任何数据。微也不再发送命令。



      以下为原文

    In its idle state, it holds the CTS line low and just ignores any data that comes over the UART. The micro also doesn't send anymore commands.

谢谢你，Withmore先生。



      以下为原文

    Thank you Mr Withmore.

从用户手册：SDS，和lt；文本& Gt；描述：这个命令设置DeVice信息服务中序列号特性的值。默认设备的MAC地址。示例12345678，示例



      以下为原文

    From the user manual:  SDS,
Description
This command sets the value of the serial number characteristics in the Device
Information Service.
Default
The MAC address of the device.
Example
SDS,12345678

在不可见的回复之后，线程可以被标记为读取



      以下为原文

    Post after invisible reply so thread can be marked as read

您好DAGNABITBOY，我没有成功地修改RN4020 MAC地址与SDS命令，我试过。我做了：SF，2R，1SDS，12345678（和12Char太）-检查广告MAC地址：KO-R，1 -检查广告MAC地址：Ko -和，123456789012 -检查广告MAC广告着装：OK——（123456789012）和一些没有成功的配置。谢谢，我们不会使用损坏的设备，在那些我们将改变RN4020模块，没有什么可以做。事实上，＆命令工作良好，但它是一个能源和问题深渊。谢谢你。



      以下为原文

    Hello dagnabitboy,
I didn't succeed to modify the RN4020 mac address with the sds command althought I tried.
I did :
sf,2
r,1
SDS,12345678 (and with 12char too)
--check of the advertising mac address : KO--
r,1
--check of the advertising mac address : KO--
&,123456789012
--check of the advertising mac address : OK-- (123456789012)
 
and some more configurations that didn't succeed too. thanks we won't use the broken devices, on those we'll change the RN4020 module, there's nothing else to be done.
in fact the & command works fine but it's an energy and issue abyss.
thank you all.
 
btcommon.eir_ad.entry.device_name