Jeff Epler dc74ae83da nRF: Always use sd_nvic_critical_region calls
The motivation for doing this is so that we can allow
common_hal_mcu_disable_interrupts in IRQ context, something that works
on other ports, but not on nRF with SD enabled.  This is because
when SD is enabled, calling sd_softdevice_is_enabled in the context
of an interrupt with priority 2 or 3 causes a HardFault.  We have chosen
to give the USB interrupt priority 2 on nRF, the highest priority that
is compatible with SD.

Since at least SoftDevice s130 v2.0.1, sd_nvic_critical_region_enter/exit
have been implemented as inline functions and are safe to call even if
softdevice is not enabled.  Reference kindly provided by danh:
 https://devzone.nordicsemi.com/f/nordic-q-a/29553/sd_nvic_critical_region_enter-exit-missing-in-s130-v2

Switching to these as the default/only way to enable/disable interrupts
simplifies things, and fixes several problems and potential problems:
 * Interrupts at priority 2 or 3 could not call common_hal_mcu_disable_interrupts
   because the call to sd_softdevice_is_enabled would HardFault
 * Hypothetically, the state of sd_softdevice_is_enabled
   could change from the disable to the enable call, meaning the calls
   would not match (__disable_irq() could be balanced with
   sd_nvic_critical_region_exit).

This also fixes a problem I believe would exist if disable() were called
twice when SD is enabled.  There is a single "is_nested_critical_region"
flag, and the second call would set it to 1.  Both of the enable()
calls that followed would call critical_region_exit(1), and interrupts
would not properly be reenabled.  In the new version of the code,
we use our own nesting_count value to track the intended state, so
now nested disable()s only call critical_region_enter() once, only
updating is_nested_critical_region once; and only the second enable()
call will call critical_region_exit, with the right value of i_n_c_r.

Finally, in port_sleep_until_interrupt, if !sd_enabled, we really do
need to __disable_irq, rather than using the common_hal_mcu routines;
the reason why is documented in a comment.
2020-07-15 09:26:47 -05:00
..
2020-07-13 15:53:44 -07:00
2019-12-18 15:39:11 +07:00
2020-01-05 23:33:42 -05:00
2020-04-21 12:29:56 +08:00
2020-07-06 19:16:25 +01:00
2020-05-27 11:28:50 +08:00
2020-05-27 11:28:49 +08:00
2018-06-27 20:52:13 +02:00
2019-12-11 15:43:06 -05:00
2019-08-11 08:53:02 -05:00

CircuitPython Port To The Nordic Semiconductor nRF52 Series

This is a port of CircuitPython to the Nordic Semiconductor nRF52 series of chips.

Note

: There are board-specific READMEs that may be more up to date than the generic board-neutral documentation below.

Flash

Some boards have UF2 bootloaders and can simply be flashed in the normal way, by copying firmware.uf2 to the BOOT drive.

For some boards, you can use the flash target:

make BOARD=pca10056 flash

Segger Targets

Install the necessary tools to flash and debug using Segger:

JLink Download

nrfjprog linux-32bit Download

nrfjprog linux-64bit Download

nrfjprog osx Download

nrfjprog win32 Download

note: On Linux it might be required to link SEGGER's libjlinkarm.so inside nrfjprog's folder.

DFU Targets

run follow command to install adafruit-nrfutil from PyPi

$ pip3 install --user adafruit-nrfutil

make flash and make sd will not work with DFU targets. Hence, dfu-gen and dfu-flash must be used instead.

  • dfu-gen: Generates a Firmware zip to be used by the DFU flash application.
  • dfu-flash: Triggers the DFU flash application to upload the firmware from the generated Firmware zip file.

When enabled you have different options to test it: