Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32L5_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L5_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L5_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings and
all pins should have had suffixes to allow any pins attributes to
be set. This is board dependent.
This change adds CONFIG_STM32WB_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps with suffixes.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32WB_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32WB_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32F0G0L0_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32L4_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, CONFIG_STM32L4_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32L4_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
replace all GPIO_MODE_xxMHz with GPIO_MODE_2MHz provide GPIO_ADJUST_MODE
and add legacy pinmap
For the stm32F1 pinmaps should not have contained GPIO_MODE_50MHz settings
on all pins. Speed is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps that can have the GPIO_MODE_xxMHz set.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h, and use all the defconfigs with the legacy
pinmap and output the required changes that one needs to make to a board.h
file.
Eventually, CONFIG_STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set CONFIG_STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.hf1
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32F7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32F7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32F7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
Pinmaps should not have contained GPIO_SPEED_xxx settings.
This is board dependent.
This change adds CONFIG_STM32H7_USE_LEGACY_PINMAP to allow for
lazy migration to using pinmaps without speeds.
The work required to do this can be aided by running tools/stm32_pinmap_tool.py.
The tools will take a board.h file and a legacy pinmap and outut the required
changes that one needs to make to a board.h file.
Eventually, STM32H7_USE_LEGACY_PINMAP will be deprecated and the legacy
pinmaps removed from NuttX.
Any new boards added should set STM32H7_USE_LEGACY_PINMAP=n and
fully define the pins in board.h
The text describes an issue related to the running task in code.
The running task is only used when calling the _assert function
to indicate the task that was running before an exception occurred.
However, the current code only updates the running task during
irq_dispatch, which is suitable for ARM-M architecture but not
for ARM-A or ARM-R architecture, because their context switches
are not done through irq handler. Therefore, if the following
process is followed, the value of the running task will be incorrect:
1. task1 is running, this_task()=task1
2. do_irq is executed, setting running task()=task1
3. task1 switches to task2
4. task2 is running and generates a data abort
5. In the data abort, the _assert function is called,
and the running task obtained is still task1, but
the actual task that generated the exception is task2.
Signed-off-by: zhangyuan21 <zhangyuan21@xiaomi.com>
Problem:
AppBringup task in default priority 240 ->
board_late_initialize() ->
some driver called work_queue() ->
nxsem_post(&(wqueue).sem) failed because sem_count is 0
hp work_thread in default priority 224 ->
nxsem_wait_uninterruptible(&wqueue->sem);
so hp_work_thread can't wake up, worker can't run immediately.
Signed-off-by: dongjiuzhu1 <dongjiuzhu1@xiaomi.com>
If this option is enabled, the working path of nuttx will be modified to the folder where the nuttx file is located.
Signed-off-by: yinshengkai <yinshengkai@xiaomi.com>
Over-drive can be forced to a given state by adding define to the
board.h configuration file:
#define STM32_VOS_OVERDRIVE 1 - force over-drive enabled,
#define STM32_VOS_OVERDRIVE 0 - force over-drive disabled,
#undef STM32_VOS_OVERDRIVE - autoselect over-drive by the default RCC logic
It seems that over-drive is not required for ULPI but it can be a workaround solution for boards with poor signal integration.
Higher core voltage means faster clock signal edges, which may be sufficient to synchronize the high-speed clock and data on poorly designed boards.
Over-drive can be forced to a given state by adding define to the
board.h configuration file:
#define STM32_VOS_OVERDRIVE 1 - force over-drive enabled,
#define STM32_VOS_OVERDRIVE 0 - force over-drive disabled,
#undef STM32_VOS_OVERDRIVE - autoselect over-drive by the default RCC logic
It's better to raise error before client sends its (NIOVEC+1)th buffer
(and release buffers held by server), otherwise the client may stuck at
getting (NIOVEC+1)th tx buffer if NIOVEC is equal to rpmsg buffer num.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
