• State Verified Answer
  • Replies 6 replies
  • Subscribers 64 subscribers
  • Views 2280 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 227524
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using Debug Out (p19) to program 3rd Party nrf52840/nrf52810 boards with issues

Olaf

I wrote some user data to 3rd party nrf52840 boards flash using the command "nrfjprog --memwr 0x1001084 --val 0x33333333" , when I ran the program the data values was not 0x333333333,

but running the command  "nrfjprog --memrd 0x1001084" returned the correct value 0x33333333. On the nrf52840DK I have cut the fuse in sb40 to prevent the boards 52840 chip to be programmed every time I program a chip using the Debug Out connection.The is the correct way, right?  I am also trying to erase(all) of the flash before writing to it, but it doesn't help either.

What are the correct steps to write reliable to flash memory?

Thanks

  • 0

    Hi,

    Just so there are no misunderstandings. You write 0x33333333, and read it back correctly with nrfjprog? But you have some firmware that reads the same memory address and sees a different value? This looks strange. Can you show details from your source code as well, showing how you read this data and see that it has another value?

    (Regarding SB40 this is not in any way related to this. If you use the debug out connector, then the GND detect signal will cause the interface MCU to use the pins connected to the debug out port instead of the onboard nRF. It will never be programmed in this case, regardless of SB40.)

  • 0 in reply to Einar Thorsrud

    Yes, I verified by reading back with nrfjprog.

    In the code I read from same addr:

    uint8_t device_id[4];

    memcpy(device_id, (uint8_t *)0x10001084, 4);

    device_id array contains 4x 0xFF in program.

    by cutting CB40 and leaving "nrf current measurement open" is it not cutting the power supply to the 

    nrf52840 on the DK? 

    Is there a need to erase the flash area in order to be able to write new values to it?

  • 0 in reply to Olaf

    Olaf said:

    Yes, I verified by reading back with nrfjprog.

    In the code I read from same addr:

    uint8_t device_id[4];

    memcpy(device_id, (uint8_t *)0x10001084, 4);

    device_id array contains 4x 0xFF in program.

     

    This should not be possible. Are you sure you are programming the same device as you are reading out the data from?

    Olaf said:

    by cutting CB40 and leaving "nrf current measurement open" is it not cutting the power supply to the 

    nrf52840 on the DK? 

    Yes, but it will not make the onboard debugger use the debut out port instead. That is decided with the GND detect signal (you can see it printed on the PCB for one pin on P20). When that is grounded, the debugger will program/debug the debug out port. When not, it will program/debug the onboard nRF.

    Olaf said:
    Is there a need to erase the flash area in order to be able to write new values to it?

     Yes. Writing can only change 1's to 0's. Erase changes all bits to 1. This is an inherent property of NOR flash memory.

  • 0 in reply to Einar Thorsrud
    Einar Thorsrud said:
    This should not be possible. Are you sure you are programming the same device as you are reading out the data from?

    No, I am not. 

    Here is my setup: PC -usb- nrf52840 preview DK - DebugOut- tag connect cable - 3rdParty52840 board.

    When I verify the device_id using the memrd command I am getting the same value as I wrote to the 3rd party board. But the problem is I am getting the same device_id when I haven't attached any 3rd party board to the tag-connect cable!

    But you have dismissed the case that nrfjprog writes to the "nrf52840 preview DK" when DebugOut have a tag-connect cable attached.

    How can I verify that the .hex files are transferred correctly to 3rd Party board?

    Thanks

  • +1 in reply to Olaf

    Hi,

    Olaf said:
    But you have dismissed the case that nrfjprog writes to the "nrf52840 preview DK" when DebugOut have a tag-connect cable attached.

    Well, it depends on your HW as well. You need to short the GND detect signal to ground. If that is not done in the device end of the tag-connect cable you should instead short it to GND on the DK (for instance as shown in the image below). This is the signal that determines if the debugger should connect to the onboard nRF52 or via the debug out port.

    Olaf said:
    How can I verify that the .hex files are transferred correctly to 3rd Party board?

    You can verify that you are debugging the custom board and not the DK by for instance reading out the DEVICEID registers and seeing that they are different. If they are not different, then you are always looking at the same device. And if you have a LED or something on your custom board you can of course use the firmware to control it so that you can see that it has been programmed.

Related