First NRF Project (Ebyte nRF52832) device seems to hang after programming



  • Hi All,

    I'm hoping some of you can help me out, I've trawled the internet for the past week and the 1700 posts in the NRF Action thread. I've managed to at least get my NRF to program (I think), but when I load sketches on I don't get any action.

    The setup:

    Ok, first thing I was unable to do was burn the bootloader or upload any sketches like the erase_all example. I ended up using Nordic's nrfjprog to unlock the chip via $ nrfjprog -f NRF52 --recover, but this requires the use of a JLink debugger with the JLink driver (not WinUSB).

    After doing that, success... have been able to upload sketches, and on @NeverDie 's board, the LED lights up. If I wipe the NRF again, LED is off.

    My test sketch is the Blink_Serial_Demo_v001 which was posted with the board schematics. It needed some modification, but it compiles and I believe is faithful to the pinouts for the breakout board.

    /*
     * This example sketch shows how you can manage the nRF5 pin mapping as part of your code.
     * You can use the method for any nRF51822 or nRF52832 board or module.
     * 
     * Most components, like UART, SPI, Wire Bus, of the nRF5 series chips don't
     * have a fixed pin mapping. There are some pins with restrictions like analog
     * inputs, NFC or pins near the radio module. Please refer the latest
     * documentation about pin restrictions at http://infocenter.nordicsemi.com 
     * 
     * To use the custom pin mapping you have to do following steps:
     * 
     * 1. Install "arduino-nrf5" like described at
     *    https://github.com/sandeepmistry/arduino-nRF5/
     * 2. Install the "My Sensors nRF5 Boards" with the board manager like
     *    explained at https://github.com/mysensors/ArduinoBoards
     * 3. Copy the files "MyNRF5Board.cpp" and "MyNRF5Board.h" from
     *    "MyNRF5Board" example into your sketch.
     * 4. Modify pin mappings in "MyNRF5Board.cpp" and "MyNRF5Board.h" to fit
     *    your requirements.
     * 5. Select "MyNRF5Board nrf52832" or "MyNRF5Board nrf52822" as your board.
     *    Choose the correct parameters and programmer in the Tools menu.
     */
    
    //Simple program to demonstrate that both the LED and Serial are working correctly on the breakout board:
    // https://www.openhardware.io/view/471/Ebyte-nRF52832-Small-Breakout-Board
    //Note: Compile and upload from Arduino IDE using "MyNRF5Board nRF52832" as the board.
    //
    // Many thanks to d00616 for this framework!
    
    //#define MY_GATEWAY_SERIAL
    #define MY_RADIO_NRF5_ESB
    #define MY_DEBUG
    #define MY_NODE_ID 254
    
    
    #include <nrf.h>
    #include <MySensors.h>
    
    void setup() {
      Serial.begin(115200);
      hwPinMode(LED_BUILTIN,OUTPUT_H0H1);
    }
    
    void presentation()
    {
      
    }
    
    void loop() {
      Serial.println("HIGH");
      digitalWrite(LED_BUILTIN,HIGH);
      delay(1000);
      Serial.println("LOW");
      digitalWrite(LED_BUILTIN,LOW);
      delay(1000);
    }
    
    /*
      If you don't use an nRF5 board, you can ignore this file.
    
      This file was part of the "My Sensors nRF5 Boards" board repository
      available at https://github.com/mysensors/ArduinoBoards If you have
      questions, please refer the documentation at
      https://github.com/mysensors/ArduinoHwNRF5 first.
    
      This file is compatible with ArduinoHwNRF5 >= 0.2.0
    
      This file allows you to change the pins of internal hardware, like the
      serial port, SPI bus or Wire bus.
    
      All pins referenced here are mapped via the "g_ADigitalPinMap" Array
      defined in "MyBoardNRF5.cpp" to pins of the MCU.
      
      As an example, if you have at the third position in "g_ADigitalPinMap" the
      12, then all ports referenced in Arduino with 2 are mapped to P0.12. If you
      don't change the "g_ADigitalPinMap" Array, the Arduino pins 0..31 are
      translated to P0.00..P0..31.
       
      ###########################################################################
     
      This file is compatible with ArduinoHwNRF5 > 0.1.0
      Copyright (c) 2014-2015 Arduino LLC.  All right reserved.
      Copyright (c) 2016 Sandeep Mistry. All right reserved.
      Copyright (c) 2017 Sensnology AB. All right reserved.
    
      This library is free software; you can redistribute it and/or
      modify it under the terms of the GNU Lesser General Public
      License as published by the Free Software Foundation; either
      version 2.1 of the License, or (at your option) any later version.
      This library is distributed in the hope that it will be useful,
      but WITHOUT ANY WARRANTY; without even the implied warranty of
      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      See the GNU Lesser General Public License for more details.
      You should have received a copy of the GNU Lesser General Public
      License along with this library; if not, write to the Free Software
      Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
    */
    
    #ifndef _MYBOARDNRF5_H_
    #define _MYBOARDNRF5_H_
    
    #ifdef __cplusplus
    extern "C"
    {
    #endif // __cplusplus
    
    // Number of pins defined in PinDescription array
    #define PINS_COUNT           (32u)
    #define NUM_DIGITAL_PINS     (32u)
    #define NUM_ANALOG_INPUTS    (8u)
    #define NUM_ANALOG_OUTPUTS   (8u)
    
    /* 
     *  LEDs
     *  
     *  This is optional
     *  
     *  With My Sensors, you can use
     *  hwPinMode() instead of pinMode()
     *  hwPinMode() allows to use advanced modes like OUTPUT_H0H1 to drive LEDs.
     *  https://github.com/mysensors/MySensors/blob/development/drivers/NRF5/nrf5_wiring_constants.h
     *
     */
    #define PIN_LED1                (11)
    //#define PIN_LED1                (8)
    // #define PIN_LED2                (25)
    // #define PIN_LED3                (26)
    // #define PIN_LED4                (27)
    // #define PIN_LED5                (12)
    // #define PIN_LED6                (14)
    // #define PIN_LED7                (15)
    // #define PIN_LED8                (16)
    // #define USER_LED             	 (PIN_LED2)
    // #define RED_LED                 (PIN_LED3)
    // #define GREEN_LED            	 (PIN_LED4)
    // #define BLUE_LED			           (PIN_LED1)
    // #define BLE_LED                 BLUE_LED
    #define LED_BUILTIN          PIN_LED1
    
    /* 
     *  Buttons
     *  
     *  This is optional
     */
    // #define PIN_BUTTON1             (3)
    // #define PIN_BUTTON2             (4)
    // #define PIN_BUTTON3             (5)
    // #define PIN_BUTTON4             (6)
    // #define PIN_BUTTON5             (7)
    // #define PIN_BUTTON6             (8)
    // #define PIN_BUTTON7             (9)
    // #define PIN_BUTTON8             (10)
    
    /* 
     * Analog ports
     *  
     * If you change g_APinDescription, replace PIN_AIN0 with
     * port numbers mapped by the g_APinDescription Array.
     * You can add PIN_AIN0 to the g_APinDescription Array if
     * you want provide analog ports MCU independed, you can add
     * PIN_AIN0..PIN_AIN7 to your custom g_APinDescription Array
     * defined in MyBoardNRF5.cpp
     */
    static const uint8_t A0  = ADC_A0;
    static const uint8_t A1  = ADC_A1;
    static const uint8_t A2  = ADC_A2;
    static const uint8_t A3  = ADC_A3;
    static const uint8_t A4  = ADC_A4;
    static const uint8_t A5  = ADC_A5;
    static const uint8_t A6  = ADC_A6;
    static const uint8_t A7  = ADC_A7;
    
    /*
     * Serial interfaces
     * 
     * RX and TX are required.
     * If you have no serial port, use unused pins
     * CTS and RTS are optional.
     */
    #define PIN_SERIAL_RX       (8)
    #define PIN_SERIAL_TX       (6)
    //#define PIN_SERIAL_RX       (12)
    //#define PIN_SERIAL_TX       (11)
    // #define PIN_SERIAL_CTS      (13)
    // #define PIN_SERIAL_RTS      (14)
    
    /*
     * SPI Interfaces
     * 
     * This is optional
     * 
     * If SPI is defined MISO, MOSI, SCK are required
     * SS is optional and can be used in your sketch.
     */
    #define SPI_INTERFACES_COUNT 1
    
    #define PIN_SPI_MISO         (2)
    #define PIN_SPI_MOSI         (3)
    #define PIN_SPI_SCK          (4)
    #define PIN_SPI_SS           (5)
    //#define PIN_SPI_MISO         (22)
    //#define PIN_SPI_MOSI         (23)
    //#define PIN_SPI_SCK          (24)
    //#define PIN_SPI_SS           (21)
    
    static const uint8_t SS   = PIN_SPI_SS;
    static const uint8_t MOSI = PIN_SPI_MOSI;
    static const uint8_t MISO = PIN_SPI_MISO;
    static const uint8_t SCK  = PIN_SPI_SCK;
    
    /*
     * Wire Interfaces
     *
     * This is optional
     */
    #define WIRE_INTERFACES_COUNT 2
    
    #define PIN_WIRE_SDA         (13u)
    #define PIN_WIRE_SCL         (14u)
    
    #define PIN_WIRE_SDA1        (15u)
    #define PIN_WIRE_SCL1        (16u)
    
    //#define WIRE_INTERFACES_COUNT 1
    
    //#define PIN_WIRE_SDA         (20u)
    //#define PIN_WIRE_SCL         (21u)
    
    
    static const uint8_t SDA = PIN_WIRE_SDA;
    static const uint8_t SCL = PIN_WIRE_SCL;
    
    #ifdef __cplusplus
    }
    #endif
    
    #endif
    

    When uploading the sketch, I get the following messages - I assume this is in some way working, as with this sketch loaded I get a permanently on LED. When the board is erased, the LED is off.

    Sketch uses 24796 bytes (4%) of program storage space. Maximum is 524288 bytes.
    Open On-Chip Debugger 0.10.0-dev-00254-g696fc0a (2016-04-10-10:13)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    debug_level: 0
    0
    adapter speed: 10000 kHz
    cortex_m reset_config sysresetreq
    nrf52.cpu: target state: halted
    target halted due to debug-request, current mode: Thread 
    xPSR: 0x01000000 pc: 0x00002290 msp: 0x20010000
    ** Programming Started **
    auto erase enabled
    wrote 28672 bytes from file C:\Users\Antony\AppData\Local\Temp\arduino_build_265035/Blink_Serial_Demo_v001.ino.hex in 4.123537s (6.790 KiB/s)
    ** Programming Finished **
    ** Verify Started **
    verified 25040 bytes in 0.064402s (379.695 KiB/s)
    ** Verified OK **
    ** Resetting Target **
    shutdown command invoked
    

    Unfortunately from this point, I have a board with an LED that should be flashing, but isn't and when connecting a FTDI to the board there's no serial output either. It seems to be 'hung'.

    I can only assume I've got something wrong somewhere, but after staring at it for a week now I'm so desperate for clues I'm swallowing my pride and asking for help. 🙂



  • Upload looks fine indeed,

    I'm not sure if they hang, I just think the pinout wasn't right.

    Whenever Pins are not working correctly I check the files again (to be sure), then close down the Arduino IDE. And open the sketch you want to upload. somehow it looks like the pinout isn't coming through correctly when a different version is also opened.


  • Hero Member

    @spanners said in First NRF Project (Ebyte nRF52832) device seems to hang after programming:

    Crystal Oscillator, Reset:Don't Enable

    A small thing, but I'd suggest setting RC oscillator and Reset:Enable

    Now to the matters at hand: since you're getting a solid LED light instead of a flashing one, and it's no longer lit if you bulk erase, I agree that it does sound like maybe your pin re-assignments aren't working. To test that theory, see if you are getting a voltage pulse on any of the other pins that would match the expected pulse rate of the LED. You can test for that using a multimeter.


  • Hero Member

    By the way, if you just wanted to simply test whether your module is working at all or not, you could upload this FORTH hex file to it and then see if you are able to communicate to the REPL prompt over the Tx and Rx lines: https://github.com/rabbithat/nRF52840-DK_easy
    For the purpose of this test, it doesn't matter that your board is an nRF52832.

    The advantage of this particular test is that the hex file is already published, and all you need to do is simply upload it. It won't blink your LED, but you should get working serial communications over pins P0.06 and p0.08. 🙂



  • @neverdie and @Omemanti thanks for taking the time to give me some ideas.

    I tried loading the FORTH hex file to two of the nrf modules using nrfjprog, all I got from the serial output though was a single line of square characters that kept repeating. Not the desired outcome, but at least it's consistent.

    More worrying is neither of the two modules are doing anything with the LED's unlike yesterday.

    Did some more testing with the Arduino IDE, using the RC Oscillator and Reset:Enable - same result, no serial, no LED's at all anymore but the upload seems successful.

    I will run some tests with the multimeter to see if any of the pins are showing the LED blink.



  • @spanners to give you some assurance about these modules, I programmed 15 units by now, eventually all were working at the end.


  • Hero Member

    @spanners It's a long-shot, but maybe your Jlink programmer is running very old firmware and needs updating? If it's genuine, you should be able to download a current update from the Segger website.

    If all else fails, try posting photos of your exact setup. Maybe someone with an eagle eye will spot something amiss.

    That said, it sounds like you're very close, and it's just some nit that's holding you back. In that case, just further reducing differences between your setup and the proven setups of others will, by definition, get you over the finish line.


  • Hero Member

    @spanners Come to think of it, the particular version of the arduino IDE that you're using might be what's screwing with you. I'm not even sure which ones are the goods ones anymore, and it's partly for that reason that I moved away from it.

    Meh, but probably not, since the FORTH hex that you uploaded didn't work. It's probably something else amiss.



  • @neverdie

    It's a new J-link but I did update it to the latest version when I unboxed it.

    Like you say - I must be close, but something is definitely wrong.

    For my next test I'll try connecting wires directly to a naked NRF module. I do have some NRF Prototype modules and some different modules other than the Ebytes. At least if they all give me the same result I know the problem has got to be at the PC/Programmer end.

    I do also have an ST-Link V2 which I may as well have a try with.


 

380
Online

8.0k
Users

8.8k
Topics

94.3k
Posts