Hello,
I guess this is mostly a question for Sebastian.
While you were away, a bunch of us figured out that gcc for CM4 is using the
wrong instruction set for multilib (?).
Can you take a look at issue #4504 please? (I’m pretty sure I didn’t express
that correctly, but I have put all of the
Does it matter that there is a new stable release coming from the LwIP people
very soon now?
As a target user of the system, I can live with pulling STM’s HAL out of the
RTEMS tree completely and adding it back in myself. The HAL calls in RTEMS are
no different than the fight that just happened
Hey Joel,
I don’t suppose this update will be in the places where the build system
decides on the instruction set that newlib uses for Cortex-M4
A
> On 2021-September-07, at 08:56, Joel Sherrill wrote:
>
> On Tue, Sep 7, 2021 at 8:04 AM Ryan Long wrote:
>>
>> Alright, I’ll have that in
On 2021-August-11, at 01:06, Sebastian Huber
wrote:
>
> On 10/08/2021 23:48, Mr. Andrei Chichak wrote:
>> From what I can figure out, there seems to be a problem with the
>> out-of-the-box build of newly that the STM32F4 uses.
>> memset() goes for a few ARM instru
From what I can figure out, there seems to be a problem with the out-of-the-box
build of newly that the STM32F4 uses.
memset() goes for a few ARM instructions and then seems to intentionally branch
into, what the map file indicates is, the middle of fflush().
newly would have been built with th
In an attempt to make some progress, I’ve gone back to trying to install RTEMS6
built for STM32F4. Should be straight forward.
To make things clean, I don’t do any modifications to any of the code being
pulled out of git.
I followed the Quick Start section of the RTEMS User Manual, Release 6 ef
In an attempt to make some progress, I’ve gone back to trying to install RTEMS6
built for STM32F4. Should be straight forward.
To make things clean, I don’t do any modifications to any of the code being
pulled out of git.
I followed the Quick Start section of the RTEMS User Manual, Release 6 ef
Hi Juan,
On the original stm32f4 board for this BSP (STM32F407 on a STMF4 Discovery
board), the FLASH memory resides at 0x0.
I have a BSP for STM32F767 and its FLASH is located at 0x0800 as you have
in the 429. It works.
Andrei
> On 2021-January-21, at 14:02, Juan Solano wrote:
>
> Hi
If I may, remember that MISRA has the organizations go through the rules,
determine which ones they will adopt, and document deviations for the others.
If Sebastian feels strongly that one function exit is never going to happen,
and the rest of the development group agrees, document it fully an
I’m working with ST’s HAL USB stack, and to initialize the various structures,
they use a USB interrupt as a trigger.
In this interrupt, they malloc some space for a descriptor (504 bytes).
The RTEMS malloc always returns 0.
Is there a guard against calling malloc in an interrupt context?
I m
There is a bit of weirdness in the way that ST generates code from Cube. First,
they create a main.c file for you with a main() routine. Nice, but it conflicts
with the way that RTEMS uses Init() as a user entry point.
Next, they put all of the highest level code into a directory called Src.
Th
11 matches
Mail list logo
