The implementation internally uses sector erase to wipe everything except
the sector(s) that mboot lives in (by erasing starting from
APPLICATION_ADDR).
The erase command can take some time (eg an STM32F765 with 2MB of flash
takes 8 to 10 seconds). This time is normally enough to make pydfu.py fail
with a timeout. The DFU standard includes a mechanism for the DFU device
to request a longer timeout as part of the get-status response just before
starting an operation. This timeout functionality has been implemented
here.
Before this commit the USB VCP TX ring-buffer used the basic implementation
where it can only be filled to a maximum of buffer size-1. For a 1024 size
buffer this means the largest packet that can be sent is 1023. Once a
packet of this size is sent the next byte copied in goes to the final byte
in the buffer, so must be sent as a 1 byte packet before the read pointer
can be wrapped around to the beginning. So in large streaming transfers,
watching the USB sniffer you basically get alternating 1023 byte packets
then 1 byte packets.
This commit changes the ring-buffer implementation to a scheme that doesn't
have the full-size limitation, and the USB VCP driver can now achieve a
constant stream of full-sized packets. This scheme introduces a
restriction on the size of the buffer: it must be a power of 2, and the
maximum size is half of the size of the index (in this case the index is
16-bit, so the maximum size would be 32767 bytes rounded to 16384 for a
power-of-2). But this is not a big limitation because the size of the
ring-buffer prior to this commit was restricted to powers of 2 because it
was using a mask-based method to wrap the indices.
For an explanation of the new scheme see
https://www.snellman.net/blog/archive/2016-12-13-ring-buffers/
The RX buffer could likely do with a similar change, though as it's not
read from in chunks like the TX buffer it doesn't present the same issue,
all that's lost is one byte capacity of the buffer.
USB VCP TX throughput is improved by this change, potentially doubling the
speed in certain cases.
By passing through the I2C instance to the application callbacks, the
application can implement multiple I2C slave devices on different
peripherals (eg I2C1 and I2C2).
This commit also adds a proper rw argument to i2c_slave_process_addr_match
for F7/H7/WB MCUs, and enables the i2c_slave_process_tx_end callback.
Mboot is also updated for these changes.
Signed-off-by: Damien George <damien@micropython.org>
Mboot now supports FAT, LFS1 and LFS2 filesystems, to load firmware from.
The filesystem needed by the board must be explicitly enabled by the
configuration variables MBOOT_VFS_FAT, MBOOT_VFS_LFS1 and MBOOT_VFS_LFS2.
Boards that previously used FAT implicitly (with MBOOT_FSLOAD enabled) must
now add the following config to mpconfigboard.h:
#define MBOOT_VFS_FAT (1)
Signed-off-by: Damien George <damien@micropython.org>
This commit factors the code for files and streaming to separate source
files (vfs_fat.c and gzstream.c respectively) and introduces an abstract
gzstream interface to make it easier to plug in different filesystems.
Signed-off-by: Damien George <damien@micropython.org>
There's no need to do a directory listing to search for the given firmware
filename, it just takes extra time and code size. Instead this commit
changes it so that the requested firmware file is opened immediately and
will abort if the file couldn't be opened. This also allows to specify
files in a directory.
Signed-off-by: Damien George <damien@micropython.org>
Previously, if FAT was not enabled but LFS1/2 was then MICROPY_PY_IO_FILEIO
would be disabled and file binary-mode was not supported.
Signed-off-by: Damien George <damien@micropython.org>
Commit 8675858465 switched to using the CMSIS
provided SystemInit function which sets VTOR to 0x00000000 (previously it
was 0x08000000). A VTOR of 0x00000000 will be correct on some MCUs but not
on others where the built-in bootloader is remapped to this address, via
__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH().
To make sure mboot has the correct vector table, this commit explicitly
sets VTOR to the correct value of 0x08000000.
Signed-off-by: Damien George <damien@micropython.org>
There's no need to duplicate this functionality in mboot, the code provided
in stm32lib/CMSIS does the same thing and makes it easier to support other
MCU series.
Signed-off-by: Damien George <damien@micropython.org>
The flash functions in ports/stm32/flash.c are almost identical to those in
ports/stm32/mboot/main.c, so remove the duplicated code in mboot and use
instead the main stm32 code. This also allows supporting other MCU series.
Signed-off-by: Damien George <damien@micropython.org>
This commit makes the low-level flash C functions usable by code other than
flashbdev.c (eg by mboot). Changes in this commit are:
- flash_erase() and flash_write() now return an errno error code, a
negative value on error.
- flash_erase() now automatically locks the flash, as well as unlocking it.
- flash_write() now automatically unlocks the flash, as well as locking it.
- flashbdev.c is modified for the above changes.
Signed-off-by: Damien George <damien@micropython.org>
irq.h is included by py/mphal.h but it's better to be explicit, eg if mboot
uses powerctrlboot.c.
Signed-off-by: Damien George <damien@micropython.org>
The irq.h file now just provides low-level IRQ definitions and priorities.
All Python binding definitions are moved to modmachine.h, with some
renaming of pyb -> machine, and also the machine_idle definition (was
pyb_wfi) is moved to modmachine.c.
The cc3200 and teensy ports are updated to build with these changes.
Signed-off-by: Damien George <damien@micropython.org>
Otherwise the RMT will repeat pulses when using loop(True). This repeating
is due to a bug in the IDF which will be fixed in an upcoming release, but
for now the accepted workaround is to swap these calls, which should still
work in the fixed version of the IDF.
Fixes issue #6167.
With only `sp_func_proto_paren = remove` set there are some cases where
uncrustify misses removing a space between the function name and the
opening '('. This sets all of the related options to `force` as well.
There are a maximum of 8 USB endpoints and each has 2 buffer slots
(in/out). This commit add support for up to 8 endpoints and adds FIFO
configuration for USB profiles with 2xVCP on MCUs that have device-only USB
peripherals.
Tested on NUCLEO_WB55 in 2xVCP, 2xVCP+MSC and 2xVCP+MSC+HID mode.
Signed-off-by: Damien George <damien@micropython.org>
The ESP32 RMT peripheral has hardware support for a carrier frequency, and
this commit exposes it to Python with the keyword arguments carrier_freq
and carrier_duty_percent in the constructor. Example usage:
r = esp32.RMT(0, pin=Pin(2), clock_div=80, carrier_freq=38000, carrier_duty_percent=50)
Zephyr renamed CONFIG_FLOAT to CONFIG_FPU to better reflect its semantics
of enabling the hardware floating point unit (FPU) rather than enabling
toolchain-level floating point support (i.e., software floating point for
FPU-less socs).
Zephyr deprecated and then removed its stack_analyze function because it
was unsafe. Use the new zephyr thread analyzer instead and rename the
MicroPython function to zephyr.thread_analyze() to be more consistent with
the implementation.
Tested on mimxrt1050_evk.
The output now looks like this:
>>> zephyr.thread_analyze()
Thread analyze:
80004ff4 : unused 400 usage 112 / 512 (21 %)
rx_workq : unused 1320 usage 180 / 1500 (12 %)
tx_workq : unused 992 usage 208 / 1200 (17 %)
net_mgmt : unused 656 usage 112 / 768 (14 %)
sysworkq : unused 564 usage 460 / 1024 (44 %)
idle : unused 256 usage 64 / 320 (20 %)
main : unused 2952 usage 1784 / 4736 (37 %)
Sending more than 64 bytes to the USB CDC endpoint in HS mode will lead to
a hard crash. This commit fixes the issue, although there may be a better
fix from upstream TinyUSB in the future.
With this commit the code should work correctly regardless of the size of
StackType_t (it's actually 1 byte in size for the esp32's custom FreeRTOS).
Fixes issue #6072.
This commit implements an LED class with rudimentary parts of a pin C API
to support it. The LED class does not yet support setting an intensity.
This LED class is put in the machine module for the time being, until a
better place is found.
One LED is supported on TEENSY40 and MIMXRT1010_EVK boards.
