Hot!RN4871 the "brick" machine. Should I continue to develop it for production ???

Page: 12 > Showing page 1 of 2
Author
tssir
New Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2016/08/10 10:32:32
  • Location: 0
  • Status: offline
2017/05/15 05:06:42 (permalink)
0

RN4871 the "brick" machine. Should I continue to develop it for production ???

Hello,
First RN4871 works for a while. I manage to setup configuration and somes tests. After few days, it stop working. No radio and no serial response. Ok, maybe a mistake in configuration ...
Second works few hours. Bizarre ...
Third is "bricked" after very carefully use, and only one "$$$" sending. Now, led output blinking randomly (some time rapid blinking, some times off, some times on for ten minutes).
I think that the RN4871 die after receiving on RX. Because first one works well many days, without any communication to external CPU (solded and supplied on PCB, while developping other features). Problems comes with serial communications.
 
After some research, it seems that I am not the first to have this kinds of problems (this forum, for example). But the proposed solutions seems not "logical" or solid.
 
Has anyone ever used the RN4871 successfully in production ?
Because if it "brick" like that while developing, it is not reassuring for production !!!
 
#1

21 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 16125
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2017/05/15 06:25:24 (permalink)
    0
    Does it need its firmware updated?
    #2
    tssir
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2016/08/10 10:32:32
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2017/05/15 09:08:08 (permalink)
    0
    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.
    #3
    traversjames
    Starting Member
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/04/26 15:06:38
    • Location: Ireland
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2017/05/18 02:26:12 (permalink)
    0
    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.
    #4
    tssir
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2016/08/10 10:32:32
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2017/05/18 02:53:27 (permalink)
    0
    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.
    #5
    traversjames
    Starting Member
    • Total Posts : 21
    • Reward points : 0
    • Joined: 2017/04/26 15:06:38
    • Location: Ireland
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2017/05/18 04:57:42 (permalink)
    5 (1)
    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.
    #6
    boatbodger
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/03/13 15:37:45 (permalink)
    0
    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...
    #7
    RISC
    Super Member
    • Total Posts : 5240
    • Reward points : 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/03/13 17:01:47 (permalink)
    0
    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
     
    #8
    boatbodger
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/03/14 02:18:03 (permalink)
    0
    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?
    #9
    boatbodger
    New Member
    • Total Posts : 19
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/03/15 02:03:21 (permalink)
    0
    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.
     
    #10
    northeastman
    Senior Member
    • Total Posts : 123
    • Reward points : 0
    • Joined: 2009/11/07 05:49:38
    • Location: North East England
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/25 08:35:26 (permalink)
    4.5 (2)
    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 usb 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.
     

    Regards
    Northeastman
    #11
    tunelabguy
    Super Member
    • Total Posts : 1712
    • Reward points : 0
    • Joined: 2005/04/03 08:30:19
    • Location: Hopkins, MN USA
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/25 19:34:22 (permalink)
    3 (1)
    northeastman
    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 usb socket and circuitry onto our final design just for production programming the device with our UUID's and allow for software upgrades?

    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.
     

    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).

    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.
     

    Robert Scott
    Hopkins, MN
     
    #12
    northeastman
    Senior Member
    • Total Posts : 123
    • Reward points : 0
    • Joined: 2009/11/07 05:49:38
    • Location: North East England
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/25 23:42:52 (permalink)
    0
    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.

    Regards
    Northeastman
    #13
    qɥb
    Monolothic Member
    • Total Posts : 3295
    • Reward points : 0
    • Joined: 2017/09/09 05:07:30
    • Location: Jupiter
    • Status: online
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/25 23:53:34 (permalink)
    0
    northeastman
    ...
    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.
    ...

    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.
     

    This forum is mis-configured so it only works correctly if you access it via https protocol.
    The Microchip website links to it using http protocol. Will they ever catch on?
    PicForum "it just works"
    #14
    northeastman
    Senior Member
    • Total Posts : 123
    • Reward points : 0
    • Joined: 2009/11/07 05:49:38
    • Location: North East England
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/26 11:34:16 (permalink)
    0
    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.

    Regards
    Northeastman
    #15
    myZigbee
    Super Member
    • Total Posts : 237
    • Reward points : 0
    • Joined: 2006/11/17 08:34:52
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/26 16:33:55 (permalink)
    0
    "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 <cr> 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.
    #16
    tunelabguy
    Super Member
    • Total Posts : 1712
    • Reward points : 0
    • Joined: 2005/04/03 08:30:19
    • Location: Hopkins, MN USA
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/26 17:32:37 (permalink)
    4.5 (2)
    @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.

    Robert Scott
    Hopkins, MN
     
    #17
    northeastman
    Senior Member
    • Total Posts : 123
    • Reward points : 0
    • Joined: 2009/11/07 05:49:38
    • Location: North East England
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/27 08:06:24 (permalink)
    0
    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.

    Regards
    Northeastman
    #18
    myZigbee
    Super Member
    • Total Posts : 237
    • Reward points : 0
    • Joined: 2006/11/17 08:34:52
    • Location: 0
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/27 10:12:51 (permalink)
    0
    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.
    #19
    northeastman
    Senior Member
    • Total Posts : 123
    • Reward points : 0
    • Joined: 2009/11/07 05:49:38
    • Location: North East England
    • Status: offline
    Re: RN4871 the "brick" machine. Should I continue to develop it for production ??? 2018/06/27 11:40:44 (permalink)
    3 (1)
    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.

    Regards
    Northeastman
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2018 APG vNext Commercial Version 4.5