1) The first enables building with CONFIG_ARCH_IDLE_CUSTOM enabled.
2) The second allows changing voltage output scaling setting and prevents enabling over-drive mode for low frequencies (STM32 F74xx, 75xx, 76xx, 77xx)
STM32, STM32 L4, and STM32 M4: USB OTGFS DMA trace output fix
STM32: Add dump buffer feature to stm32 F4 series
STM32 and STM32 L4: Fix bad USB OTGFS register address
STM32 L4: Fix typo in USB OTGFS register usage
STM32 L4: Add check in USB OTGFS driver to assure that SYSCFG is enabled
Nucleo-L496ZG: Make HSE on Nucleo-L496ZG default to enable USB
lc823450 auto LED support
* arch/arm/src/lc823450: Add auto LED for CPU activity
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
* configs/lc823450-xgevk: Add auto LED support
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Approved-by: Gregory Nutt <gnutt@nuttx.org>
configs/stm32f429i-disco/ltdc: This configuration has been deleted because it violated the portable POSIX OS interface. It used apps/examples/ltdc and include ltdc.h and dma2d.h which were also removed for the same reason.
Fix stm32 dmacapable on f20xx
* Fixed build for STM32F20XX platforms when CONFIG_STM32_DMACAPABLE is enabled
* Fixed build for STM32F20XX platforms when CONFIG_STM32_DMACAPABLE is enabled
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Port STM32F7 I2C driver to STM32L4
* arch/stm32l4: port STM32F7 I2C driver to STM32L4
STM32L4 I2C driver is in work-in-progress state (plentiful of
TODOs and #warnings) and lags many features found in more
up-to-date STM32 I2C drivers. The peripheral on STM32F7 and
STM32L4 are identical except for L4's 'wakeup from stop mode'
flag and STM32F7's I2C driver is in more 'ready to use' state.
Patch ports the STM32F7 I2C driver to STM32L4. The I2C clock
configuration is kept the same as before (I2CCLK = PCLK1 80 Mhz)
instead of switching to STM32F7 arch default that is I2CCLK=HSI.
Further work would be to add configuration option for choosing
I2C clock source instead of current hard-coded default.
* arch/arm/stm32f7: i2c: restore bus frequency after I2C reset
Copy frequency restoration fix from STM32L4 I2C driver to STM32F7 I2C driver.
* arch/arm/stm32f7: i2c: remove unused Kconfig option
* configs/nucleo-l496zg/nsh: enable I2C4 bus with i2ctool
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Master
* stm32_hrtim: fix warnings related with RCC
* stm32f33xxx_adc: add some publicly visable interfaces and some code to support injected channels
* stm32f33xxx_dma: add public interface to handle with DMA interrupts
* stm32_hrtim: change some names and add some coments
* chip/stm32f33xxx_adc.h: cosmetics
* nucleo-f334r8: add logic for zero latency high priority interrupts example
* stm32: update some ADC-related configuration in Kconfig
Approved-by: Gregory Nutt <gnutt@nuttx.org>
STM32L1, STM32L4 RTC: add periodic interrupts, update L1 RTC implementation
* STM32L4 RTC: add support experimental CONFIG_RTC_PERIODIC
* STM32 RTC: separate STM32L1 RTC into a separate file
STM32L1 RTC is very close to F4 or L4 versions, with two alarms
and periodic wakeup support so backported L4 peripheral to L1.
* RTC: add periodic alarms to upper and lower halves
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Master
* stm32f33xxx_adc.c: fix some warnings and compilation error when extsel not in use
* nucleo-f334r8/adc: change serial console to USART2 (STLINK COM)
Approved-by: Gregory Nutt <gnutt@nuttx.org>
Lower part of STM32 CAN driver arch/arm/src/stm32/stm32_can.c uses all three hw tx mailboxes and clears TXFP bit in the CAN_MCR register (it means transmission order is defined by identifier and mailbox number).
This creates situation when order frames are put in upper part of CAN driver (via can_write) and order frames are sent on bus can be different (and I experience this in wild).
Since CAN driver API pretends to be "file like" I expect data to be read from fd the same order it is written. So I consider described behaviour to be a bug.
I propose either to set TXFP bit in the CAN_MCR register (FIFO transmit order) or to use only one mailbox.
