BlueNRG-2: JLinkExe: Failed to download RAMCode!

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

    • 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 39 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.
      The following contact form can be used for this: segger.com/about-us/contact-us/

    • 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 9 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.
      The following contact form can be used for this: segger.com/about-us/contact-us/