NRF52840 Donlge - JLink Programming

[jibba]

Hi

I have a coupe of dongles working on a project. While validating the board, i notice a strange behavior:

I have the dongles in factory reset (MBR at start, the Bootloader at the end of flash), and i took a backup of this so i can restore dongles anytime.

So what i have now is a blinky program, based on MbedOS. There i modified the linker script so Flash_Start = 0x1000 and Ram_Start=0x20000008 (copied over from the OT-CLI example from the dongle).

So when i now go ahead and program my blinky app (hex) with the NrfConnect-Programmer, it works just fine. Blinky works, or if reset is pressed, i go into DFU bootloader mode.
If i do the same but program the blinky app directly with JFlash from the Segger tools, nothing works.

So i went ahead and read both chips and compared them.

See both files here for a text compare (https://we.tl/t-SqAry7eaAh)

Why is somehow my blinky app (after 0x1000 in flash) looking different? do you guys somewhat do more than just flash a hex file during nrfconnect-programming?
i use this method a lot any other Cortex-M chip with more than 1 binary in its flash storage, i know what im doing. so right now im lost with the nordic chips, which somewhat behalve strangely.

Please help me out here, with a detailed explaination.

thank you

[jibba]

Ok. Here is the hexfile i flashed (https://we.tl/t-VuXnDaqxy8)

#include "mbed.h"

int main()
{
    DigitalOut led1(P0_6,  1);
    DigitalOut led2(P0_8,  1);
    DigitalOut led3(P1_9,  1);
    DigitalOut led4(P0_12, 1);

    while (true)
    {
        led1.write(0);
        ThisThread::sleep_for(10);
        led1.write(1);
        ThisThread::sleep_for(10);

        led2.write(0);
        ThisThread::sleep_for(10);
        led2.write(1);
        ThisThread::sleep_for(10);

        led3.write(0);
        ThisThread::sleep_for(10);
        led3.write(1);
        ThisThread::sleep_for(10);

        led4.write(0);
        ThisThread::sleep_for(10);
        led4.write(1);
        ThisThread::sleep_for(10);
    }
}

#define MBED_APP_START 0x1000
#define MBED_APP_SIZE 0xDB000
#define MBED_RAM_START 0x20000008
#define MBED_RAM_SIZE 0x3FFF8
#define MBED_BOOT_STACK_SIZE 0x800
#define MBED_RAM0_START MBED_RAM_START
#define MBED_RAM0_SIZE  0x100

#define MBED_CRASH_REPORT_RAM_START (MBED_RAM0_START + MBED_RAM0_SIZE)
#define MBED_CRASH_REPORT_RAM_SIZE  0x100

#define MBED_RAM1_START (MBED_CRASH_REPORT_RAM_START + MBED_CRASH_REPORT_RAM_SIZE)
#define MBED_RAM1_SIZE  (MBED_RAM_SIZE - (MBED_RAM0_SIZE + MBED_CRASH_REPORT_RAM_SIZE))

MEMORY
{
  FLASH (rx)     : ORIGIN = MBED_APP_START, LENGTH = MBED_APP_SIZE
  RAM_NVIC (rwx) : ORIGIN = MBED_RAM0_START, LENGTH = MBED_RAM0_SIZE
  RAM_CRASH_DATA (rwx) : ORIGIN = MBED_CRASH_REPORT_RAM_START, LENGTH = MBED_CRASH_REPORT_RAM_SIZE
  RAM (rwx)      : ORIGIN = MBED_RAM1_START, LENGTH = MBED_RAM1_SIZE
}

[jibba]

Hi Jorgen

Is this ticket still in process or do you need more information ?

Thank you

[Jørgen Holmefjord]

Hi,

Sorry for the slow response. I compared the hex-files to the dummy.hex file. It looks like the eclipse read-back is identical in the relevant areas, while the nrfconnect readback has a lot of single bits set in addition in most lines. This is not what I see when I readback the flash of a nRF52840 device after writing a hex-file with nRF Connect Programmer application, it is reading back the same hex-file as I programmed.

Did you test this on the same dongle, or on two different dongles? It sounds strange that the one programmed with nRF Connect is working, while the one programmed from JFlash is not working, if the one flashed with nRF Connect does not contain the same hex-file that you flashed.

Could it be that you have somehow erased/overwritten the bootloader, which is causing the application to not run on the Dongle flashed using JFlash?