• State Not Answered
  • Replies 16 replies
  • Subscribers 69 subscribers
  • Views 7829 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 284443
Options

Programming a custom board with an NRF52840 dev kit

ryerye120

Hi,

I've made my own PCB with an nrf52840. Right now I'm hoping to test out the bluetooth and measure my board's power consumption - the only problem is that I can't reliably program the microcontroller! A long time ago I was able to program this device with ble_app_blinky so I know the bluetooth works - unfortunately, right now I keep running into JLink errors. The specific setup/issues are listed below:

Right now I'm trying to program my custom board/NRF with 2 example projects: blinky and ble_app_blinky. To do so, I've setup the boards as in the diagram below:

I am powering my custom board with an external supply set to 3.3V (the current limit is set to 3A so we should have more than enough juice) and the dev kit is "powered on" and plugged into my laptop via the uart/usb programming port (the left most usb port on the diagram). With this setup I can reliably program my custom board with the normal blinky program. Unfortunately, when I try to build&debug on my board with ble_app_blinky I get the following error:


Preparing target for download
Executing Reset script TargetInterface.resetAndStop()
Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘s140_nrf52_7.0.1_softdevice.hex’ to J-Link
Programming 2.7 KB of addresses 00000000 — 00000aff
Programming 149.3 KB of addresses 00001000 — 00026597
Failed to download application.
Error during program/erase phase.
Please check J-Link and target connection.
Download failed

sometimes when I "build & run" directly I get a slightly different error:

Reset: Halt core after reset via DEMCR.VC_CORERESET.
Reset: Reset device via AIRCR.SYSRESETREQ.
Downloading ‘s140_nrf52_7.0.1_softdevice.hex’ to J-Link
Programming 2.7 KB of addresses 00000000 — 00000aff
Programming 149.3 KB of addresses 00001000 — 00026597
J-Link: Flash download: Bank 0 @ 0x00000000: 2 ranges affected (4096 bytes)
J-Link: Flash download: Total: 0.652s (Prepare: 0.172s, Compare: 0.027s, Erase: 0.170s, Program & Verify: 0.106s, Restore: 0.175s)
J-Link: Flash download: Program & Verify speed: 37 KiB/s
Failed to download application.
Error during program/erase phase.
Please check J-Link and target connection.
Download failed

I'm using the latest version of the sdk (v17) and s140. To program my board I'm using SES. I have done all my development so far with the nrf52840 dk (PCA10056) and I figured I could use the same example files. Do I have to change the starting/stopping memory locations for programming? If not, does anyone have any suggestions for further log/debug steps I can proceed with?

I beseech the Nordic (company) gods.

Thank you,

Ryan

Parents
  • 0
    hen I try to build&debug on my board with ble_app_blinky I get the following error:

    looks like the board might be resetting during the session. 

    If you do not use the debug function does it work ?

    It is a vary strange cease, only ble_app_blinky?, could you test a --recover command to whip the chip? No other BLE samples have this issue?

    Regards,
    Jonathan

  • 0 in reply to JONATHAN LL

    Hi Jonathan,

    Thanks for getting back to me!

    JONATHAN LL said:
    looks like the board might be resetting during the session. 

    I saw this vaguely mentioned in a few other posts but those situations seemed to be related to faulty USB ports, low voltages, or faulty connections. I can try another usb port today but I think I tried this out yesterday and it didn't change anything. Is there a flag I should toggle in SES?

    JONATHAN LL said:
    If you do not use the debug function does it work ?

    No, unfortunately. I usually get the same error - sometimes it looks different (the second code block), but it usually looks like the first error (first code block).

    JONATHAN LL said:
    It is a vary strange cease, only ble_app_blinky?, could you test a --recover command to whip the chip? No other BLE samples have this issue?

    I'm glad it's not just me! I can try other ble examples. Is it possible to use the "recover" command in SES? If so, how? hahaha. 

    Edit:

    I've tried out a few more examples, their results are listed below:

    1) simple_timer: works

    2) ble_beacon: Does NOT work - similar error

    3) ble_app_alert_notification: Does NOT work - similar error

    4) blinky_rtc_freeRTOS: Does NOT work - similar error

    So it seems that larger programs (that may/may not include soft device) cause it to break while programming. Right now the external board is drawing around 110 mA at 3.3V and the dev kit is connected to my macbook pro (with a USB-C to USB hub as an adaptor). If I try to power the external boards with 3V (which I thought I saw somewhere) it ends up bricking the chip (I keep getting "No idcode detected" which I guess is another problem).

    Also I've found the board that I know has a functioning NRF52840 & antenna so I can rule out any potential board manufacturing issues.

    Also thanks for your prompt response, Jonathan. I'm really lost and this is incredibly frustrating. I can't tell you how much I appreciate you helping me with this.

    Kindest regards,

    Ryan

  • 0 in reply to ryerye120
    ryerye120 said:
    Firstly, when I plug my boards into the nrf connect programmer, I can only see the dev kit (that I'm using to program my custom board). Is there something specific I need to do to see the downstream microcontroller (the one on my custom PCB)?

    This is the expected behaviour, It is the debugger/programmer chip that is shown. 


    I dont quite see what could be the issue with idle_state_handle(), is it only for the ble_app_blinky you have tested this? any other changes you do to the applicaton?

    I think i will take a look at the HW and schematics first and then we can go from there. Can you provide them as PDF and if you have the HW files as GERBER that would be fantastic. 

    Regards,
    Jonathan

  • 0 in reply to JONATHAN LL
    JONATHAN LL said:
    This is the expected behaviour, It is the debugger/programmer chip that is shown.

    I've only tested this with ble_app_blinky so far. I made 2 changes, 1 was commenting out idle_state_handle() and the other was to the pinout of LED4 (because that is different between the dev kit and my pcb). I will try another example! 

    I am working on getting the gerbers - in the meantime here are pdfs of the schematic and layout. This board is meant to test a custom IC that our research group designed, the nrf52840 is in the top left of the board.

    Thanks again for your help!!

    board_schematic.pdfboard_layout.pdf

  • 0 in reply to ryerye120

    So after looking at the schematic and layout pdf files, i have some comments, the layout you have does not exactly follow the recommendations we have for the nrf52840 and the deviations can\will effect at the very least RF performance. 

    There is enough space on the PCB that is should not be an issue to copy\paste the ref design on to the PCB. If you want i can provide more details on the layout of the nRF. But to keep things short it will mostly contain references to the ref design, best to have GERBER files to properly review and address the potential changes. 

    As for the cause of the issue you have now i dont think that it is HW related at the moment.

    Regards,
    Jonathan

  • 0 in reply to JONATHAN LL

    Hi Jonathan,

    Thank you for looking at the schematic and design! It's been a while since I did the schematic/layout but I think we were trying to stay as close as possible to the CKAA WLCSP schematic #3 with a few changes to the antenna (we wanted to use a dedicated antenna chip). Here are the appropriate gerbers (I think). I would really appreciate any feedback!

    gerbers.zip

    As for other examples I have tested ble_app_alert_notification and ble_app_beacon and both exhibited the same behavior as blinky. Worked the first time with build & debug. If I power cycled the board or did a "build & run" they board would halt. If I commented out "nrf_power_mgmt_run()" things work as expected.

    As always, thank you for your help,

    Ryan

  • 0 in reply to ryerye120

    Hi Ryan, 

    Looking at the files there are some tings i want to comment on.

    1. it would be good to have a top layer ground pour. More ground surface area does help reduce return paths and can be used to create coplanar wave guides in sted of strip lines. We do recommend the grounded coplanar wave guide as we have seen that they often preform better.

    2. The decupling cap on the first radio matching component is not directly following the ref. design.  We do have some notes that point to the fact that it is not just matching but also filering of the harmonics so it is best to keep the layout identical. You do have more then enough space to do a copy past of the design. 




    3. Since there is no top layer ground you are also missing out on the some of the pinns that benefit from being connected to top layer ground might give reduced radio performance. The decupling caps here help filter the supply so that no as lite noise as possible can get to the radio.




    ryerye120 said:
    close as possible to the CKAA WLCSP schematic #3

    Did you mean QIAA  no. 3?  aQFN package, in your design that is what is used at least. 



    But i think the layout is ok, adding top layer ground would solve many of the "issues", choice of antenna is good also, many use it and it preforms well.


    As for the application halting after reset issue, i have not figured this out, so will update in a day or two to wit more info\debugging options you can test. Sorry for the slow response.  

    Regards,
    Jonathan

Reply
  • 0 in reply to ryerye120

    Hi Ryan, 

    Looking at the files there are some tings i want to comment on.

    1. it would be good to have a top layer ground pour. More ground surface area does help reduce return paths and can be used to create coplanar wave guides in sted of strip lines. We do recommend the grounded coplanar wave guide as we have seen that they often preform better.

    2. The decupling cap on the first radio matching component is not directly following the ref. design.  We do have some notes that point to the fact that it is not just matching but also filering of the harmonics so it is best to keep the layout identical. You do have more then enough space to do a copy past of the design. 




    3. Since there is no top layer ground you are also missing out on the some of the pinns that benefit from being connected to top layer ground might give reduced radio performance. The decupling caps here help filter the supply so that no as lite noise as possible can get to the radio.




    ryerye120 said:
    close as possible to the CKAA WLCSP schematic #3

    Did you mean QIAA  no. 3?  aQFN package, in your design that is what is used at least. 



    But i think the layout is ok, adding top layer ground would solve many of the "issues", choice of antenna is good also, many use it and it preforms well.


    As for the application halting after reset issue, i have not figured this out, so will update in a day or two to wit more info\debugging options you can test. Sorry for the slow response.  

    Regards,
    Jonathan

Children
Related