[SOLVED] BlueNRG-2: JLinkExe: Failed to download RAMCode!

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] BlueNRG-2: JLinkExe: Failed to download RAMCode!

    Hi Segger,

    When using the BlueNRG2 with certain applications, the JLinkExe seems unable to reliably reflash the device.
    What I get is this:

    Cortex-M0 identified.
    Downloading file [build/blescan.hex]...

    ****** Error: Verification of RAMCode failed @ address 0x200000C0.
    Write: 0x599D5991 D10442A9
    Read: 0x01E80048 D10442A9
    Failed to prepare for programming.
    Failed to download RAMCode!
    Unspecified error -1


    After many tries, it eventually succeeds (sometimes after 2 or 3 times, sometimes after > 10 times)

    The code is very simple, and not putting the CPU in sleep or anything.
    It basically just sets up the MCU, and orders a BLE scan.

    I have attached the .HEX file containing the application, so you can try to reproduce the issue.

    I am using Linux + SEGGER J-Link Commander V6.30h (Compiled Mar 16 2018 18:04:43),
    although this issue has been there for many versions already.

    Any help is appreciated!

    Best regards,
    Maxime
    Files
    • blescan.hex.txt

      (324.86 kB, downloaded 78 times, last: )
  • Hello Maxime,

    Thank you for your inquiry.
    Such an issue is not known to us.
    For verification we used the latest J-Link software V6.32 and a STEVAL - IDB008V1 eval board and every program through the JLinkExe worked flawlessly.
    Could you provide a the full J-Link Commander output of a failed session?
    Are you using custom hardware or an eval board?

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/
  • Hi Nino,

    This is indeed on a custom board, using a BlueNRG-248.

    Here's the full output:


    % JLinkExe -device BLUENRG2 -if swd -speed 1000 -AutoConnect 1
    SEGGER J-Link Commander V6.32a (Compiled Apr 30 2018 15:46:56)
    DLL version V6.32a, compiled Apr 30 2018 15:46:51

    Connecting to J-Link via USB...O.K.
    Firmware: J-Link V10 compiled Apr 20 2018 16:47:09
    Hardware version: V10.10
    S/N: 50104725
    License(s): GDB
    VTref=1.896V
    Device "BLUENRG2" selected.


    Connecting to target via SWD
    Found SW-DP with ID 0x0BB11477
    Scanning AP map to find all available APs
    AP[1]: Stopped AP scan as end of AP map has been reached
    AP[0]: AHB-AP (IDR: 0x04770021)
    Iterating through AP map to find AHB-AP to use
    AP[0]: Core found
    AP[0]: AHB-AP ROM base: 0xF0000000
    CPUID register: 0x410CC200. Implementer code: 0x41 (ARM)
    Found Cortex-M0 r0p0, Little endian.
    FPUnit: 4 code (BP) slots and 0 literal slots
    CoreSight components:
    ROMTbl[0] @ F0000000
    ROMTbl[0][0]: D00FF000, CID: 00000000, PID: 00000000 ???
    Cortex-M0 identified.
    J-Link>loadfile blescan.hex
    Downloading file [blescan.hex]...

    ****** Error: Verification of RAMCode failed @ address 0x200000C0.
    Write: 0x599D5991 D10442A9
    Read: 0x01E80048 D10442A9
    Failed to prepare for programming.
    Failed to download RAMCode!
    Unspecified error -1
    J-Link>q
  • Hello,

    Thank you for providing additional information.
    Attached you can find the successful connect on our side when using the eval board.
    Also loading the example hex file you send us is working.
    The biggest difference we noticed is that your VTref voltage is relatively low.
    Are 1.8 V expected?
    On the eval board target voltage is at 3.3 V.
    On some devices a low voltage can lead to low power modes that disable debug connections or Flash programming.
    Flash programming requires much energy so make sure the power supply is stable throughout the whole process.
    Could you monitor the target device voltage with an oscilloscope during programming?
    Should you see a dip in the supply voltage then this is most likely the culprit for the failed programming.

    Best regards,
    Nino
    Images
    • Capture.PNG

      36.39 kB, 677×738, viewed 107 times
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    Alternatively our support ticketing system can be used as well: segger.com/ticket/