stm32h7 bsp - simple led blink example not working on stm32h7 nucleo board

[John Nathen]

Hi,

I am new to rtems and am planning to use rtems on a project with the
stm32h7 mcu. I cloned the latest sources from git and built the arm-rtems6,
gcc 10.2 toolchain and also built the stm32h7 bsp using the new waf build
system.

Everything works fine and I can build the (modified for stm32h7) LED blink
example application. However, the resulting .bin file, after conversion
from exe to bin using objcopy, does not work - no blinking led.

I then decided to try the stm32f4 discovery board:
If I use the rtems5.1 release version with arm-rtems5, gcc 7.5 and the
configure based build system, I can get the led to blink on this board. It
also works even if I clone the latest rtems source and use the configure
based system with arm-rtems5.

If I use the latest master with arm-rtems6, gcc 10.2 and build the stm32f4
bsp using the new waf build system, the led blink example does NOT work!

I then tried to 'force' rsb to build arm-rtems6 using the gcc 7.5 and tried
to build the stm32f4 bsp using waf. This resulted in a number of linker
errors - multiple definition of __getreent  _Semaphore_Wait and a few
others. Also, undefined reference to _init and so on.

I tried to solve it based on the suggestions given for the __getreent
(crt0.o issue). But still get a number of errors.

I am hoping to get some suggestions on how to proceed further.

Thanks in advance.

John
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

When to register termios devices?

[Jan.Sommer]

Hello,

I try to register several termios devices in a custom BSP (based on RTEMS 5.1).
I tried to do this in the bsp_start function, but this fails.
My guess is, that it is because too early in the system initialization as the 
rtems_filesystem_umask is set, so that no device nodes can be added by 
rtems_termios_device_install.
What would be the right time to do that?
Also, I tried to register my driver initialization function using 
RTEMS_SYSINIT_ITEM, in several phases, but it seems that the function is never 
linked into the final binary.
Is there some trick I need to know to make this work?:
RTEMS_SYSINIT_ITEM(
register_additional_termios,
RTEMS_SYSINIT_DEVICE_DRIVERS,
RTEMS_SYSINIT_ORDER_LAST_BUT_5
);

It works if I register the additional termios devices in the init task, but I 
would like to have this added directly in the BSP, not in the user application.

Best regards,

Jan

Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Jan Sommer
Telephone +49 531 295-2494 | Telefax 0531 295-2767 | 
jan.som...@dlr.de
DLR.de/SC

___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

libbsd select timeout issue

[RUI Zhengxin]

Hello everyone,




We meet an issue of select function timeout drift in rtems-libbsd5.1.

The select timeout can drift 1ms every 14000 seconds.




Kernel put the select thread to sleep queue in sleepq_set_timeout_sbt,

the expire value is calculated by this

expire = (sbt - SBT_1S + sbt_per_tick - 1) / sbt_per_tick;




sbt is the absolute time,

Precision is a constant value, no time drift.

but the sbt_per_tick is not an accurate value,

It can make the expire vaule bigger and bigger while sbt is increasing.




in rtems_bsd_initialize function,

rtems_bsd_sbt_per_watchdog_tick = SBT_1S / tps;

in our system the tick rate is set to 1000Hz,

The real value of rtems_bsd_sbt_per_watchdog_tick is 1<<32/1000=4294967.296

but in integer type the value is 4294967.

The error is 0.296/4294967 = 0.069ppm,

and it can increase the expire value 1ms every 14000 seconds.


Zhengxin
Best regards.___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users