Re: Question on rtems printf problem

[groups]

> On 2022-December-19, at 19:59, tia...@sugon.com  
> wrote:
> 
> Hi:
>   I have a testcode, it will lead to uart print space forever.
> 
> Demo code like this:
>   Init()
>   {
>   create a task;
>   start this task;
>   printf("%*\n");
> while(1) { 
>   sleep()
>   }
>   }

What are you expecting get? The * tells printf that there will be a parameter 
following that will give you the length of the subsequent parameter. Usually of 
the format %*s, length, string.
I’m pretty sure that you don’t have a proper format string, it’s missing the 
item that you should be specifying the length for and then you neither have the 
length nor the item to be printed.

What are you trying to do?


A


-
Andrei Chichak

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

Re: Question on rtems printf problem

[groups]

On 2022-December-19, at 19:59, tia...@sugon.com  wrote:
> 
> Hi:
>   I have a testcode, it will lead to uart print space forever.
> 
> Demo code like this:
>   Init()
>   {
>   create a task;
>   start this task;
>   printf("%*\n");
> while(1) { 
>   sleep()
>   }
>   }

What are you expecting get? The * tells printf that there will be a parameter 
following that will give you the length of the subsequent parameter. Usually of 
the format %*s, length, string.
I’m pretty sure that you don’t have a proper format string, it’s missing the 
item that you should be specifying the length for and then you neither have the 
length nor the item to be printed.

What are you trying to do?


A


-
Andrei Chichak

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

Hands up, do you use the Mini Robomind BSP (MRM332)?

[groups]

Hi all,

The Mini Robomind is a board that was available through the Seattle Robotics 
Society that used the Motorola MC68332 processor. The BSP is called MRM332.

I was wondering if anybody uses this BSP, either for a Mini Robomind or as a 
basis for some other MC68332 board?

Why? I was talking with Joel and Chris during the RTEMS6.1 ticket review and 
asked if they knew if anybody used MRM332 anymore. I have not seen any 
discussion of this BSP or the ‘332 for years and figured that it may be time to 
sunset the BSP rather than continue to keep it up to date if nobody is using it.

I’m putting together an email to the Seattle Robotics Society to see if they 
have any interest, but please speak up if you use this BSP.

Thanks,

Andrei Chichak (from The Great White North (where it is going down to -33C 
tonight))
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: RTEMS_FATAL_SOURCE_EXCEPTION during startup

[groups]

I reported this, Set fixed it, and the report was closed. 

Either someone said “multilib, multilib, multilib” and it came back, Peter 
needs to do a pull, or something has reverted.

https://devel.rtems.org/ticket/4504

A

> On 2022-January-01, at 13:56, Петр Борисенко  wrote:
> 
> I didn't print anything explisitly.
> Here is call stack:
> ```
> Thread #1 (Suspended : Signal : SIGINT:Interrupt) 
> output_char() at console-config.c:104 0x8007132   
> rtems_putc() at rtems_putc.c:31 0x800f038 
> _IO_Vprintf() at iovprintf.c:133 0x800b8b4
> vprintk() at vprintk.c:31 0x8009aa0   
> printk() at printk.c:40 0x800794e 
> bsp_fatal_extension() at bspfatal-default.c:26 0x8006ea2  
> _User_extensions_Iterate() at userextiterate.c:181 0x800e686  
> _User_extensions_Fatal() at userextimpl.h:446 0x800b856   
> _Terminate() at interr.c:38 0x800b856 
> rtems_fatal() at fatal.h:158 0x80103a6
> _ARM_Exception_default() at arm-exception-default.c:24 0x80103a6  
> () at 0xfff9   
> 0x0
> ```
> 
> Best regards.
> Peter Borisenko
> Awesome Technologies, Ltd.
> http://awsmtek.com 
> hardw...@awsmtek.com 
> +79062165482
> 
> 
> On Sat, Jan 1, 2022 at 7:09 PM Joel Sherrill  > wrote:
> Assuming it is compiled correctly, printing this early should be via
> printk().
> 
> Can you attach gdb and just walk through the BSP initialisation?
> 
> --joel
> 
> On Sat, Jan 1, 2022, 2:08 AM mailto:gro...@chichak.ca>> 
> wrote:
> 
> > (sorry, I accidentally sent this to the dev list instead of users. too
> > much cheer)
> >
> > It’s bombing in printf. It’s so early that the stack hasn’t been set up
> > yet, and it’s found an error and it’s trying to poot a message out on the
> > console, which is also not set up yet.
> >
> > Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in
> > RTEMS4.11, and a version in RTEMS5)
> >
> > I had problems with that BSP blowing up just like this because portions of
> > it weren’t compiled with the proper instruction set, and when the startup
> > code called memset (I think), it would call memset in newlib/libc that was
> > compiled for the wrong architecture, do the wrong thing, end up in printf
> > and die a horrible death.
> >
> > Let’s see if I can find the thread on Discord…
> >
> > around August 19/2021
> >
> > run:
> >
> > rtems-exeinfo -O blah.exe
> >
> > and make sure that all of the functions have the same architecture
> > specified. Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which are
> > incompatible.
> >
> >
> >
> > Andrei Chichak
> > (from The Great White North)
> >
> >
> > > On 2021-December-31, at 18:48, Петр Борисенко  > > > wrote:
> > >
> > > Hello and Happy new year!
> > > I am getting an error during startup:
> > > RTEMS_FATAL_SOURCE_EXCEPTION
> > > Catching it in _ARM_Exception_default.
> > > The bsp is `arm/stm32f4`.
> > > Here is contains of CPU_Exception_frame:
> > > register_r0 uint32_t 0x80139bc
> > > register_r1 uint32_t 0
> > > register_r2 uint32_t 0
> > > register_r3 uint32_t 76
> > > register_r4 uint32_t 0
> > > register_r5 uint32_t 0
> > > register_r6 uint32_t 0
> > > register_r7 uint32_t 0
> > > register_r8 uint32_t 0
> > > register_r9 uint32_t 0
> > > register_r10 uint32_t 0
> > > register_r11 uint32_t 0
> > > register_r12 uint32_t 0
> > > register_sp uint32_t 536909088
> > > register_lr void * 0x80001c3 
> > > register_pc void * 0x8013f08 <_svfprintf_r+8152>
> > > register_xpsr uint32_t 16777216
> > > vector uint32_t 3
> > > vfp_context const ARM_VFP_context * 0x0
> > > reserved_for_stack_alignment uint32_t 3522771716
> > > &Console_Port_Minor rtems_device_minor_number * 0x20006988
> > > 
> > > *&Console_Port_Minor rtems_device_minor_number 1363452156
> > >
> > > What could it be? Any common reasons? Or what additional info should I
> > > provide?
> > >
> > > Also it would be really appreciated if someone will help me export/build
> > > bsp as a debuggable source tree.
> > >
> > > Best regards.
> > > Peter Borisenko
> > > Awesome Technologies, Ltd.
> > > http://awsmtek.com 
> > > hardw...@awsmtek.com 
> > > +79062165482
> > > ___
> > > users mailing list
> > > users@rtems.org 
> > > http://lists.rtems.org/mailman/listinfo/users 
> > > 
> >
> > ___
> > devel mailing list
> > de...@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/devel 
> > 
> > ___
> > users mailing list
> > users@rtems.org 
> > http://lists.rtems.org/mailman/listinfo/users 
> > 
> ___
> users mailing list

Re: RTEMS_FATAL_SOURCE_EXCEPTION during startup

[groups]

(sorry, I accidentally sent this to the dev list instead of users. too much 
cheer)

It’s bombing in printf. It’s so early that the stack hasn’t been set up yet, 
and it’s found an error and it’s trying to poot a message out on the console, 
which is also not set up yet.

Umm, what could be wrong? Lemme think… (I’ve worked wth this bsp in RTEMS4.11, 
and a version in RTEMS5)  

I had problems with that BSP blowing up just like this because portions of it 
weren’t compiled with the proper instruction set, and when the startup code 
called memset (I think), it would call memset in newlib/libc that was compiled 
for the wrong architecture, do the wrong thing, end up in printf and die a 
horrible death.

Let’s see if I can find the thread on Discord…

around August 19/2021

run:

rtems-exeinfo -O blah.exe

and make sure that all of the functions have the same architecture specified. 
Mine had a mix of -mcpu=cortex-m4 and -mcpu=arm7tdmi which are incompatible.



Andrei Chichak
(from The Great White North)


> On 2021-December-31, at 18:48, Петр Борисенко  wrote:
> 
> Hello and Happy new year!
> I am getting an error during startup:
> RTEMS_FATAL_SOURCE_EXCEPTION
> Catching it in _ARM_Exception_default.
> The bsp is `arm/stm32f4`.
> Here is contains of CPU_Exception_frame:
> register_r0 uint32_t 0x80139bc
> register_r1 uint32_t 0
> register_r2 uint32_t 0
> register_r3 uint32_t 76
> register_r4 uint32_t 0
> register_r5 uint32_t 0
> register_r6 uint32_t 0
> register_r7 uint32_t 0
> register_r8 uint32_t 0
> register_r9 uint32_t 0
> register_r10 uint32_t 0
> register_r11 uint32_t 0
> register_r12 uint32_t 0
> register_sp uint32_t 536909088
> register_lr void * 0x80001c3 
> register_pc void * 0x8013f08 <_svfprintf_r+8152>
> register_xpsr uint32_t 16777216
> vector uint32_t 3
> vfp_context const ARM_VFP_context * 0x0
> reserved_for_stack_alignment uint32_t 3522771716
> &Console_Port_Minor rtems_device_minor_number * 0x20006988
> 
> *&Console_Port_Minor rtems_device_minor_number 1363452156
> 
> What could it be? Any common reasons? Or what additional info should I
> provide?
> 
> Also it would be really appreciated if someone will help me export/build
> bsp as a debuggable source tree.
> 
> Best regards.
> Peter Borisenko
> Awesome Technologies, Ltd.
> http://awsmtek.com
> hardw...@awsmtek.com
> +79062165482
> ___
> users mailing list
> users@rtems.org
> http://lists.rtems.org/mailman/listinfo/users

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

Re: Pleiades Neo and RTEMS?

[groups]

https://www.youtube.com/watch?v=onGXURpR1bM&ab_channel=RawSpace

> On 2021-August-16, at 10:13, Joel Sherrill  wrote:
> 
> Hi
> 
> I noticed that another Pleiades Neo satellite was launching later today.
> 
> https://directory.eoportal.org/web/eoportal/satellite-missions/p/pleiades-neo
> 
> My quick search didn't find any indication of the software or hardware
> internals of the satellites. Given the parties involved, I expect there is
> a reasonable chance RTEMS is hiding in these somewhere.
> 
> Does anyone have any insight? I'm happy for an offlist answer.
> 
> Thanks.
> 
> --joel

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

Segmentation fault 11 issue with gdb

[groups]

In my ongoing quest to bring up libbsd, I ran into an issue with gdb as built 
for RTEMS5.

gdb 9.1 immediately gives a segmentation fault 11 as it has a fight with 
python3 version 3.9.2.

I managed to find a good explanation of the problem at 
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c47bae859a5af0d95224d9df0e529f7c5aa0

So I managed to trick the RTEMS5 installer into building with gdb 9.2 and it 
had exactly the same problem. The problem report, above, was generated a couple 
of days after 9.2 was released, so the problem should have existed there too.

I then persuaded the installer to grab 10.1 and the issue was gone. Yay. 10.1 
also worked adequately with eclipse and OpenODC (yuck).

I just noticed that gdb 10.2 was released today. I have not tried it yet.

That is all,

Andrei (from The Great White North)
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users

Re: Issue with configure on MacOS

[groups]

> Any ideas or pointers?
> 
> Did you forget to add something to c/src/libbsp? The autoconf builds system 
> files are under the old tree while all the code is under bsps/. This makes it 
> easier to remove the old build system when all is done.
> 
> 

likely. In c/src/lib/libbsp/arm I created a new folder called stm32f767 that 
contains configure.ac and Makefile.am with (my version of) appropriate 
modifications for my ‘767 board.

I assumed that autoconf would pick up all of the stuff in c/src and somehow use 
bsps, but do I need to munge any config files or is the presence of the BSP 
folders in bsps and c/src/lib/libbsp all?

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

Re: Tick interrupt priority?

[groups]

Super, I’ll have to review my projects to see if I did it right.

Granted, it should only come into play when there is interrupt contention, but 
these are the sorts of things that cause subtle issues.

Thanks Chris,

A

> On 2019-September-18, at 22:32, Chris Johns  wrote:
> 
> On 19/9/19 2:16 pm, gro...@chichak.ca wrote:
>> I was reviewing the interrupt priorities on a project where I’m using 
>> FreeRTOS and they want the tick interrupt priority to be very low.
>> 
>> I found this to be not obvious, then started wondering what the elders of 
>> the RTEMS suggest for use with RTEMS.
>> 
>> Should the tick interrupt be high priority or low?
> 
> If all that is happening is the OS tick entry point is being called then I set
> the priority below any other sources. If the OS tick routine expires a timer 
> and
> readies a task that task will not be dispatched until the outer most interrupt
> exits so being any higher does not gain you anything.
> 
> Chris

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

Tick interrupt priority?

[groups]

I was reviewing the interrupt priorities on a project where I’m using FreeRTOS 
and they want the tick interrupt priority to be very low.

I found this to be not obvious, then started wondering what the elders of the 
RTEMS suggest for use with RTEMS.

Should the tick interrupt be high priority or low?

Enquiring minds want to know.

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

Missing arm_switch_reg is blowing up the build. And time is going way too fast.

[groups]

Good morning. 

I did a pull to rebuild the tools and RTEMS from the head for STM32F4 and 
cpukit/libdebugger/rtems-debuger-arm.c blows up in function 
arm_debug_unlock_abort with ‘arm_switch_reg’ undeclared. 

This was working about a week ago when I used the same scripts to pull, build 
the tools, configure, and build RTEMS.



The reason that I did a fresh pull was that time seems to be ticking by 10x 
faster than expected.  Repeated calls to rtems_cpu_usage_report show a time 
that is ticking by at about 10 seconds per real second. A call to 
rtems_clock_get_uptime_nanoseconds (divided by a billion) corroborates this 
finding.


Andrei



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

Options in the STM32F4 BSP

[groups]

I guess this is really a question for Sebastian.

Is there a way to override some of the BSP config options at application build 
time? Like the ports that UART3 show up on?

Also, a while back the ST HAL layer was included in the build somehow, a 
library perhaps, how would you go about using it?

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

Re: RTEMS C++ examples?

[groups]

I’m working on a bit of a hobby project right now and someone bullied me into 
trying C++. Fine. Plus I did say that I’d try it in anger at some point.

So far I’ve managed to get a simple Init going that creates two tasks. I 
haven’t tried it yet, since it was 2AM when I finally got the right sequence of 
extern “C”s in place to get it to compile.

Once I get something that demonstrates that the tasks are truly running and 
have some sort of demonstrable C++ nature, I’ll send someone a zip of the 
project file set and maybe I could learn some better idioms to get this stuff 
going and we can all learn from this.

A

> On 2019-July-24, at 17:46, Chris Johns  wrote:
> 
> On 25/7/19 9:25 am, Joel Sherrill wrote:
>> One open issue we don't know the right solution to is how to mix C/C++ 
>> threads
>> with POSIX threads. The language threads don't have as many attributes as 
>> POSIX
>> threads including stack size and priority. Ignoring that, the task
>> synchronization objects in C++ should just work on RTEMS.
> 
> It would be really good to figure this out and have it work. There are some
> really neat things in C++11 and later like future and promise.
> 
>> Maybe you can create (or port) some neat examples. And we could talk about 
>> them
>> on embedded.fm . :)
> 
> +1
> 
> Chris

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

RTEMS C++ examples?

[groups]

I’m trying to figure out how to get started with using C++ with RTEMS. Mostly 
as an academic endeavour to figure out what people are talking about when they 
say that C++ is so much better than C.

Can anybody point me at any C++ sample code to create a couple of tasks, pass a 
message back and forth perhaps? Like a multi-task blinky.

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

Re: Link errors with an install using quick-start guide

[groups]

Thank you. Thank you. Thank you.

Yes, of course, once I added the configuration section and changed main into an 
appropriately formatted Init, it compiles nicely.

Thanks again,

Andrei

> On 2019-July-22, at 00:05, Sebastian Huber 
>  wrote:
> 
> On 22/07/2019 07:58, Mr. Andrei Chichak wrote:
>> The linker is bitching about a whole bunch of missing symbols. I expect that 
>> there is a problem finding a library.
>> Any pointers?
> 
> You need an application configuration. If you just have a main() function, 
> then you can use the default configuration (I would always write a custom 
> application configuration). To use the default configuration, add 
> -lrtemsdefaultconfig to the linker command line.
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: function declare

[groups]

No, it has nothing to do with RTEMS in particular. Any C program will do this.

> On 2019-June-27, at 21:17, Jython  wrote:
> 
> so it is rtems build requirement?
> 
> On Thu, Jun 27, 2019 at 2:53 AM Mr. Andrei Chichak  > wrote:
> Assume that you are using C and C has a facility to bind together object 
> modules from different files.
> 
> You define a function in one file, it has a bunch of parameters and doesn’t 
> return anything.
> 
> In another file you use that function but don’t have a prototype that tells 
> the compiler anything about the function.
> 
> Now assume that the compiler was written in 1972, and doesn’t benefit from 
> things like mind reading.
> 
> C assumes, by default, that a function has one integer parameter and returns 
> an integer, unless otherwise told. What other choices has it got? Nothing 
> really. 
> 
> So in later versions of C, they introduced a thing called a prototype that 
> gives the compiler a hint about the parameters and return values of a 
> function.
> 
> All that you needed was to take your function header, put a semicolon on the 
> end and paste it before the call to the function and the compiler would have 
> done what you wanted instead of what you said.
> 
> Better yet, take that prototype and put it into a header file and whenever 
> you want to call the function, put in an include statement, the compiler 
> get’s the information about the parameters and return values, and overrides 
> the int func( int) default nature.
> 
> A
> 
>> On 2019-June-26, at 12:41 AM, Jython > > wrote:
>> 
>> I have a function named  oled_write_temp in a.c, if i dont declare it in a.h 
>> , then i will get the wrong supply value in the function within main call, 
>> why?
>> 
>> if i  declare it in a.h, then all is right
>> 
>> void oled_write_temp(float set_temp, const float supply, float return_temp)
>> {
>> 
>> int base_x = 12, base_y = 60;
>> 
>> char buffer[20] = {0};
>> 
>> printf("supply_temp %f at %s\n", supply, __FUNCTION__);
>> 
>> snprintf(buffer, 20, "SUPPLY:%.2f", supply);
>> printf("supply_temp string %s\n", buffer);
>> 
>> oled_clear_area(base_x, base_y + 16, 122, base_y + 32);
>> OLED_ShowString(base_x, base_y + 16, buffer, 16, 1);
>> 
>> memset(buffer, 0, sizeof(buffer));
>> snprintf(buffer, 20, "RETURN:%.2f", return_temp);
>> OLED_ShowString(base_x, base_y + 36, buffer, 16, 1);
>> 
>> memset(buffer, 0, sizeof(buffer));
>> snprintf(buffer, 20, "SET   :%.2f", set_temp);
>> OLED_ShowString(base_x, base_y + 56, buffer, 16, 1);
>> 
>> }
>> 
>> ps: watch line  printf("supply_temp %f at %s\n", supply, __FUNCTION__);
>> ___
>> users mailing list
>> users@rtems.org 
>> http://lists.rtems.org/mailman/listinfo/users 
>> 
> 

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

Re: stm32f4 __wfi

[groups]

Jython,

You may have better luck asking on the ST support forums. Your questions relate 
more to the inner workings of the STM32 sleep and interrupt facilities and less 
about RTEMS.

A

> On 2019-June-20, at 18:58, Jython  wrote:
> 
> 
> handler https://gist.github.com/goog/7bf5ec55139a3ed43e36be5b2eee318b 
> 
> 
> the main loop code 
> https://gist.github.com/goog/d83786e0eb2c97ad3126ded1987b5078 
> 
> 
> when i pressed key, printf("loop begin\n"); does not print immediately 
> so the sleep function does not break
> 
> 
> 
> On Thu, Jun 20, 2019 at 10:47 PM Christian Mauderer  > wrote:
> On 20/06/2019 16:43, Jython wrote:
> > sleep function at the ending of loop, the loop did not begin intermediate
> 
> So just that I understand it correctly: Your have a loop in a task that
> sends your processor to sleep at the end of the loop. Then you wake up
> the processor via an interrupt and the interrupt handler is executed.
> But you don't reach the loop again?
> 
> I think I remember some discussion where you wanted to put a sleep into
> your idle loop? Maybe you have a double sleep?
> 
> > 
> > On Thursday, June 20, 2019, Christian Mauderer  > 
> > >> wrote:
> > 
> > On 20/06/2019 13:25, Jython wrote:
> > > do have service routine,  handler can printk log,  SLEEPONEXIT is 0
> > 
> > So your handler is called? But it seems that the processor wakes up
> > then. How does the "won't stop sleep mode" look like?
> > 
> > >
> > > On Thu, Jun 20, 2019 at 5:19 PM Christian Mauderer
> > mailto:l...@c-mauderer.de> 
> > >
> > >  
> >  > >
> > > On 20/06/2019 10:57, Jython wrote:
> > > > a GPIO EXTI line,
> > > > rtems idle phrase called __wfi, does it make stm32 enter
> > standby mode?
> > > > so key can not wake up it from sleep function
> > >
> > > Please take a look at the reference manual of your chip. Most
> > likely
> > > it's "RM0090 Rev 18" but make sure that's the right part number:
> > >
> > >
> > https://www.st.com/resource/en/reference_manual/dm00031020.pdf 
> > 
> >  > >
> > >
> > > On page 127 there is a description of "Entering low-power mode":
> > >
> > > "Low-power modes are entered by the MCU by executing the
> > WFI (Wait
> > > For Interrupt), or WFE (Wait for Event) instructions, or
> > when the
> > > SLEEPONEXIT bit in the Cortex ®-M4 with FPU System Control
> > > register is set on Return from ISR."
> > >
> > > There is also a description for "Exiting low-power mode". For
> > WFI "any
> > > peripheral interrupt acknowledged by the NVIC can wake up the
> > device."
> > > So your interrupt has to be set up.
> > >
> > > Your code seems to enable the interrupt. But have you registered a
> > > interrupt service routine? Otherwise you might get problems
> > with an
> > > unhandled interrupt on wakeup.
> > >
> > > I only skimmed through the power controller chapter. But it
> > seems that
> > > if you have SLEEPDEEP bit set, you will enter a deeper sleep mode
> > > where peripheral clocks can be disabled. In that state it's
> > possible
> > > that only special pins (like the WKUP) can wake up the processor
> > > again. Please have a detailed look at that chapter to find out all
> > > traps.
> > >
> > > Best regards
> > >
> > > Christian
> > >
> > > >
> > > >
> > > > void keys_init()
> > > > {
> > > > // config gpio
> > > > stm32f4_gpio_set_config(&io_key1);  // PA12
> > > > stm32f4_gpio_set_config(&io_key2);
> > > > stm32f4_gpio_set_config(&io_key3);
> > > > stm32f4_gpio_set_config(&io_key4);
> > > >
> > > >   
> > > > //  SYSCFGEN and exit map
> > > > (*(uint32_t*)0x40023844) |= 1<<14;
> > > >   
> > > > SYSCFG_EXTICR3 = 0;
> > > > SYSCFG_EXTICR4 = 0;
> > > >   
> > > >
> > > >
> > > > // EXIT INIT
> > > > EXTI_IMR |= (1<<12);
> > > > EXTI_RTSR |= (1<<12);
> > > >
> > > > EXTI_IMR |= (1<<

Re: RTEMS scheduler bug ?

[groups]

This sounds like a problem I had in 2015 on an STM32 that Sebastian helped me 
get around. At the end of the ordeal I wrote:

"A bit of review to begin with; I am working with an STM32F4 ARM Cortex M4F 
processor’s ADC section. A feature of this ADC is the ability to have 
conversions triggered by a timer (great for evenly sampled signals), the 
results transferred using double buffered DMA, giving you an interrupt when the 
DMA buffer is half full, then again when the buffer is full.

To let my task know when there was data ready to process, the DMA half/full 
complete interrupt routines would call rtems_event_send. The task would pend on 
the events, with a timeout in case something screwed up.

In my case, the timer would trigger 14 channels of ADC conversions to happen 
400 times per second. This would yield 200 half full and 200 full interrupts 
per second, each calling rtems_event_send.

This action would proceed for a few thousand seconds and then the program would 
crash and, doing some painful debugging, I managed to repeatedly catch the 
system attempting to expire some “watchdogs”, which I believe is the squelching 
of outstanding timeouts on satisfied rtems_event_receive calls.



After trying a whole bunch of dead ends, Sebastian Huber asked me about the 
priorities of the interrupts being generated. 

The ARM architecture uses a vectored interrupt structure quite similar to the 
MC68xxx processors, where a device generates an interrupt and the address of 
the service routine is automatically picked up from a known place in a table 
without having to poll a bunch of registers to figure out what happened and 
branch off to the handler. The ARM processors have assignable priorities on 
most of the interrupts, so if two interrupts assert at the same time, or if a 
higher priority interrupt happens while an interrupt is in progress, you can 
predict what happens.

What I didn’t know is that RTEMS implements something called Non-Maskable 
Interrupts (NMI). The software NMIs don’t seem to be like hardware NMIs (a 
hardware interrupt that can not be turned off), they just have the same name 
(much like the event watchdogs that aren’t like the hardware watchdogs).

What I learned was that RTEMS NMIs are interrupt routines that are not allowed 
to use any RTEMS facilities. So, I presume, these routines would be used for 
dealing with devices that don’t need to interact with task code. The upside is 
that the interrupts can be entered bypassing RTEMS’ overhead.

A drawback is that if you call for RTEMS facilities from within one of these 
routines, apparently, your code becomes rather crashy.




To differentiate between NMI routines and a regular ISR that can call RTEMS 
facilities, the developers use the interrupt priorities and a mask. The NMI 
determination is not specific to the ARM family, each architecture has a mask 
that determines which bits are used to determine if an interrupt routine is an 
NMI or an ISR.


ARM uses an 8 bit priority and a priority in the range of 0x00-0x7F indicates 
an NMI. On an ARM, the lower the number, the more urgent the interrupt, so NMIs 
have higher urgency than ISRs that can use RTEMS facilities.


On the STM32F4, only 4 bits of 8 of priority are implemented, the 4 MSBs with 
the lower 4 being set to 0 (other Cortex M4 implementations have other 
combinations). In ST’s CubeMX tool, you can set the interrupt priority of the 
various interrupt sources in the range of 0-15 and Cube generates code to take 
care of the bit shifting for you. In my case I had set my priorities to 1,2,3 
and 6. Shifted, these became 0x10, 0x20, 0x30, and 0x60. Since these numbers 
are all below 0x80, the RTEMS code was interpreting these interrupts as NMIs, 
bypassing a bunch of the necessary code to support RTEMS calls.

By changing my interrupt priorities to 9, 10, 11, and 14 (shifting gives 0x90, 
0xA0, 0xB0, and 0xE0), the interrupt routines lost their NMI nature and the 
system immediately became dead stable with a 1kHz tick interrupt rate, 2 ADC 
DMA interrupts at 200Hz each, and a CAN interrupt at about 36Hz.”



When I ported RTEMS5 to the STM32F7, I ran into the same issue and used the 
same method to get around it.

I hope this helps.

Andrei





> On 2019-April-03, at 07:46, Sebastian Huber 
>  wrote:
> 
> On 03/04/2019 15:41, Catalin Demergian wrote:
>> yes, I realized yesterday evening that gIntrErrs could be incremented in the 
>> second if.
>> so I rewrote it like this
>> 
>> int gIntrptErrs;
>> int gInsertErrs;
>> 
>> RTEMS_INLINE_ROUTINE void _Scheduler_priority_Ready_queue_enqueue(
>>   Chain_Node *node,
>>   Scheduler_priority_Ready_queue *ready_queue,
>>   Priority_bit_map_Control   *bit_map
>> )
>> {
>>   Chain_Control *ready_chain = ready_queue->ready_chain;
>>   //_Assert(_ISR_Get_level() != 0);
>>   if(_ISR_Get_level() == 0)
>> gIntrptErrs++;
>> 
>>   cnt_before = _Chain_Node_count_unprotected(ready_chain);
>>   _Chain_Append/*_unprotected

does RTEMS use libssh?

[groups]

Hi, there seems to be a protocol issue with libssh that allows the bypass of 
credentials. I was wondering if there are any parts of RTEMS that use libssh?

Instead of butchering the explanation of a protocol that I don’t know, see 
CVE-2018-10933.

I couldn’t find libssh on my RTEMS distro, but I thought I’d ask.

A

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

Re: RTEMS 5 build on a Mac with the latest compilers?

[groups]

My initial tests look very promising. I did a clean pull and build and the ARM 
tools built without complaint. 

I need to do more work on my STM32F767 BSP to get it into the new format, but 
the compile went through the motions well enough.

Andrei

> On 2018-September-18, at 19:08, Chris Johns  wrote:
> 
> On 19/09/2018 03:18, Mr. Andrei Chichak wrote:
>> I was wondering if anybody has tried to do a clean build if the HEAD with 
>> Apple’s latest version of Xcode?
> 
> Not yet.
> 
>> Apple dropped Xcode 10.0 yesterday with all fo the associated command line 
>> tools. Since these are used to build the RTEMS tools, it seemed to be a 
>> dangerous update.
> 
> I saw this yesterday and I have not had a chance to fetch it and try. I forgot
> to kick off the install last night.
> 
>> I always get a flinch when there is a .0 version compiler being dropped and 
>> I’m in the middle of a project.
>> 
> 
> Sure. I have a machine here for just this purpose.
> 
> The only recent issue I have seen is with APFS on high end MacBooks with large
> solid state disks. I thought we had a patch to work around the issue but I
> cannot find it in the RSB and I was building tools on that machine on the
> weekend without a problem so something must have been fixed.
> 
> The only other problem I know of is a BSD vs GNU sed issue on FreeBSD and 
> MacOS...
> 
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41380
> 
> Chris

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

Re: Stitching in another BSP into V5

[groups]

Of course. I should have looked in there.

Thank you for your help.

A

> On 2018-September-04, at 23:55, Sebastian Huber 
>  wrote:
> 
> Hello Andrei,
> 
> you still need the BSP build files in "c", e.g.
> 
> https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/stm32f4
> 
> Build system improvements are extremely time consuming.
> 

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

Re: Malloc from ISR?

[groups]

No, I expect that someone is just being clever. At startup, the USB device 
generates an init event. The author then brings up everything that is needed.

Out of the various people I have done a sanity check with, everybody agrees 
that malloc should not be called in an ISR.

I’ll see what I can do about writing it up and sending a message to ST.

Thanks,

Andrei

> On 2017-December-11, at 19:12, Joel Sherrill  wrote:
> 
> 
> 
> See cpukit/libcsupport/src/malloc_deferred.c. It is definitely returning NULL 
> because
> you shouldn't malloc from an ISR. malloc() is a non-deterministic operation. 
> I am
> surprised that code was designed to do that.
> 
> Perhaps this code assumes the USB interrupt is serviced from a thread. The raw
> interrupt unblocks a thread to run this code.
> 
> --joel
> 
> On Mon, Dec 11, 2017 at 6:36 PM, Mr. Andrei Chichak  > wrote:
> (sorry if this ended up on the Devel list.)
> 
> 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 managed to get around the problem by doing a static allocation, but I was 
> just wondering.
> 
> 
> Andrei
> 
> ___
> users mailing list
> users@rtems.org 
> http://lists.rtems.org/mailman/listinfo/users 
> 

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

An issue with ARM interrupts revisits.

[groups]

Back in June 2015 I reported an issue where my program would crash after a very 
predictable period when working with rtems_event_receive. Sebastian and I 
tracked the problem down to an issue with the priorities of my interrupts 
causing an infinite loop in the dealings with “Watchdog” values in events and 
“NMI”s. (neither watchdog nor NMI are used in the hardware sense).

If my DMA complete interrupts use a priority of less than 0x80 they are 
interpreted as RTEMS NMI events (I probably have that wrong, but no matter).

Now, I’m trying to get a system going on a ST Cortex-M7 using the same 
structures and I’m running into this same problem, or maybe something related 
even though I have set my priorities to 0x80, 0x90, 0xA0, and so on.

I am using the latest head version pulled out of git with the latest tools.

Here is the situation, I have my ADCs set up to deliver results using DMA 200 
times per second using two interrupt routines. One routine is called when the 
ADC buffer is half full, the other when the ADC buffer is full. The interrupt 
routines execute a rtems_event_send call that is picked up in the task code 
using rtems_event_receive.

If I don’t call rtems_event_receive (wth a timeout of 100 ticks) the code runs 
for hours. With the rtems_event_send call, it fails after 125 seconds.

The failure is not something that I have seen before:


#0  _Terminate (the_source=the_source@entry=INTERNAL_ERROR_CORE, 
the_error=the_error@entry=31) at 
/Users/andreichichak/development/rtems/kernel/rtems/c/src/../../cpukit/score/src/interr.c:37
#1  0x0800bf6e in _Internal_error 
(core_error=core_error@entry=INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT) at 
/Users/andreichichak/development/rtems/kernel/rtems/c/src/../../cpukit/score/src/interr.c:52
#2  0x0800dd38 in _Thread_Do_dispatch (cpu_self=, 
level=) at 
/Users/andreichichak/development/rtems/kernel/rtems/c/src/../../cpukit/score/src/threaddispatch.c:186
#3  0x0800f924 in _ARMV7M_Thread_dispatch () at 
/Users/andreichichak/development/rtems/kernel/rtems/c/src/../../cpukit/score/cpu/arm/armv7m-isr-dispatch.c:32


In _Thread_Do_dispatch, it looks like an maybe an ISR is firing when it is 
disabled (?) and then _Internal_error is being called.
 

void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
  Thread_Control *executing;

  _Assert( cpu_self->thread_dispatch_disable_level == 1 );

#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
  if (
!_ISR_Is_enabled( level )
#if defined(RTEMS_SMP)
  && rtems_configuration_is_smp_enabled()
#endif
  ) {
_Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
  }
#endif


Does anybody have any idea where I should look to figure this out?

Thanks,
Andrei

-
Andrei Chichak

Systems Developer
CBF Systems Inc.
Suite 225 
8215 112 St NW
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

Re: Stack_check_Dump_threads_usage printing out the wrong values

[groups]

I fear blowing up builds all over the world, but I’ll give it a try.

A

> On 2017-November-16, at 21:21, Chris Johns  wrote:
> 
> On 17/11/2017 15:05, gro...@chichak.ca wrote:
>> 
>> (I don’t know how to proceed with getting this reported/fixed.)
>> 
> 
> Please head to the wiki (https://devel.rtems.org/) and select the link in the
> "Reporting a bug" column of the Releases Table for the release you are 
> reporting
> the bug against. You will need an account.
> 
> - Clone the git repo and select the branch.
> - Make the change and test.
> - Commit the change with a summary as the first line and then if
>  you need more detail add a body. End the commit message with
>  "Close #12345." with the ticket number.
>eg git commit
> libmisc: Fix formatting in Stack_check_Dump_threads_usage
> Close #12345.
> - Enter 'git format-patch -1'
> - Attach the patch to the ticket.
> 
> Please ask if you are not sure or something does not work.
> 
> Thanks
> Chris

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

Re: Stack_check_Dump_threads_usage printing out the wrong values

[groups]

> On 2017-November-15, at 16:10, Chris Johns  wrote:
> 
> On 16/11/2017 09:50, Mr. Andrei Chichak wrote:
>> I’m working with 4.12 for ARM   (cortex M7)
>> 
>> I’m tracing down an issue and figured it smelled like a stack problem, so I 
>> got
>> my command line interpreter to call rtems_stack_checker_report_usage().
>> 
>> The addresses that it is printing out are just wrong.
>> 
>> STACK USAGE BY THREAD
>> ID NAME  LOWHIGH   CURRENTAVAIL  USED
>> 0x09010001 IDLE  0x536902024 0x536906119 0x536906024   4080  
>>   164
>> 0x0A010001 UI1   0x536906128 0x536910223 0x536910112   4080  
>>   404
>> 0x0A010002 CfgT  0x536910232 0x536914327 0x536914120   4080  
>>   288
>> 0x0A010003 LOGT  0x536914728 0x536918823 0x536918248   4080  
>>   648
>> 0x0A010004 MonT  0x536918832 0x536922927 0x536922592   4080  
>>   404
>> 0x0A010005 ADCT  0x536922936 0x536927031 0x536926712   4080  
>>   388
>> 0x0A010006 CSLT  0x536927040 0x536931135 0x536930512   4080  
>>  1236
>> 
>> So I started chasing the source code and I find that on line 408 of check.c 
>> in
>> function Stack_check_Dump_threads_usage, in the line:
>> 
>>  rtems_printf(
>>printer,
>>"0x%08" PRIx32 " %-21s 0x%08" PRIuPTR " 0x%08" PRIuPTR " 0x%08" PRIuPTR "
>> %6" PRId32 " ",
>>id,
>>name,
>>(uintptr_t) stack->area,
>>(uintptr_t) stack->area + (uintptr_t) stack->size - 1,
>>(uintptr_t) current,
>>size
>>  );
>> 
>> Stack->area has the value 0x20009998 and the value of stack->size is 4096  ( 
>> for
>> process CfgT). Current has the value 0x2000a8c8.
>> 
>> AH, I get it, the values are being prepended with 0x and then printing out in
>> decimal instead of hex.
> 
> Nice fine.
> 
>> 
>> Perhaps in the format, the PRIuPTRs should be PRIx32s instead???
>> 
> 
> Or PRIxPTR?

Yes, I think that PRIxPTR would be the correct pick.

(I don’t know how to proceed with getting this reported/fixed.)

> 
> Chris

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

Re: I've got a problem compiling the 4.11 tools for ARM (fancy_abort)

[groups]

> 
> TypeError: cannot concatenate 'str' and 'general' objects
> ./getRTEMS: line 18: 
> /Users/andreichichak/development/rtems/kernel/rtems/configure: No such file 
> or directory
> make: *** No targets specified and no makefile found.  Stop.
> make: *** No rule to make target `install'.  Stop.
> 
> This looks like a bug in the sb-bootstrap script. I don't have access to a 
> Mac OS X machine, so I can't really help here.
> 
> Try the single threaded "bootstrap" at the top of the tree. Functionally 
> equivalent, just slower. 


That didn’t work.

I thought that my username has a space in it, but MacOS squishes that out. 

I checked to make sure that /rtems/4.12/bin was in my path, it wasn’t. I added 
it and was able to get the stm4f BSP to build. Now I have to stitch in the 
stm32f7x code and see where it goes.

I really shouldn’t do this sort of stuff at 2AM when I’m sick.

A

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

Re: I've got a problem compiling the 4.11 tools for ARM (fancy_abort)

[groups]

Okay, here is the 4.12 build for stm32f4  (it’s something different today):


Generating ./c/src/lib/libcpu/m68k/preinstall.am
Generating ./c/src/lib/libcpu/powerpc/preinstall.am
Generating ./c/src/lib/libcpu/lm32/preinstall.am
Generating ./c/src/lib/libcpu/or1k/preinstall.am
Generating ./c/src/lib/libcpu/i386/preinstall.am
Generating ./c/src/lib/libcpu/mips/preinstall.am
Generating ./c/src/lib/libcpu/sh/preinstall.am
Generating ./c/src/lib/libcpu/sparc64/preinstall.am
Generating ./c/src/lib/libcpu/arm/preinstall.am
Generating ./c/src/lib/libcpu/sparc/preinstall.am
Generating ./c/src/lib/libcpu/bfin/preinstall.am
Generating ./c/src/lib/libcpu/nios2/preinstall.am
RTEMS Source Builder - RTEMS Bootstrap, 4.12 (6c60a4bf600f)
  1/138: autoreconf: configure.ac
  2/138: autoreconf: tools/cpu/configure.ac
  3/138: autoreconf: tools/cpu/sh/configure.ac
  4/138: autoreconf: tools/cpu/generic/configure.ac
  5/138: autoreconf: tools/cpu/nios2/configure.ac
  6/138: autoreconf: tools/build/configure.ac
  7/138: autoreconf: cpukit/configure.ac
  8/138: autoreconf: testsuites/configure.ac
Traceback (most recent call last):
  File 
"/Users/andreichichak/development/rtems/rsb/source-builder/sb-bootstrap", line 
28, in 
bootstrap.run(sys.argv)
  File 
"/Users/andreichichak/development/rtems/rsb/source-builder/sb/bootstrap.py", 
line 279, in run
generate(topdir, opts.jobs(opts.defaults['_ncpus']))
  File 
"/Users/andreichichak/development/rtems/rsb/source-builder/sb/bootstrap.py", 
line 188, in generate
ac.post_process()
  File 
"/Users/andreichichak/development/rtems/rsb/source-builder/sb/bootstrap.py", 
line 158, in post_process
self.command.reraise()
  File 
"/Users/andreichichak/development/rtems/rsb/source-builder/sb/bootstrap.py", 
line 119, in reraise
raise self.result[0](self.result[1]).with_traceback(self.result[2])
  File "/Users/andreichichak/development/rtems/rsb/source-builder/sb/error.py", 
line 36, in __init__
self.set_output('error: ' + what)
TypeError: cannot concatenate 'str' and 'general' objects
./getRTEMS: line 18: 
/Users/andreichichak/development/rtems/kernel/rtems/configure: No such file or 
directory
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target `install'.  Stop.



This is one of the reasons that I was trying to get 4.11 going. I am finding 
that the git clones are a bit bleeding edge. Earlier today I was able to 
configure, just not build. Now the configure bombs.

Sigh.

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

Re: I've got a problem compiling the 4.11 tools for ARM (fancy_abort)

[groups]

Same thing, I tried that too.

I can’t make up that syntax, I do embedded applications not obscure UNIX 
hieroglyphics. I got it out of a quick start guide from RTEMS.org 
 somewhere.

Andrei

> On 2017-October-24, at 01:01, Sebastian Huber 
>  > wrote:
> 
> On 24/10/17 08:54, gro...@chichak.ca  wrote:
>> I was hoping to go there later but, this is the script that I am using to 
>> build the BSP for 4.12:
>> 
>> cd
>> cd development/rtems
>> mkdir kernel
>> cd kernel
>> git clone git://git.rtems.org/rtems.git  rtems
>> cd rtems
>> ./bootstrap -c && ./bootstrap -p && 
>> $HOME/development/rtems/rsb/source-builder/sb-bootstrap
>> cd ..
>> mkdir stm32f4
>> cd stm32f4
>> $HOME/development/rtems/kernel/rtems/configure 
>> --prefix=$HOME/development/rtems/4.12 --target=arm-rtems4.12 
>> --enable-rtemsbsp=stm32f4 --enable-posix
>> make RTEMS_BSP="stm32f4"
> 
> I never used a "make RTEMS_BSP=XXX". Is this documented somewhere? What 
> happens if you do a simple "make"?
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de 
> 
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 



-
Andrei Chichak
4024-120 STREET
EDMONTON, ALBERTA
T6J 1X8
CANADA


Phone: 780-434-6266
Skype: andrei.chichak






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

Re: I've got a problem compiling the 4.11 tools for ARM (fancy_abort)

[groups]

I was hoping to go there later but, this is the script that I am using to build 
the BSP for 4.12:

cd
cd development/rtems
mkdir kernel
cd kernel
git clone git://git.rtems.org/rtems.git rtems
cd rtems
./bootstrap -c && ./bootstrap -p && 
$HOME/development/rtems/rsb/source-builder/sb-bootstrap
cd ..
mkdir stm32f4
cd stm32f4
$HOME/development/rtems/kernel/rtems/configure 
--prefix=$HOME/development/rtems/4.12 --target=arm-rtems4.12 
--enable-rtemsbsp=stm32f4 --enable-posix
make RTEMS_BSP="stm32f4"
make install

and when I get to the `make RTEMS_BSP=“stm32f4”’ make bitches that there is no 
target for ‘all’.

I will quickly rebuild the 4.12 tools and get you a cut/paste of the real error 
message and context.  One possible hint is that there is a mention of an RTEMS 
configuration of version 4.11.99.2, so it will not build right out of the box.

Andrei


> On 2017-October-24, at 00:42, Sebastian Huber 
>  wrote:
> 
> On 24/10/17 08:33, gro...@chichak.ca wrote:
>> I build the 4.12 tools, newlib and the tools build properly but I cannot 
>> build a BSP for stm32f4 or stm32f7x successfully
> 
> What is the problem with 4.12 and these BSPs?
> 
> -- 
> Sebastian Huber, embedded brains GmbH
> 
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> 



-
Andrei Chichak

Systems Developer
CBF Systems Inc.
Suite 225 
8215 112 St NW
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

I've got a problem compiling the 4.11 tools for ARM (fancy_abort)

[groups]

Hello,

I’m attempting to get a BSP rolling for STM32F767 and 4.12 is going reasonably 
poorly, so I am trying to regress back to a BSP for stm32f4 on 4.11.

Now, when putting together the tools for 4.11, I use the script:

cd
mkdir -p development/rtems
cd development/rtems
git clone git://git.rtems.org/rtems-source-builder.git rsb
cd rsb
git checkout 4.11
cd rtems
../source-builder/sb-check
../source-builder/sb-set-builder --list-bsets
../source-builder/sb-set-builder —prefix=$HOME/development/rtems/4.11 
—log=l-4.11-rtems-arm.txt 4.11/rtems-arm



Reasonably straight out of the quick start guide.  BUT, when putting together 
newlib there is an issue where I get:

In file included from ../../gcc-4.9.3/gcc/c/c-objc-common.c:33:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/new:89:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:173:5:
 error: no member named ‘fancy_abort' in namespace 'std::__1'; did you mean 
simply 'fancy_abort'?


…

make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex  
/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin17.0.0-1/doit
error: building 
arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin17.0.0-1


(If I build the 4.12 tools, newlib and the tools build properly but I cannot 
build a BSP for stm32f4 or stm32f7x successfully, so I was going back to a 
release where I could get a good BSP for stm32f4)

This is running on a Mac using OSX 10.13, Xcode 9.0.1, but I’m getting the same 
results with a system running OSX 10.12.6 and Xcode 9.0.1.

Any ideas?

Thank you in advance,
Andrei





(from my other machine: 
axe:~ andreichichak$ /usr/bin/c++ --version
Apple LLVM version 9.0.0 (clang-900.0.38)
Target: x86_64-apple-darwin16.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
)


/usr/bin/c++ -O2 -pipe -fbracket-depth=1024 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/tmp/sb-andreichichak/4.11/rtems-arm/Users/andreichichak/development/rtems/4.11/include
 -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic 
-I../../gcc-4.9.3/gcc -I../../gcc-4.9.3/gcc/c -I../../gcc-4.9.3/gcc/../include 
-I../../gcc-4.9.3/gcc/../libcpp/include 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin16.7.0-1/build/./gmp
 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin16.7.0-1/gcc-4.9.3/gmp
 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin16.7.0-1/build/./mpfr
 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin16.7.0-1/gcc-4.9.3/mpfr
 
-I/Users/andreichichak/development/rtems/rsb/rtems/build/arm-rtems4.11-gcc-4.9.3-newlib-2.2.0.20150423-x86_64-apple-darwin16.7.0-1/gcc-4.9.3/mpc/src
  -I../../gcc-4.9.3/gcc/../libdecnumber 
-I../../gcc-4.9.3/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc-4.9.3/gcc/../libbacktrace-o c/c-objc-common.o -MT 
c/c-objc-common.o -MMD -MP -MF c/.deps/c-objc-common.TPo 
../../gcc-4.9.3/gcc/c/c-objc-common.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is 
deprecated [-Wdeprecated]
In file included from ../../gcc-4.9.3/gcc/c/c-objc-common.c:33:
In file included from 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/new:89:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/exception:173:5:
 error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean 
simply 'fancy_abort'?
_VSTD::abort();
^~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15:
 note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
  ^
../../gcc-4.9.3/gcc/system.h:685:13: note: 'fancy_abort' declared here
extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN;
^
1 error generated.
make[2]: *** [c/c-objc-common.o] Error 1
make[2]: *** Waiting for unfinished jobs

-
Andrei Chichak

Systems Developer
CBF Systems Inc.
Suite 225 
8215 112 St NW
EDMONTON, ALBERTA
T6G 2C8
CANADA

Phone: 780-628-2072
Skype: andrei.chichak










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

Re: dead servers

[groups]

devel.rtems.org is dead and the ones that are referred to in source builder.

A

> On 2017-October-18, at 23:10, Chris Johns  wrote:
> 
> On 19/10/2017 15:55, gro...@chichak.ca wrote:
>> I was trying to get the 4.12 tools working but some of the rtems.org
>>  servers used for git in RSB are giving 503s.
> 
> http://rtems.org/ changes to https://www.rtems.org/.
> 
> They are all working for me.
> 
> Chris

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

dead servers

[groups]

I was trying to get the 4.12 tools working but some of the rtems.org 
 servers used for git in RSB are giving 503s.

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

Re: Building RTEMS tools using Source Builder fails

[groups]

I was building the 4.12 tools for ARM using RSB yesterday and the build would 
randomly fail. Unfortunately, to fix it, I’d delete everything and try again.

Trying again is a very unsatisfying solution. I passed it off as a git 
repository inconsistency.

On the other hand, doing a git checkout 4.11 gives a repeatable failure when 
building newlib for 4.11.

Andrei




(on a Mac, with OSX 10.13 (high sierra), using the latest Xcode)

cd
mkdir -p development/rtems
cd development/rtems
git clone git://git.rtems.org/rtems-source-builder.git rsb
cd rsb
#git checkout 4.11
cd rtems
../source-builder/sb-check
../source-builder/sb-set-builder --list-bsets
#../source-builder/sb-set-builder --prefix=$HOME/development/rtems/4.11 
--log=l-4.11-rtems-arm.txt 4.11/rtems-arm
../source-builder/sb-set-builder --prefix=$HOME/development/rtems/4.12 
--log=l-4.12-rtems-arm.txt 4.12/rtems-arm


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