This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems with 2018 purchase of nRF6700 and nRF24LE1-F16Q24-DK from Mouser Australia - Advice on how nRF6310 Firmware issue was resolved 3743 > 7000

We recently purchased the nRF6700 and nRF24LE1-F16Q24-DK from Mouser Australia. The Getting Started Guide is completely misleading (totally out of date). e.g. No product keys are required to download the software. However, the RF6310 motherboards had old firmware (Rev 3743) so the bootloader fails in Nordic Studio. The Studio firmware update process also fails. After much trawling I found this method works (it's a combination of several old posts):

I have Studio 1.21.2.10  and DFU Rev 0.4.5  (downloaded Oct 2018).

The major issue is that the 6310 motherboards aren't recognised by DFU so the firmware update always fails.
I had to resort to using the Atmel FLIP program from...   https://www.microchip.com/developmenttools/ProductDetails/FLIP

This seems to be the only successful solution with the current hardware/firmware/software combination.

There are several steps - note this is an update to all the steps I found in the DevZone - which are out of date for the products I received.

1.  Power up 6310 motherboard by USB connection to a PC.
2. Short P18  (next to the majn processor). With P18 shorted, Short P14, pins 5,6 (next to the crystal). Remove shorts and m/b will re-enumerate.
3.  If in Windows, use Device Manager to see the enumeration... it will probably now be:  AT90USB128
4. Download and run FLIP (see link above).  Click: 'Device', 'Select' and select AT90USB1287.  Click 'Settings', 'Communication' to select USB and Open the port!
5. Press Ctrl+L to load:  'nRFgo Firmware_7000.hex'  file located in your Nordic Studio/hex folder.
6. Press RUN in FLIP.  The file should download immediately.
7. Power cycle the motherboard and it should now appear in Studio with Rev 7000 firmware.

Good luck! P.s.  I think it's inappropriate for Nordic/Mouser to be selling product which requires hours of trawling websites and trying various processes just to get them to run.
I would prefer if Nordic had an official post that clearly identified the issue and the solution... and kept it up to date !!

  • Thanks Runar... I figured that out (I was following the Getting Started Guide - which is completely out of date and shouldn't be shipped with the product.  I now have a different problem:  The rf6310 motherboard firmware is out of date (Rev 3743) so the bootloader fails. I followed an old post by Hakon to update with a cmd line version of DFU-programmer... but that didn't recognise the device... so I reset the board (as per Hakon again) so it now enumerates as:  AT90USB128. That doesn't help as the DFU doesn't recognise that either.  The other alternative seems to be Atmel FLIP method, which I haven't figured out yet.  Surely if this is a Studio "issue' (as it was described) that would have been fixed by now? I have Studio Rev 1.21.2.10 and DFU: 0.4.5.  Any help greatly appreciated... there must be an easy solution?  P.s. I suggest it is not appropriate for Nordic to be selling products which take days of investigation just to get them running?

  • Is there any way I can persuade you to use the nRF51- or nRF52-series?

    The nRF24L-series have not received an update for quite some years, and unless you are using the specific operating system it was built for at the time, there may be issues I suppose.

    Best regards,
    Kenneth

  • Hi Kenneth, thanks for your advice. I'll look into the 51/52 series but we are trying to avoid Bluetooth if possible. I think our application is more suited to plain vanilla 2.4Ghz RF - the requirements are modest:  12 byte packet to be transmitted every 10mS. Further, many of the packets would contain redundant data so we expect to aggressively power down the chip to save battery life.... hence, a main requirement is that we can power up and reconnect within 2-4mS.  I'm not hopeful that this will be possible in many environments when the IoT is more ubiquitous. I understand that plain vanilla RF is sharing the same bandwidth (2.4GHz), but believe it may be possible to achieve reconnection faster if we're not running a BLE protocol. I would appreciate any thoughts you or others have on that topic. Also, if anyone has contemporary experience with the nRF24 series (and any problems with the O/S) I'd love to hear abput that too.  Thanks again......... Peter    

Related