RN48 71停止工作

是否需要更新固件？



      以下为原文

    Does it need its firmware updated?

最后一个版本是2016年9月27日V1.18，发行说明没有显示出这种问题。有人说固件更新是解压模块（测试）的正确方法。但是没有人说如果它能解决这个问题。我不能检查版本，因为直接砖。这就是为什么我正在寻找一些严肃的经验与这个模块。我需要评估，如果我继续这个模块，或者如果它太坏。无论如何，它不是一个解决方案的生产，因为我不能假设更新每一个新的模块。



      以下为原文

    Last release is v1.18 from 27 september 2016, and release note shows nothing about this kind of problems. Someone says that firmware update is the right method to unbrick module (tested). But nobody says if it solve the problem. And i can not check version because immediate brick.
It is why i am looking for some serious experiences with this module. I need evaluate if i continue with this module, or if it is too bad.
 
Anyway it is not a solution for production, because i can't assume update of each new module.

以前我提到过用固件更新来解锁模块，但注意到它可能是我的（AB）使用该模块，导致它在一开始就变得无响应。由于我解决了所有问题与UART COMS和稳定电源电压，我已经使用相同的模块，可靠的几个星期没有问题。



      以下为原文

    I mentioned before about unbricking the module with a firmware update, but noted that it was probably my (ab)use of the module to cause it to become unresponsive in the first place.  Since I resolved all of the issues with UART comms and stable supply voltage I have been using the same module for weeks reliably with no issues.

谢谢你提供的信息。这是个好消息，我尝试了第四个模块。我在每条线路上使用220欧姆隔离（除了电源）。第一次测试：没有通信，只是提供。BT广告工作。LED闪烁。BTI注意到一个巨大的噪音在TX（3.5V至2.8V）。我设法添加一些小型冷凝器，不同的值，接近模块供应线。噪声略有下降。但是，对于微芯片CPU和IMU芯片（每个解耦冷凝器）都使用相同的调节器和电源线。他们保持完美的工作，但我将调查监管机构缺乏活力。第二个测试：P.BT广告作品的重置。LED闪烁。第三测试：发送$$并寻找快速响应。没有响应。没有LED闪烁。没有BT广告（通常在$$后）。TX线看起来很干净，现在。第四测试：复位引脚。没有效果。TX保持非常干净。没有LED闪烁，没有BT广告。结果与第三个模块相同：第一个$$后锁定。我想相信这个问题来自于我的安装或我的焊接。但四个模块…我将尝试一个SPBTLE模块在相同的配置。



      以下为原文

    Thank you for informations. It is good news.
 
I try a fourth module. I use 220 ohm isolation on each lines (except supply).
 
First test : no communication, just supply.
BT advertising works. Led blinks. But i notice a huge noise on TX (3.5v to 2.8v). I manage to add some small condensators, differents values, close to module supply line. The noise decreases slightly. But always abnormal.
Same regulator and supply line is used for a Microchip CPU and a IMU chip (with decoupling condensator each). They keep working perfectly.
But I will investigate about lack of dynamism of the regulator.
 
Second test : reset by pin.
BT advertising works. Led blinks.
 
Third test : send $$$ and looking for prompt response.
No response. No led blinking. No BT advertising (normal after a $$$). TX line seems very clean, now.
 
Fourth test : reset by pin.
No effect. TX keeps very clean. No led blinking, no BT advertising.
 
The result is same as the third module : locked after first $$$.
 
I would like to believe that the problem comes from my installation or my welds. But four modules ...
I will try a SPBTLE module in same configuration.

我对我自己的电路板有些担心，最后我把一个模块连接到一个3V电池（没有电源噪声），电源去耦电容，只有TX和RX连接到一个串行电缆。我用一个示波器确保RX的定时和数据是正确的，在发送任何其他字符之前等待TX的响应。当所有这些都是正确的和验证的模块工作良好-然后你可以回到原来的董事会和检查差异。我必须做很多修改我的代码，以确保所有的时间规格满足和收到的响应；例如，在上电和复位你需要等待100毫秒。在发送任何字符之前，确保%ReSudio%String完全转移。



      以下为原文

    I had some concerns about my own board and I ended up just wiring a module to a 3V battery (no supply noise) with a power decoupling capacitor and only TX and RX connected to a serial cable.  I made sure that the timing and data on RX were correct using an oscilloscope and waited for response from TX before sending any further characters.  When all of these were correct and verified the module worked fine - then you can go back to the original board and check for differences.
 
I had to do a lot of modifications to my code to make sure all timing specs were met and responses received; e.g. after power-up and reset you need to wait 100ms before sending any characters and make sure the %REBOOT% string is fully transferred.

我也一直在实验RN48模块。一个是因为我意外地让它的电源上升到5V。我觉得它很热，我不能责怪任何人。我又买了三个。第二个，我真的很小心。从它自己的3.3V稳压器运行它，通过电阻运行RX/TX线路，以确保它们不可能超过3.3V -用一个DMM验证。这一个响应一次$$ $命令，但没有出现在我的手机上，就是这样。砖砌的根本没有反应，甚至没有尝试重新闪光。我经历了一切，直到我是蓝色的脸，并得出结论，那里真的真的没有什么错误的条件，所以把第三个模块。它的工作完美。我不知道我敢不敢我的产品基础上这些东西。他们看起来非常非常有吸引力。我现在正在考虑自己买的第四个是不是好的。



      以下为原文

    I too have been experimenting with the RN4871 modules. 
One I bricked rather permanently by accidentally allowing its supply to rise to 5V.  It got very hot, and I can't blame anyone but myself for that.  I bought three more.
 
For the second, one I was being REALLY careful.  Ran it from its own 3.3V regulator, Ran the Rx/Tx lines via resistors to ensure they could not possibly go above 3.3V - verified with a DMM.
This one responded just once to the $$$ command, but did not show up on my phone.
That was it.  Bricked.  No response at all, not even to attempt to re-flash.
 
I went through everything till I was blue in the face, and concluded there really really really was nothing wrong with the conditions, so put in a third module.
 
It works perfectly.
 
I now don't know whether I dare base a product on these things.  They seem very very flakey.
 
I am now psyching up myself to see whether the fourth one I've bought is a good'un or not...

嗨，一定要更新RN878到V1.23.3的固件，这可能解决了这个问题：http://www. McCluts/wwws/En/rn861（下页的文档& gt；软件部分）。



      以下为原文

    Hi,
 
Make sure to update the firmware of the RN4871 to v1.28.3 which solves probably this issue :
http://www.microchip.com/wwwproducts/en/RN4871 (under the Documentation > software section at the bottom of the page)
Release notes
 
Regards
 

我尝试过，但是更新工具无法检测到BLE模块。我能够用相同的线束成功地更新“好”模块上的固件。如果有人感兴趣，我会很高兴地发布失败的单元进行检查。或者它可以使用U下的焊盘重新编程。唱JTAG还是等值？



      以下为原文

    I tried that, but the updating tool could not detect the BLE module.
I was able to successfully update the firmware on a 'good' module using the same harness.
I'd be happy to post the failed unit for examination if anybody is interested.
Or perhaps it could be re-programmed using the pads underneath using JTAG or equivalent?

在我的三个单元中：单元1：一次工作（我看到%ReBOOT %消息），然后永久地砌砖——即使在“反射”模式下，它的TXD线上也没有活动，并且在“操作模式”中没有RF可见，因此不能再闪动。单元2：开始工作。-然后我看到垃圾从TXD线出来，机智。偶尔断续重启%的消息-一个重新启动清除了15到45秒，然后它再次启动-然后它停止工作。-我可以在这一点上重新考虑这个问题，我再次考虑了我的测试线束。我已经焊接了“短”电线到模块连接它，因为我仍然在“面包板”阶段。这些电线大约有25毫米长，所以最近的功率解耦器在50mm往返行程中。我估计线圈的电感在40nH左右，提供大约4Pijjoule的存储能量。这真的够炸这个装置吗？虽然怀疑，我决定“丑陋”一个1uF芯片帽直接穿过电源引脚使用2.5mm长的线股。（在我的微焊接能力的禁锢阻止我发布图片）之后，第2单元似乎完美地工作在单元3中：我在做其他事情之前安装了1UF盖，并且它表现出完美的假设：这些设备有自杀倾向，除非有一个好B。它的电容非常接近其电源端子。



      以下为原文

    Of my three units:
Unit 1: Worked once (I saw the %REBOOT% message) and then permanently bricked - no activity on its TxD line even in "reflashing" mode, and no RF visible in "operating mode", therefore cannot re-flash.
Unit 2: Worked to start with. 
- Then I saw garbage coming out of the TxD line, with intermittent %REBOOT% messages occasionally
- A reboot cleared that for 15 to 45 seconds  then it started again
- Then it stopped working. 
- I *was* able to reflash this one
At this point, I considered my test harness again.  I had soldered "short" wires to the module to connect it as I'm still at 'breadboard' stage.  These wires are about 25mm long, so the nearest power decoupler was on a 50mm round trip.
I estimate the inductance of the loop at around 40nH, giving stored energy of about 4picojoules.
Is that really enough to fry the device?
Whilst sceptical, I decided to "ugly" a 1uF chip cap directly across the power pins using 2.5mm long wire strands.  (Embarassment at my microsoldering capabilities prevents me from posting a picture)
After that, Unit 2 appeared to work flawlessly
Unit 3: I fitted the 1uF cap before doing anything else, and it has behaved flawlessly
 
Tentative hypothesis: These devices have suicidal tendencies unless there's a good bit of capacitance very near their power terminals.
 

嗨，我想我会尝试和贡献一些线索，根据我们的经验与RN48设备。我们正在设计一个小的板，我们的客户希望在生产上安装Bluetooth或蓝牙。在开发过程中，我们很难得到RN861甚至与主机MCU（它是PIC18F26K80）通信。经过多次尝试，我们成功地获得了%ReBOOT %消息，但是该单元将不接受任何命令，只会重新启动。Microchip示意图显示了一个1UF帽在复位线，我们删除了这一点，因为我们正在使用PIC来控制复位线。然后，我们设法能够发送和接收CMD和GT模式，并设置芯片与一些定制UUID和我们的特点为BLE操作。我们假设1UF CAP可能仅在模块运行时需要，并且需要在上电时重置。我们的问题如下：是的，如果你处于开发模式，你可以升级软件，但是你到底应该如何将这个升级过程转化为一个生产？环境，当设备安装在板上，并可能在最终产品？我们必须设计一个微型USB插座和电路到我们的最终设计只是为了生产编程设备与我们的UUID的，并允许软件升级？没有成本是不可接受的！我们试图通过编写一个函数将UUID等加载到设备中，然后在PIC的EEPROM上写一个标志，表示已经完成了这个限制。所以下一次单位靴子它应该工作！这个软件程序运行正常，但显然没有执行任何“神奇”的软件升级。你可以通过设备进行远程CMD，如果你能让它通过蓝牙连接，这对于我们客户的生产SMD线来说是不可接受的，所以我们还没有走下这条路线。在开发了引导功能之后，一切都在工作，BLE通信和所有的，所以我们开始了WO。对我们的应用程序发送的命令信号进行解码。没有任何干预，这个装置决定砖块本身！一天晚上，我们离开工作，一切都在工作，第二天早上，在电源上，这个设备失灵了。没有闪烁的LED显示它正在传输，甚至没有一%重新启动%的消息到PIC，现在它将不接受任何命令。我们写了一些代码，把设备放入测试模式，（保持模式低，然后重置），LED点亮固态显示我们在测试模式，但同样没有命令被接受，并且没有任何反应从设备。得出结论，设备不工作，（Brand）是一个很好的术语。在使用这个设备花费了大量的时间和金钱之后，我们现在必须将它从我们的最终设计中移除，寻找另一种选择。RN861似乎是不可靠的，可能会导致客户返回我们的许多客户的产品，由于其间歇性故障。感谢阅读，我们希望这有助于其他人的设计选择。



      以下为原文

    Hi,
just thought I would try and contribute something to this thread based upon our experience with RN4871 devices.  We are designing a small board for which our client wants BLE or Bluetooth installed at production.
 
During development we had a lot of trouble getting the RN4871 to even communicate with the host MCU (which is a PIC18F26K80). After much trying, we managed to get the %REBOOT% message but the unit would not accept any commands and would only reboot. Microchip schematic shows a 1uF cap on the reset line we removed this as we are using the PIC to control the reset line. We then managed to be able to send and receive in CMD> mode and set the chip up with some custom UUID's and our characteristics for BLE operation. We assume that the 1uF cap is probably only needed if the module is run stand alone and needs to reset on power up.
 
Our issues appear to be as follows;
Yes you can upgrade the software, if you are in development mode, but how on earth are you supposed to translate this upgrade process to a production environment, when devices are installed on the board and possibly in the final product? Do we have to design a micro u*** socket and circuitry onto our final design just for production programming the device with our UUID's and allow for software upgrades? No the cost is not acceptable! We tried to work around this limitation by writing a function to load the UUID's etc, into the device and then write a flag to the PIC's eeprom to say that this had been done. So next time the unit boots it should just work! This software routine works OK, but obviously does not perform any "magical" software upgrade. You can do remote CMD with the device if only you can get it to connect across the Bluetoothlink, this is not acceptable for our client's production SMD line, so we have not gone down this route.
 
After developing the boot functions everything was working, BLE communications and all, so we started working on decoding the command signals sent by our app. Without any intervention the device decided to brick itself! We left work one evening with everything working and the next morning at power on the device was not functional. No flashing LED to show that it was transmitting and not even a %REBOOT% message to the PIC, now it will not accept any commands. We wrote some code to put the device into Test mode, (hold MODE low and then reset), and the led lights up solid to show we are in the test mode, but again no commands are accepted, and there is no response from the device at all. Conclude that the device is not working, ("bricked" is such a good term).
 
After spending a considerable amount of time and money with this device we must now remove it from our final design and look for an alternative. The RN4871 appears to be unreliable and will probably result in customers returning a lot of our customers products due to its intermittent failure. 
 
Thanks for reading and we hope this assists others with their design choice.
 

我不知道你是否要求能够通过主机PIC进行固件升级，或者在最后的板全部焊接之后？我不知道前者，但我可以告诉你我们后来做了什么。我们在测试板上提供了测试点，允许我们从一台台式机上的外部串行适配器进入RXD和TXD，并在电路中执行固件升级。这就带来了一些问题。1。该Pix0引脚需要接地闪存新固件。我们在板上提供了一个测试点。2。PIC的TXD线通常由PIC驱动，但是当闪烁新固件时，我们需要从外部串行适配器驱动这条线。我们不希望司机互相打斗，所以我们在PIC上编写了一个特殊的启动序列，在RXD和TXD上被动，允许外部串行适配器处于控制状态。在每个应用程序中，这都取决于您已经对PIC所拥有的输入。在我们的应用中，我们有一个按钮，通常做其他事情。我们在PIC中提供启动代码，检查该按钮是否在上电时按下了2秒，如果是的话，在串行端口上进行被动操作。RN878非常不情愿地看到任何新命令，直到之前的命令响应完全被接收为止。我们早就违反了这条规则，它偶尔“乱扔”一批RN48 71s。但即便如此，对固件进行反射总是使芯片死而复生。



      以下为原文

   
I don't know if you are asking to be able to do firmware upgrade though the host PIC, or just after the final board is all soldered?  I don't know about the former, but I can tell you how we did the later.
 
We provided test points on the board that allows us to tap into RxD and TxD from an external serial adapter on a desktop computer and perform the firmware upgrade totally in-circuit.  This presents several problems.
 
1. The P2_0 pin needs to be grounded to flash new firmware.  We provided a test point on the board for that.
2. The TxD line from the PIC is normally driven by the PIC, but when flashing new firmware we need to drive this line from the external serial adapter.  We don't want the drivers to fight each other, so we programmed a special start-up sequence on the PIC that went passive on RxD and TxD, allowing the external serial adapter to be in control.  How that is done in each application depends on what inputs you already have to the PIC.  In our application we had a pushbutton the normally does something else.  We provided start-up code in the PIC that checked if that pushbutton was pressed for 2 seconds on power up, and if so, go passive on the serial port.
 

The RN4871 is very picky about not wanting to see any new commands until the previous command response has been completely received.  We violated that rule early on and it did "brick" a number of RN4871s sporadically.  But even then, reflashing the firmware always brought the chip back from the dead.
 

Tunelabguy，感谢您的输入，您显然对我们自己也有类似的问题。我们在将产品焊接到电路板之后考虑了您的编程方法。我们查看了BM7XDealDealStudio中的代码，以适应我们的PIC。我们被一个事实，即一旦设备被烧毁，很难从PCB中移除而不损坏板，几乎总是破坏设备。您的命令关于命令被完全接收。有趣的是，显然是从经验中诞生的，而且可能不是从阅读数据表中获得的。如果设备在测试模式中有低级别的命令，不管其状态如何，都可以进行工厂复位。可悲的是，一旦设备被烧毁，没有这样的命令存在，软件闪烁可能是唯一的选择。在我们的情况下，开发的产品是一个低成本的专业市场的产品，并必须编程或升级软件，一旦生产板已组装和装箱是没有。没有附加成本的实用性。从客户那里获得高于正常的产品回报率的可能性，真的吓坏了我们。我们认为，这个设备应该适合于“箱外”，并且是可靠的。在我们看来，这些设备不符合这一标准。再次感谢您的输入，很高兴知道有人还在阅读这些论坛。



      以下为原文

    Tunelabguy,
Thanks for your input, you obviously had similar issues to ourselves.
 
We did consider your approach to programming after soldering the product to the board. We looked at the code in BM7xConfigurationLibrary with a view to adapting it to our PIC.
We were put off by the fact that once the devices are bricked they are difficult to remove from the PCB without damaging the board, nearly always destroy the device.
 
Your point about commands being fully received is interesting, and obviously born out of experience, and probably not from reading data sheets.
 
It would have been better if the device had a low level command in test mode to do a factory reset regardless of its state. Sadly, once the device is bricked, no such command exists and software flashing is probably the only alternative.
 
In our case the product being developed is a low cost product for a specialist market and having to program or upgrade software once production boards have been assembled and boxed is not practical without additional cost. The possibility of a higher than normal return rate of product from customers really scared us away from this device.
 
In our view, the device should be fit for purpose "out-of-the-box" and be reliable. In our view, these devices do not meet that criteria.
 
Again, many thanks for your input it is nice to know someone is still reading these forums.

注意，他没有用PIC编程。只是让PIC浮动USAT引脚和驱动他们从一个外部的PC做反射。



      以下为原文

   
Note, he's not programming it with the PIC. Just getting the PIC to float the USART pins and driving them from an external PC to do the reflash.
 

感谢您的帖子，我们确实意识到，正在调查使用车载PIC而不是外部PC的闪光灯。如果我们在PCB上有外部PC连接，我们当然可以通过禁用PIC的UART并使所有相关联的引脚输入来浮动PIC引脚，从而使其成为可能。高阻抗。这完全在我们的能力范围内，但是我们只是不准备花费宝贵的时间在BM7xDealDealStudio中通过Microchip代码进行拖拽，并重新编写代码以使它运行在我们的PIC18F26K80上。如果您查看了库中的代码，您可以注意到，无论谁编写THI。S，（在我们看来），有一些奇怪的方式使用宏来编码，定义宏，定义最终代码，这使得代码理解一个任务的一部分。因此，重新配置我们的PIC将是非常耗时的。在我们看来，无论如何，我们不应该纠正在一个显然有可靠性问题，并没有明显原因死亡的设备中的RN861设计问题！这是我们的经验，从论坛的阅读帖子中，其他人也有类似的经历。谢谢你的输入和兴趣。



      以下为原文

    qub
thanks for your post we did realise that and were investigating re-flashing using the on-board PIC instead of an external PC. 
 
If we had the external PC connections on the PCB we could of course float the PIC pins by disabling the PIC's USART and making all associated pins inputs thus making them hi-impedance.  This is entirely within our capabilities, but we are just not prepared to spend valuable time trawling thru the microchip code in the BM7xConfigurationLibrary and re-writing the code to make it run on our PIC18F26K80.
 
If you have looked at the code in the library, you may note, that whoever wrote this, (in our opinion), have some bizarre ways of coding using Macros, to define macros, to define final code, which makes understanding the code a bit of a task. So re-configuring for our PIC would be very time consuming.
 
In our opinion anyway we should not be correcting RN4871 design issues in a device that obviously has reliability issues and ends up dead for no apparent reason! This is our experience, and from reading posts in this forum others have similar experiences.
 
Thanks for your input and interest.

“你关于命令被完全接收的观点是有趣的，显然是从经验中诞生的，而且可能不是从阅读数据表中得到的。”下面的句子是从RN870/71用户指南中复制的：一旦在命令模式下，就可以发出有效的ASCII命令来控制或配置RNC070/ 71。所有命令以一个回车和LT；CR & GT结束，并且总是由RNC070/ 71响应。任何后续命令都不能发出，直到接收到先前命令的响应为止。



      以下为原文

    "Your point about commands being fully received is interesting, and obviously born out of experience, and probably not from reading data sheets."
 
Following sentences are copied from RN4870/71 User Guide:
 
Once in Command mode, valid ASCII commands can be issued to control or configure
the RN4870/71. All commands end with a carriage return and are always
responded to by the RN4870/71. Any subsequent command must not be issued until a
response is received for the previous command.

NASTASTMAN:我现在可以看到为什么重新配置PIC看起来让你胆怯了。长期以来，我一直是对第三方库的最小依赖的倡导者，因此，当我开发了与RN878对话的PIC18F1320代码时，我使用了CCS C编译器，但没有一个附带编译器的外围库。对我来说，学习一个库的特质似乎更难，更不可靠，更麻烦，因为我在PIC和特殊记录的特殊功能寄存器之间，而不是直接与这些寄存器对话。现在，如果我要开发一个USB接口或一个HTTP服务器，我肯定会依赖其他人开发的一个图书馆，因为这些东西是很难从头开始做的。但是串行COM我发现相当容易-即使有中断驱动的64字符FIFO的输入和输出。至于UART配置，我只需读取Microchip数据表，并直接编写ToCSTA、BUDCTL、TXSTA、PIE1等。我发现它非常满意地知道我的代码中到底发生了什么，特别是在时间关键的中断服务程序中，有时我需要对指令周期进行计数。我在C编程中得到所有好处，而不必比在汇编中编程得到的硬件更远。我不是受虐狂。我不会试图编写一个32位除法程序在组装自己。我确实让C编译器做了这些事情。但与外围寄存器相比，我更舒服地使用了那些寄存器的API。在重新配置串行端口的情况下，只需清除RCSTA的7位就可以禁用串行端口，并设置适当的TrISB位来生成Tx。D和RXD两个输入。



      以下为原文

    @Northeastman: I can see now why reconfiguring the PIC looked so daunting to you.  I have long been an advocate of minimal reliance on third-party libraries, so when I developed the PIC18F1320 code that talks to the RN4871, I used the CCS C-compiler but none of the peripheral library that comes with that compiler.  For me it seems harder and less reliable and more troublesome to learn the idiosyncrasies of a library that stands between me and the well-documented Special Function Registers on the PIC than to talk to those registers directly.  Now if I were going to develop a USB interface or a HTTP server, I would definitely rely on a library someone else developed, because those things are hard to do from scratch.  But serial comm I find quite easy - even with an interrupt driven 64-character FIFO on both input and output.  As for UART configuration, I simply read the Microchip datasheet and write directly to RCSTA, BAUDCTL, TXSTA, PIE1, etc.  I find it very satisfying knowing exactly what is going on in my code, especially in time-critical Interrupt Service Routines where I sometimes need to count instruction cycles.  I get all the benefit of programming in C without getting any further away from the hardware than I would get if programming in assembly.  I am not a masochist.  I will not try to write a 32-bit divide routine in assemble myself.  I do let the C compiler do those kinds of things. But I am much more comfortable talking to peripheral registers than to somebody's idea of an API for those registers.
 
In the case of reconfiguring the serial port for floating pins, all it takes is clearing bit 7 of RCSTA to disable the serial port and setting the appropriate bit of TRISB to make TxD and RxD both inputs.

嗨，MyZigbee，你是正确的，因为这个段落适用于ASCII命令发送到RN814MUS完成与CR’R’。但是，如果您将该单元输入测试模式，则来自BM70用户手册的命令生效。这些是基于十六进制的，然后用0xAA启动命令，并用校验和完成。这些通常与RN48 1一起工作，其核心与BM70相同。但一旦砖头没有命令被承认，他们是CMD和GT；或0xAA或其他任何东西。闪光灯可能是唯一的选择，（其他人已经报告过），但是我们没有时间去那条路线，而且如果产品可靠和正确地工作，就不需要。因此我们决定不使用这个装置。但谢谢你的回应。很高兴。Tunelabgy，我不能同意你的回应，作为一个前英特尔汇编级程序员，（甚至在Mac编译器之前），控制所有寄存器意味着你知道程序中发生了什么。调试肯定是容易的，然后你就没有人可以责怪，但你自己，没有阅读，（甚至理解）数据表。在最近的一段时间里，我们为客户完成了一个32位的项目。和谐是好的，当它工作，但只是尝试一个调试会话，找出和谐功能是什么，（或不到）！在我们看来，因为许多MC软件被编写来支持多个处理器，所以你发现宏，定义较低的宏定义更复杂的较低的宏，这使得理解代码非常困难，几乎不可能调试。在基于和谐的项目中，我们不得不求助于写一些低级的东西，否则项目永远不会发生。我知道和声有点偏离这个主题，但是你知道你的代码在低水平上做什么是很好的，也是今天的微控制器程序员必须做的学习点。再次感谢你的宝贵的输入，非常感谢。在一个更正常的速度和一个更好的设备，都不是MC之一。



      以下为原文

    Hi MyZigbee,
You are correct in that this paragraph applies to ASCII commands being sent to the RN4871 mus finish with CR 'r'. However, if you get the unit into Test mode then the commands from the BM70 user manual come into force. These are Hex based and are started with 0xaa then the command and finish with a checksum. These do normally work with the RN4871 as the core is the same as BM70. But once bricked no commands are acknowledged be they CMD> or 0xaa or anything else. Re-flashing is probably the only option, (so others have reported), but we don't have the time to go that route, and really shouldn't need to if the product was working reliably and correctly. Hence our decision NOT to use this device. But thanks for your response it is appreciated.
 
Hi tunelabguy,
I couldn't agree more with your response, and as an ex Intel assembly level programmer, (even in a time before compilers for micros), being in control of all registers meant that you knew what was happening in your program. Debugging is definitely easier and then you have no one to blame, but yourself, for not reading, (and even understanding) the data sheet.
 
In the recent past we had an excursion into Harmony for a 32 bit project we completed for a client. Harmony is fine when it works, but just try a debug session to find out what the Harmony functions are up to, (or not up to)! In our opinion, because a lot of MC software is being written to support more than one processor, you discover Macros, defining lower Macros defining even more knotty lower macros that makes understanding the code extremely hard and almost impossible to debug. In the Harmony based project we had to resort to writing some of the low level stuff ourselves otherwise the project would never have happened. I know Harmony is a Bit off this topics but your point about knowing what your code is doing at a low level is well made and a MUST DO learning point for today's micro-controller programmers.
 
Again thanks for your valuable input, much appreciated.
 
Having designed out the RN4871 we are now proceeding at a more normal pace with a much better device, all be it not an MC one.

NASTASMANIT是一个误解，你可以运行BM70二进制命令在测试模式的RN48 71.我不知道你从哪里得到的印象，你可以运行BM70命令在RN48 71-在测试模式下。我从未尝试过这条路线，到目前为止，Microchip的新固件修复了MAC地址损坏问题后，没有发现任何内存损坏。除非升级模块固件，否则实际应用程序不应在测试模式下运行。它应该只在APP模式下操作设备。也许这就是为什么你看到了“砖头”的设备。在测试模式下，您可能无意地损坏设备的闪存。



      以下为原文

    Northeastman
 
It is a misunderstanding from you that you could run BM70 binary commands on Test mode of RN4871. I don't know where did you get the impression that you could run BM70 commands on RN4871 under Test Mode. I never tried that route and so far haven't seen any memory corruption after Microchip's new firmware fixed the MAC address corruption problem. A real application should never run in test mode unless to upgrade the module firmware. It should only operate the device in App mode. Maybe that is why you saw the "brick" of the device. You may unintentionally corrupt the flash memory of the device in Test mode.

HI ZigBee，最初我们使用的是BM70，因此我们知道这些命令和访问HEX命令结构的方法。在对BM70的一些建议之后，我们切换到RN878，（如您可能知道的是BM70，但使用不同的软件）。对于我们的应用来说，这应该是更好的选择。只有在设备失败后，我们决定使用BM70 HEX命令尝试解锁它。在编写了一些自定义代码后，我们可以切换到BM70测试模式，这是用一个实心LED信号显示我们进入了该模式，因此该设备响应BM70“复位到测试模式”序列。我们无意在生产中使用这种模式。这是一个最后的尝试，试图把发展委员会从我们所看到的一个没有起源的失败中恢复过来。所有的帽子都是正确的，所有其他SMD设备都是根据数据表。我们只做了一个改动，就是从复位电路中去掉1UF盖，它在PIC的常规重置中引起了我们原来的NO %ReBOOT %的问题。事实上，这个项目需要的是单元“通电”并进入透明的UART模式。之后，由应用程序发送的命令。将被PIC解释为RN1478只在每个方向上传递短数据串。我们知道BLE的20字节限制，但这对于我们的特定应用来说是绰绰有余的。它甚至不是一个高数据传输应用程序，它对于我们正在开发的一些相当简单的定制硬件来说更是一个简单的控制系统。我们意识到我们需要使用CMD和GT命令加载我们的UUID和特性。我们已经说服了我们的客户，这可以在最终板上的第一个“接通电源”上实现，因此在生产中，软件将设置一个内部EEPROM标志来向程序发出信号，说明安装已经完成。这意味着我们不会继续在EENPRM存储器中对RN878（或PIC）进行连续写入，因此我们保留EEPROM写周期。在故障点，我们不工作任何与RN1471相关的代码。一天晚上，我们带着所有的东西离开了工作，第二天早上就来了，RN48 71无法工作。我们确信我们没有造成任何锁定。这个设备固有的缺乏可靠性导致我们切换到不同的解决方案。我们的客户只是不准备重新闪光这些设备故障后，即使这确实使设备恢复生命。客户的回报率太高，无论是价格还是声誉。感谢您的贡献，我们相信这会消除我们可能造成的任何误解。



      以下为原文

    Hi Zigbee,
Originally we were using a BM70, hence our knowledge of those commands and the way to access the hex command structure.
 
After taking some advice regarding BM70's we switched to the RN4871, (which as you probably know is a BM70 but with different software). This was supposed to be the better option for our application.
 
It was only after the device failed, that we decided to try and unlock it, using the BM70 hex commands. After writing some custom code we could switch into the BM70 test mode, this worked with a solid LED signal showing that we were into that mode, so the device was responding to the BM70 "reset to test mode" sequence.
 
We had no intention of using this mode in production. It was a last ditch attempt to recover the development board from what we saw as a failure with no origin. All caps are correct and all other SMD devices are as per the data sheet.  Only change we made was to remove the 1uF cap from the reset circuit which was causing our original issue of no %REBOOT% on a conventional reset by the PIC.
 
In fact all this project needs is for the unit to be "powered on" and to enter transparent UART mode. After that commands sent by an App. would be interpreted by the PIC with the RN4871 just passing short data strings in each direction. We are aware of the 20 byte limits for BLE, but this is more than enough for our particular application. It is not even a High data transfer application it's more of a simple control system for some rather simple custom hardware we are developing.
 
We did realise that we would need to load in our custom UUID's and characteristics using CMD> commands. We had persuaded our client that this could be achieved on the first "power on" of the final boards, so that in production, the software would set an internal eeprom flag to signal to the program that the setup had already been accomplished.  This would mean that we would not be doing continual writes to any eeprom memory either in the RN4871, (or in the PIC), so we preserved eeprom write cycles.
 
At the point of failure we not working on any code associated with the RN4871. We left work one evening with everything operating, came in the next morning and the RN4871 would not work. We are confident that we did nothing to cause the lock-up.
 
The inherent perceived lack of reliability of this device has caused us to switch to a different solution. Our client is just not prepared to re-flash these devices after a failure, even if that does bring the devices back to life. The return rates from customers would be too costly, both in price and reputation.
 
Thanks for your contribution, we trust this clears any misunderstandings we may have caused.