cfsetispeed() now stores baud rate to c_cflag member of
struct termios, so it must not be overridden later on.
Signed-off-by: Juha Niskanen <juha.niskanen@haltian.com>
and remove the special handling in the stack dump
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: Ia1ef9a427bd4c7f6cee9838d0445f29cfaca3998
arch/arm/src/stm32/stm32_lowputc.c:
* stm32_lowsetup(): Ensure the USART is disabled before attempting
to configure it because some register bits cannot be modified
otherwise. This solves an issue that was encountered when a
serial bootloader did not perform a full teardown/cleanup before
launching NuttX.
Comments only. No functional changes. See STM32G474 Reference Manual
(RM0440 Rev 4), section 3.4.1, Table 11, "Option byte organization."
arch/arm/src/stm32/hardware/stm32g47xxx_memorymap.h:
* STM32_OPTION_BASE: The comment incorrectly said the range was
0x1fff7800-0x1fff780f for a total of 16 Option Bytes. Corrected
this to 0x1fff7800-0x1fff782f, as the device has 48 Option Bytes
for this option block.
* STM32_OPTION_BASE2: The comment incorrectly said the range was
0x1ffff800-0x1ffff80f for a total of 16 Option Bytes. Corrected
this to 0x1ffff800-0x1ffff82f, as the device has 48 Option Bytes
for this option block.
to save the preserved space(1KB) and also avoid the heap overhead
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I694073f68e1bd63960cedeea1ddec441437be025
malloc() and free() should never be used within the OS. This will work in the FLAT build because there is only a single heap, but will cause problems in PROTECTED and KERNEL build modes where there are separate heaps for user and kernel memory.
Typically kmm_malloc(), kmm_zalloc(), and kmm_free() should be called within the kernel in those build modes to use the kernel heap.
Memory is never free. Possible memory leak:
./boards/arm/cxd56xx/common/src/cxd56_crashdump.c: pdump = malloc(sizeof(fullcontext_t));
Memory allocated with malloc(), but freed with kmm_free():
./drivers/usbhost/usbhost_composite.c: cfgbuffer = (FAR uint8_t *)malloc(CUSTOM_CONFIG_BUFSIZE);
Memory is never freed in these cases. It is allocated in the driver initialization logic, but there is no corresponding uninitialization logic; memory is not freed on error conditions:
./arch/arm/src/lc823450/lc823450_i2s.c: priv = (struct lc823450_i2s_s *)zalloc(sizeof(struct lc823450_i2s_s));
./arch/arm/src/sam34/sam_spi.c: spics = (struct sam_spics_s *)zalloc(sizeof(struct sam_spics_s));
./arch/arm/src/sama5/sam_spi.c: spics = (struct sam_spics_s *)zalloc(sizeof(struct sam_spics_s));
./arch/arm/src/samv7/sam_spi.c: spics = (struct sam_spics_s *)zalloc(sizeof(struct sam_spics_s));
Memory is allocated with zalloc() but freed on error conditions with kmm_free():
./arch/arm/src/sama5/sam_ssc.c: priv = (struct sam_ssc_s *)zalloc(sizeof(struct sam_ssc_s));
./arch/arm/src/samv7/sam_ssc.c: priv = (struct sam_ssc_s *)zalloc(sizeof(struct sam_ssc_s));
./arch/arm/src/stm32/stm32_i2s.c: priv = (struct stm32_i2s_s *)zalloc(sizeof(struct stm32_i2s_s));
Memory is never freed:
./drivers/spi/spi_bitbang.c: priv = (FAR struct spi_bitbang_s *)zalloc(sizeof(struct spi_bitbang_s));
stm32_i2sdev_initialize to stm32_i2sbus_initiliaze, to be consistent
with the way other buses are initialized.
The stm32_i2sdev_initiliaze (similar to stm32_spidev_initialize for
example) is a board specific function that does any necessary
initialization that's board depedent.
Add support for the STM32G474 family of microcontrollers and the
B-G474E-DPOW1 Discovery Board, which features a STM32G474RET6.
This is a major pull request as it adds support for an entirely
new family of STM32. This support is implemented in
arch/arm/src/stm32 and shares implementation with other STM32
families supported by that code, such as the 'L15xx, 'F10xx,
'F20xx, 'F3xxx, and 'F4xxx.
arch/arm/Kconfig:
arch/arm/include/stm32/chip.h:
arch/arm/include/stm32/irq.h:
arch/arm/src/stm32/Kconfig:
arch/arm/src/stm32/hardware/stm32_adc.h:
arch/arm/src/stm32/hardware/stm32_adc_v2.h:
arch/arm/src/stm32/hardware/stm32_dma.h:
arch/arm/src/stm32/hardware/stm32_dma_v1.h:
arch/arm/src/stm32/hardware/stm32_flash.h:
arch/arm/src/stm32/hardware/stm32_i2c.h:
arch/arm/src/stm32/hardware/stm32_i2c_v2.h:
arch/arm/src/stm32/hardware/stm32_memorymap.h:
arch/arm/src/stm32/hardware/stm32_pinmap.h:
arch/arm/src/stm32/hardware/stm32_tim.h:
arch/arm/src/stm32/stm32_allocateheap.c:
arch/arm/src/stm32/stm32_dma.c:
arch/arm/src/stm32/stm32_dma_v1.c:
arch/arm/src/stm32/stm32_dumpgpio.c:
arch/arm/src/stm32/stm32_gpio.c:
arch/arm/src/stm32/stm32_gpio.h:
arch/arm/src/stm32/stm32_lowputc.c:
arch/arm/src/stm32/stm32_rcc.c:
arch/arm/src/stm32/stm32_rcc.h:
arch/arm/src/stm32/stm32_serial.c:
arch/arm/src/stm32/stm32_syscfg.h:
arch/arm/src/stm32/stm32_uart.h:
* Add architectural support to existing NuttX files. This
makes the STM32G474 family parts accessible to the system.
With big thanks for detailed code review:
David Sidrane (davids5)
Mateusz Szafoni (raiden00)
Abdelatif Guettouche (Ouss4)
Add support for the STM32G474 family of microcontrollers and the
B-G474E-DPOW1 Discovery Board, which features a STM32G474RET6.
This is a major pull request as it adds support for an entirely
new family of STM32. This support is implemented in
arch/arm/src/stm32 and shares implementation with other STM32
families supported by that code, such as the 'L15xx, 'F10xx,
'F20xx, 'F3xxx, and 'F4xxx.
arch/arm/include/stm32/stm32g47xxx_irq.h:
arch/arm/src/stm32/hardware/stm32g474cxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g474mxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g474qxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g474rxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g474vxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g47xxx_gpio.h:
arch/arm/src/stm32/hardware/stm32g47xxx_memorymap.h:
arch/arm/src/stm32/hardware/stm32g47xxx_pinmap.h:
arch/arm/src/stm32/hardware/stm32g47xxx_pwr.h:
arch/arm/src/stm32/hardware/stm32g47xxx_rcc.h:
arch/arm/src/stm32/hardware/stm32g47xxx_syscfg.h:
arch/arm/src/stm32/hardware/stm32g47xxx_uart.h:
arch/arm/src/stm32/stm32g47xxx_rcc.c:
* New files required for architectural support. Note that
existing NuttX files are not modified. As such, in this
revision, the system is unaffected by their addition.
With big thanks for detailed code review:
David Sidrane (davids5)
Mateusz Szafoni (raiden00)
Abdelatif Guettouche (Ouss4)
