This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Migrating from nrf52 DK to custom board, guidance required

Hello,

I am having some trouble migrating from the nrf52 DK to my custom board with an nRF52832 and running as standalone.
The application is working as intended when the custom board is connected to the DK debug header as well as on the DK itself.

Following the tutorial here:
devzone.nordicsemi.com/.../getting-started-with-nordics-secure-dfu-bootloader

I managed to get this to work, until it suddenly stopped. I tried going back to older code I had and I can't seem to repeat my success. (could it been a lucky upload order of the bootloader and DFU?)

Could someone please provide some pointers to the overall process, I cannot seem to find any concrete information anywhere.

My (lax) requirements:
-No need for security of any kind including CRC checks
-Programming will be done via the nrf52 DK (nrf52832) debug header
-both bootloader (required?) and application will be uploaded manually (no need to merge hex, open to try if that helps)
-Not using a softdevice
-Development on Segger

I am by no means a SW/FW developer and micros are understood in general, but am likely missing some general concepts. I would like to receive an overview of the process to see whether I am missing something. Please assume I know nothing and that I made every possible mistake.

Thank you in advance,
Nobody

Parents
  • Hi

    It seems like you're mixing RTC (real time counter) and RC oscillator (which is the internal 32.768kHz oscillator). The external crystal is the LF XTAL and has nothing to do with RTC really.

    The reason you don't have these defines is because you're not using a SoftDevice, and these are the SoftDevice configs. Sorry I missed that. Since you say you have an external crystal either way, this is likely not the issue.

    Regarding your misbehaving LED. Wouldn't adding a LED between VDD and a point like P0.08 just always power the LED? When the debugger is connected. What happens if you increase the interval to say 1000ms, so that you should be able to see it blinking. How have you set the pin as? Active high or low? Please use our button and LEDs HW description for details.

    What is the end goal of this custom board anyways? If you're always programming it using the debug header and SWD pins, you won't need a bootloader, and can only worry about the application itself, so what would you like the application to do?

    Best regards,

    Simon

  • Hi,

    Sorry, I believe we had a miscommunication with regards to the LED. 

    The LED is connected using one of the GPIOs as a sink with a current limiting resistor. That way, if I sufficiently increase the interval I will be able to observe it blink as you suggest or probe it to see timing intervals directly on a scope. I stopped before reaching that because I noticed an erratic behavior as mentioned. 

    Solving this issue also proved to solve the application loading problem. It was all attributed to lead inductance. Using different leads yielded different results. So no longer than 5cm and everything works as intended. I shall also add some bulk capacitance to support the current gulps for the periods when the device wakes up and the Tx is abruptly turned on.

    You are indeed correct. I only require the MBR and application. But since that did not work for my initial trials I went down the wrong hole after the wrong issue. Should have checked the power first.

    Thank you in any case and I hope this will help someone else on here.

    All the best,

    Nobody 

Reply
  • Hi,

    Sorry, I believe we had a miscommunication with regards to the LED. 

    The LED is connected using one of the GPIOs as a sink with a current limiting resistor. That way, if I sufficiently increase the interval I will be able to observe it blink as you suggest or probe it to see timing intervals directly on a scope. I stopped before reaching that because I noticed an erratic behavior as mentioned. 

    Solving this issue also proved to solve the application loading problem. It was all attributed to lead inductance. Using different leads yielded different results. So no longer than 5cm and everything works as intended. I shall also add some bulk capacitance to support the current gulps for the periods when the device wakes up and the Tx is abruptly turned on.

    You are indeed correct. I only require the MBR and application. But since that did not work for my initial trials I went down the wrong hole after the wrong issue. Should have checked the power first.

    Thank you in any case and I hope this will help someone else on here.

    All the best,

    Nobody 

Children
No Data
Related