These functions enable SDRAM data retention in stop mode. Example usage,
in mpconfigboard.h:
#define MICROPY_BOARD_ENTER_STOP sdram_enter_low_power();
#define MICROPY_BOARD_LEAVE_STOP sdram_leave_low_power();
Calculate the bit timing from baudrate if provided, allowing sample point
override. This makes it a lot easier to make CAN work between different
MCUs with different clocks, prescalers etc.
Tested on F4, F7 and H7 Y/V variants.
This much buffer space is required for CDC data out endpoints to avoid any
buffer overflows when the USB CDC is saturated with data.
Signed-off-by: Damien George <damien@micropython.org>
The nrf52840-mdk-usb-dongle and pca10050 comes with a pre-flashed
bootloader (OpenBootloader).
This commit updates the boards "mpconfigboard.mk" to use DFU as
default flashing method and set the corresponding BOOTLOADER
settings such that nrf52840_open_bootloader_1.2.x.ld linker
script is used.
The default DFU flashing method can be disabled by issuing "DFU=0"
when invoking make. This will lead to "segger" being used as default
flashing tool. When using "DFU=0", the linker scripts will not
compensate for any MBR and Bootloader region being present, and might
overwrite them if they were present.
The commit also removes the custom linker script specific to
nrf52840-mdk-usb-dongle as it now points to a generic.
Updated nrf52840-mdk-usb-dongle's README.md to be more clear on
how to deploy the built firmware.
The port README.md has also been updated. In the list of target
boards a new column has been added to indicate which bootloader
is present on the target board. And for consistency, changed all
examples in the README.md to use "deploy" instead of "flash".
An additional Makefile parameter NRFUTIL_PORT can be set in order
to define the serial port to used for the DFU (Default: /dev/ttyACM0).
The "nrfutil" that is used as flasher towards OpenBootloader is
available for installation through Python "pip".
In case of SD=s140, SoftDevice ID 0xB6 is passed to nrfutil's package
generation which corresponds to SoftDevice s140 v6.1.1.
Add the option for "mpconfigboard.mk" to define whether the
board hosts a bootloader or not. The BOOTLOADER make variable
must be set to the name of the bootloader.
When the BOOTLOADER name is set it is also required to supply
the BOOTLOADER_VERSION_MAJOR and the BOOTLOADER_VERSION_MINOR
from the "mpconfigboards.mk". These will be used to resolve which
bootloader linker script that should be passed to the linker.
The BOOTLOADER section also supplies the C-compiler with
BOOTLOADER_<bootloader name>=<version major><version minor>
as a compiler define. This is for future use in case a bootloader
needs to do modification to the startup files or similar (like
setting the VTOR specific to a version of a bootloader).
Adding variables that can be set from other linker scripts:
- _bootloader_head_size:
Bootloader flash offset in front of the application.
- _bootloader_tail_size:
Bootloader offset from the tail of the flash.
In case the bootloader is located at the end.
- _bootloader_head_ram_size:
Bootloader RAM usage in front of the application.
Updated calculations of application flash and RAM.
Two issues are tackled:
1. The calculation of the correct length to print is fixed to treat the
precision as a maximum length instead as the exact length.
This is done for both qstr (%q) and for regular str (%s).
2. Fix the incorrect use of mp_printf("%.*s") to mp_print_strn().
Because of the fix of above issue, some testcases that would print
an embedded null-byte (^@ in test-output) would now fail.
The bug here is that "%s" was used to print null-bytes. Instead,
mp_print_strn is used to make sure all bytes are outputted and the
exact length is respected.
Test-cases are added for both %s and %q with a combination of precision
and padding specifiers.
The zephyr function net_shell_cmd_iface() was removed in zephyr v1.14.0,
therefore the MicroPython zephyr port did not build with newer zephyr
versions when CONFIG_NET_SHELL=y. Replace with a more general
shell_exec() function that can execute any zephyr shell command. For
example:
>>> zephyr.shell_exec("net")
Subcommands:
allocs :Print network memory allocations.
arp :Print information about IPv4 ARP cache.
conn :Print information about network connections.
dns :Show how DNS is configured.
events :Monitor network management events.
gptp :Print information about gPTP support.
iface :Print information about network interfaces.
ipv6 :Print information about IPv6 specific information and
configuration.
mem :Print information about network memory usage.
nbr :Print neighbor information.
ping :Ping a network host.
pkt :net_pkt information.
ppp :PPP information.
resume :Resume a network interface
route :Show network route.
stacks :Show network stacks information.
stats :Show network statistics.
suspend :Suspend a network interface
tcp :Connect/send/close TCP connection.
vlan :Show VLAN information.
websocket :Print information about WebSocket connections.
>>> zephyr.shell_exec("kernel")
kernel - Kernel commands
Subcommands:
cycles :Kernel cycles.
reboot :Reboot.
stacks :List threads stack usage.
threads :List kernel threads.
uptime :Kernel uptime.
version :Kernel version.
Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
The -Og optimisation level produces a more realistic build, gives a better
debugging experience, and generates smaller code than -O0, allowing debug
builds to fit in flash.
This commit also assigns variables in can.c to prevent warnings when -Og is
used, and builds a board in CI with DEBUG=1 enabled.
Signed-off-by: Damien George <damien@micropython.org>
Allows reserving CAN, I2C, SPI, Timer and UART peripherals. If reserved
the peripheral cannot be accessed from Python.
Signed-off-by: Damien George <damien@micropython.org>
Even though IRQs are disabled this seems to be required on H7 Rev Y,
otherwise Systick interrupt triggers and the MCU leaves the stop mode
immediately.
This commit saves OSCs/PLLs state before STOP mode and restores them on
exit. Some boards use HSI48 for USB for example, others have PLL2/3
enabled, etc.
Also known as L2CAP "connection oriented channels". This provides a
socket-like data transfer mechanism for BLE.
Currently only implemented for NimBLE on STM32 / Unix.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Hardware I2C implementations must provide a .init() protocol method if they
want to support reconfiguration. Otherwise the default is that i2c.init()
raises an OSError (currently the case for all ports).
mp_machine_soft_i2c_locals_dict is renamed to mp_machine_i2c_locals_dict to
match the generic SPI bindings.
Fixes issue #6623 (where calling .init() on a HW I2C would crash).
Signed-off-by: Damien George <damien@micropython.org>
This fixes the build for non-STM32WB based boards when the NimBLE submodule
has not been fetched, and also allows STM32WB boards to build with BLE
disabled.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This is needed to moderate concurrent access to the internal flash, as
while an erase/write is in progress execution will stall on the wireless
core due to the bus being locked.
This implements Figure 10 from AN5289 Rev 3.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This commit switches the STM32WB HCI interface (between the two CPUs) to
require the use of MICROPY_PY_BLUETOOTH_USE_SYNC_EVENTS, and as a
consequence to require NimBLE. IPCC RX IRQs now schedule the NimBLE
handler to run via mp_sched_schedule.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This changes stm32 from using PENDSV to run NimBLE to use the MicroPython
scheduler instead. This allows Python BLE callbacks to be invoked directly
(and therefore synchronously) rather than via the ringbuffer.
The NimBLE UART HCI and event processing now happens in a scheduled task
every 128ms. When RX IRQ idle events arrive, it will also schedule this
task to improve latency.
There is a similar change for the unix port where the background thread now
queues the scheduled task.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This requires that the event handlers are called from non-interrupt context
(i.e. the MicroPython scheduler).
This will allow the BLE stack (e.g. NimBLE) to run from the scheduler
rather than an IRQ like PENDSV, and therefore be able to invoke Python
callbacks directly/synchronously. This allows writing Python BLE handlers
for events that require immediate response such as _IRQ_READ_REQUEST (which
was previous a hard IRQ) and future events relating to pairing/bonding.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Devices with RTC backup-batteries have been shown (very rarely) to have
incorrect RTC prescaler values. Such incorrect values mean the RTC counts
fast or slow, and will be wrong forever if the power/backup-battery is
always present.
This commit detects such a state at start up (hard reset) and corrects it
by reconfiguring the RTC prescaler values.
Signed-off-by: Damien George <damien@micropython.org>
And rename SRC_HAL -> HAL_SRC_C and SRC_USBDEV -> USBDEV_SRC_C for
consistency with other source variables.
Follow on from 0fff2e03fe
Signed-off-by: Damien George <damien@micropython.org>
Prior to this change machine.mem32['foo'] (or using any other non-integer
subscript) could result in a fault due to 'foo' being interpreted as an
integer. And when writing code it's hard to tell if the fault is due to a
bad subscript type, or an integer subscript that specifies an invalid
memory address.
The type of the object used in the subscript is now tested to be an
integer by using mp_obj_get_int_truncated instead of
mp_obj_int_get_truncated. The performance hit of this change is minimal,
and machine.memX objects are more for convenience than performance (there
are many other ways to read/write memory in a faster way),
Fixes issue #6588.
The file `$(BUILD)/firmware.bin` was used by the target `deploy-stlink` and
`deploy-openocd` but it was generated indirectly by the target
`firmware.dfu`.
As this file could be used to program boards directly by a Mass Storage
copy, it's better to make it explicitly generated.
Additionally, some target are refactored to remove redundancy and be more
explicit on dependencies.
Running the update inside the soft-reset loop will mean that (on boards
like PYBD that use a bootloader) the same reset mode is used each
reset loop, eg factory reset occurs each time.
Signed-off-by: Damien George <damien@micropython.org>
