• State Suggested Answer
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 74 subscribers
  • Views 688 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272075
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf52840 dongle debugging with DK was working now isn't.

michaelmac

Hi all, 

apologies i know there are a lot of posts about this but i cant find the exact answer.  I'm using the nrf52840 dongle, with a DK connected to the programming header. 

i have followed the nrf52840-dongle-programming-tutorial and was able to debug using segger embedded studio, on a couple of blinky projects.  i then tried a uart example (still following the dongle tutorial for mem locations and setting uicr to 3V) and it stopped working.  When i start debugging it "starts" but the device is still in DFU mode (slow flashing red led), if i hit pause the debugger is lost, program counter shows 0x000e4b9e. This now happens even going back to the blinky project that worked before.  I tried reverting to production bootloader per the tutorial and repeated but didnt help. 

Am i missing something that needs to be done to the bootloader? im confused as to how the bootloader / mbr interacts with debugging.  

many thanks,

Michael. 

  • 0

    Hi Michael, 
    Could you let me know how you program the blinky example and the uart example to the dongle ? 
    Note that if you have the bootloader still remain on the dongle, the bootloader would expect that all application on the dongle is updated via the bootloader not directly flashed (CRC check or hash check, depends on how you configure the bootloader). 

    So my suggestion, if you are doing development and you have soldered the header on P1, you can just erase the bootloader and keep only the MBR on the board. 
    When you have the final image ready you can flash the bootloader back and use the bootloader to flash your application to the dongle. 

  • 0 in reply to Hung Bui

    Hi thanks for the reply.  i was programming them by selecting debug->go.  can see the details in the output window in the picture i attached.  

    i think i understand what you mean, so the bootloader was not deleted when i programmed my application (and mbr) via debug, therefore it probably fails CRC check?  

    I erased the whole chip, then programmed my application (no MBR or bootloader) which worked fine. Now seeing your message i retried with mbr + application and it still works with debugging :) 

    Do i still need the mbr if not using the bootloader, and how does it know where my application resides? 

  • 0 in reply to michaelmac

    Hi again Michael, 
    No you don't need the MBR if you don't plan to use the bootloader in the end product. 
    For now you can just erase the whole chip and just flash the application. 
    If you want the bootloader then you need to change the start address of the application to 0x1000 and flash the MBR and the bootloader back in.

Related
Terms of service