This adds a callback early in the RISC-V startup process that allows a
BSP to copy linker sections in situations where they may not be
automatically mapped.
The content may end up in documentation sources, for this CC-BY-SA-4.0
is required.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Use the configuration values for RISCV_RAM_REGION_BEGIN and
RISCV_RAM_REGION_SIZE to determine the workspace instead of
using the FDT or linker variables.
Fixes#5545.
Where LEON3_GPTIMER_BASE was defined, the finding and initialization of
the timer devices was disabled. However, this code block has an
important side-effect. It initializes all frequencies of the device
tree. Make sure this part is done even if a dynamic initialization of
LEON3_Timer_Adev and LEON3_Timer_Regs is not required.
Close#5541.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The original internal SRAM build variant (tms570ls3137_hdk_intram)
has been used heavily during our initial TMS570 BSP development.
It is much faster then Flash application erase and update
and it prolongs kit usability as the guaranteed erase/write
cycles count is low (1000) for TMS570 used Flash technology.
The problem manifested when I have prepared tms570lc4357_hdk_intram
variant to help in #5537 with start of TMS570 development project
and environment.
HWINIT for internal SRAM build is enabled by
--- a/spec/build/bsps/arm/tms570/objhwinitlc4357hdk.yml
+++ b/spec/build/bsps/arm/tms570/objhwinitlc4357hdk.yml
@@ -5,7 +5,9 @@ copyrights:
- Copyright (C) 2023 embedded brains GmbH & Co. KG
cppflags: []
cxxflags: []
-enabled-by: arm/tms570lc4357_hdk
+enabled-by:
+ - arm/tms570lc4357_hdk
+ - arm/tms570lc4357_hdk_intram
includes: []
install: []
links: []
--- a/spec/build/bsps/arm/tms570/optlowinit.yml
+++ b/spec/build/bsps/arm/tms570/optlowinit.yml
@@ -10,6 +10,7 @@ default:
- enabled-by:
- arm/tms570ls3137_hdk
- arm/tms570lc4357_hdk
+ - arm/tms570lc4357_hdk_intram
value: true
- enabled-by: true
value: false
Closes#5539
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
This build places all code and data into the on-chip
internal SRAM. Even though this limits the application
size and has not much use for final applications
deployment, this configuration is important during
development because the guaranteed Flash write/erase
cycle count is limited to 1000 if a 15-year data retention
guarantee is required.
The load to SRAM is much faster as well.
Signed-off-by: Pavel Pisa <ppisa@pikron.com>
The fetch() function requires a considerable amount of stack space.
Increase the stack size accordingly.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Fixed various typos and grammatical errors in the documentation
throughout the stm32f4 include folder. Additionally, updated
several incorrect register names to ensure technical accuracy.
Add missing Doxygen file headers to msdos.h and msdos_init.c to
comply with documentation standards. Correct a typo ('apropriately'
to 'appropriately') in msdos_init.c.
The STM32F4 USART data register supports up to 9-bit data
when CR1.M is set. The current DR macros mask only bits [7:0],
which truncates the MSB in 9-bit mode.
Extend the field width to [8:0] to match the hardware
definition while remaining compatible with 8-bit mode.
- added CRC check for rtems_fdisk_recover_block_mappings function
- Computes CRC of page data and compares with page descriptor
- Marks pages as bad if CRC mismatch occurs
Fix two issues in the BRR calculation logic.
First the fractional part was computed using an incorrect formula, which
can produce invalid values and does not match the USARTDIV equation. This
also risks a division-by-zero in some cases. The calculation is updated to
follow the correct relation between pclk, baud, and USARTDIV.
Second the computation of the higher approximation of USARTDIV was not
consistent with the intended logic. The update ensures the next valid
step is computed properly when refining the divisor.
These changes make the baud rate calculation more accurate and reliable.
Fix incorrect definition of STM32F4_FLASH_CR_SNB which was missing
its macro parameter.
Also correct the register prefix of OPTSTRT and OPTLOCK which belong
to the FLASH_OPTCR register instead of FLASH_CR.
Previously, the AFIO register bits were not cleared correctly before
setting the remap value, which could overwrite unrelated bits and
cause GPIO remapping to behave incorrectly.
This change ensures that only the intended bits are cleared and updated,
so GPIO remapping works as expected on STM32F10xxx devices.
Fix two issues in the STM32F4 I2C driver related to mutex handling.
The mutex protecting the I2C bus was created with an initial count of
0. For a binary semaphore used as a mutex this causes the first
rtems_semaphore_obtain() call to block indefinitely since the semaphore
starts in the locked state. Initialize the semaphore with a count of 1
so it starts unlocked.
Additionally, stm32f4_i2c_process_message() could return early if the
STOP bit was set in CR1 without releasing the mutex. This would leave
the mutex locked and cause subsequent calls to deadlock. Release the
mutex before returning in this case.
Also cast dummy SR2 reads to (void) to make the intent explicit and
avoid potential compiler warnings about statements with no effect.
arm/stm32f4: Fix I2C mutex initialization and potential mutex leak
fix the indentation on these lines.
The SYSCFG register block misses two reserved registers between
EXTICR4 and CMPCR. This causes CMPCR to be mapped at the wrong
offset (0x18 instead of 0x20).
Add the missing reserved fields to preserve the correct hardware
register layout according to the STM32F4 reference manual.
STM32F4_PWR_CR_PLS now correctly takes a 'val' argument
to avoid compilation errors when selecting PVD level.
Verified other CR/CSR bit definitions and comments; no spelling issues.
Query the GCC build key and check it against the required value.
There are dependencies between the RTEMS sources and external interfaces
provided by Newlib and GCC. For example, POSIX API interfaces may
change due to POSIX standard updates. The GCC build key is used to
provide an indication that the present tools meet the requirements of
the RTEMS sources.
Add the GCC_BUILD_KEY_POLICY build option to define the checking policy.
The GCC build key policy defines how the build key of the present
compiler is checked against the required build key. While the policy is
"ERROR", if the GCC build key has not the expected value, then the build
configuration process produces a fatal error. While the policy is
"WARNING", if the GCC build key has not the expected value, then the
build configuration process produces a warning message. While the
policy is "IGNORE", the GCC build key is not checked at all. The
default policy is "WARNING".
Close#5521.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
The timer's node is shared with the RB tree and before placing it on the
timer server's chain the node needs to set to off chain or
RTEMS_DEBUG may assert.
Kinsey Moore
Rongjie Lee
Sebastian Huber
Gedare Bloom
Pavel Pisa
Karthikey Kadati
Joel Sherrill
Mohamed Ayman
Matteo Concas
Yash
Vhmed-Mvnsour
Prakhar Kumar
Chris Johns