Re: [riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Thanks

On 29-05-19 13:02, Robert Hartung wrote:

Hey everyone,

let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the deepest mode possible.
Which mode is possible depends on the used periphs. For STM32 sleep was
long not possible, as PM_BLOCKER_INITIAL was initialized with 1 for each
mode, which resulted in never going to a sleep mode.
 From what I can see is that it is still initialized with ones?
Nevertheless, to make us of it PM_BLOCKER_INITIAL should be initialized
with 0. All periph modules should then individually block the sleep
modes they can not operate in. For now the biggest problem was the
shell/uart, as it would always block any sleep modes.
An exception are some platforms, as they have a Uart which can wake them
up from sleep modes.

I have modified the atmega1284p implementation to make use of it [0] and
[1].

Best Regards
Robert

[0]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega1284p/periph/pm.c
[1]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega_common/periph/

On 28.05.19 20:01, Kees Bakker wrote:

Nice,

Thanks for sharing

On 28-05-19 08:48, Oleg Artamonov wrote:

Hi.

Yes, but for emergency reboots only.
  
Implementations:

https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c
and
https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c
  
For task scheduling on sleepy devices we use RTC-based timers with 1

ms resolution and 1 week max period
(https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis;
on STM32L, we use regular HW RTC with SSR register, on nRF52 —
"software" RTC implemented on top of HW RTT unit).
  
--

/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ 
  
  
  
27.05.2019, 21:57, "Kees Bakker" :


 Hey Oleg,

 Are you using the watchdog?
  
 On 27-05-19 07:30, Oleg Artamonov wrote:


 Hi
  
 We do. On STM32L0, STM32L1, nRF52, etc.
  
 Checking for interrupt flags is absolutely useless here - 1)

 WFI checks for any relevant interrupt flags, 2) interrupt
 still can happen between check and WFI.
  
 --

 /Sincerely yours,/
 /Oleg Artamonov/
 /+7 (916) 631-34-90/
 /www.unwds.com/ 
  
  
  
 26.05.2019, 18:40, "Kees Bakker" 

 :

 Hey

 Is there anyone using cortexm_sleep for a real
 application? And if
 yes, would you want to share how exactly that's done?

 Let me say that I've never written a real application with
 RIOT, but
 I would like to. One of the important requirements is that
 the app
 must be in sleep (deep sleep) and only wake up to do some
 work.
 And another requirement is to use the watchdog.

 That said, I'm familiar with the following Arduino pseudo
 code.

  while (forever) {
  do stuff

  disable interrupts
  if !certain condition
  __WFI();
  enable interrupts
  }

 That "certain condition" is mostly checking that no WDT or
 RTC interrupt
 occurred before disabling the interrupts. These interrupts
 are handled
 by ISR's and they set a flag. This is a fairly common
 thing to do, I think.

 I don't see (or understand) how this can be achieved with
 RIOT-OS and
 cortexm_sleep. It is essential to check the condition
 AFTER disabling the
 interrupts.

 --
 Kees Bakker
 ___
 devel mailing list
 devel@riot-os.org 
 https://lists.riot-os.org/mailman/listinfo/devel

  


 ___
 devel mailing list
 devel@riot-os.org 
 https://lists.riot-os.org/mailman/listinfo/devel

 ,

 ___
 devel mailing list
 devel@riot-os.org 
 https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel



_

Re: [riot-devel] Lightweight Syslog Implementation

[Juan Ignacio Carrano]

On 29/5/19 14:58, Robin wrote:


The only problem i see is how the backend would distinguish between a 
message for serial logging and a message for something else like syslog, 
since both logging request would be done by invoking LOG(level,"message").




the "level" parameter of our current API is just a level. In unix, on 
the other hand, one has "priority". From the man page of syslog()


> The  priority argument is formed by ORing together a facility value 
and a level value (described below).


The good news is that this ORing scheme is is compatible to what we are 
doing now (it is like we are currently defaulting facility to zero).


On the other side of the message queue you will have:

- The PID of the originating thread. In a way this means that "LOG_PID" 
is always on.
- The (facility, level) selected for that message (can that live in the 
"type" field?)


With that information an appropriate policy can be implemented. How is 
that policy specified and what is the policy is a matter that if think 
is better to ignore for now so that we don't make too many assumptions.


Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CC2538dk Riotboot support

[Brenton Chetty]

Hey guys, i kind of managed to get the riotboot tests to pass. Whenever i
program via terminal (gcc-arm) i receive the error "[FAILED] You're not
running riotboot". But when i program via the UniFlash tool, it works.
Note, so far only "tests_riotboot-slot0-combined.bin" works. I assume its
an offset issue as Gaëtan mentioned. Also, I used the cortexm_base.ld
Linker Script.

Thanks for the help guys


On Wed, May 29, 2019 at 2:18 PM Brenton Chetty  wrote:

> Thanks for the advice guys, but I'm still struggling to get the cc2538dk
> to pass the riotboot tests.
> To: Francisco Acosta
>
> I provided the length and start variables to link the slots.
> I used the cc2538sf53.ld Linker Script.
> I was not sure how to get the offset required, so i used 255 as the
> offset, this value made the slot0.riot.bin file = 512KB.
> I assume this correct because whenever you compile an example (not with
> riotboot), it generates a .bin file with this size.
>
> Any ideas on what i could be doing wrong?
>
> With thanks!
> Brenton
>
>
> On Fri, May 24, 2019 at 2:33 PM Francisco Acosta 
> wrote:
>
>> Hi Brenton!
>>
>> So far I remember we didn't take it into account, and I don't know if
>> someone is taking care of it.
>>
>> As far as I know, there are two ways of supporting that CPU:
>>
>> 1. The way we do it now, which is linking the image in another start
>> address so the bootloader can recognise it and boot it.
>>
>> 2. Modify the start address on the CC2538 register dedicated to this.
>> This might be a bit tricky but also interesting for the sake of research
>> and compatibility.
>>
>> However, I'd advice the first option to have the full benefits of the
>> bootloader and struggling less with the particular settings on that
>> chip.
>>
>> Overall, the steps would be the following:
>>
>> 1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript.
>> This consists on making the linker scripts on cpu/cc2838/ldscripts
>> comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a
>> look how is it done for stm32 or sam0 families.
>>
>> 2. Provide the length and start variables to link slots correctly:
>>- ROM_LEN
>>- RAM_LEN
>>- ROM_START_ADDR
>>- RAM_START_ADDR
>>
>> Again, take a look on the supported CPUs as examples.
>>
>> 3. Make tests/riotboot pass
>>
>> 4. Perform a firmware update or flash different firmwares with different
>> versions so the bootloader choses the newest.
>>
>> Optionally you might want to test if the WIP SUIT update format works.
>>
>> Don't hesitate to make more questions if you have some!
>>
>> Cheers,
>>
>> Paco.
>>
>>
>> On 24/05/2019 13:43, Brenton Chetty wrote:
>> > Hey guys, has anyone succeeded in providing riotboot support for the
>> > cc2538dk board as yet?
>> >
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Lightweight Syslog Implementation

[Robin]

Hi Juan,



The standard works in our favor here:
"The use of openlog() is optional" and " The use of closelog() is 
optional". We can have no-ops for both functions:


#define openlog(ident, option, facility) (void)((ident), (option), 
(facility))


Should not be needed if we do what unix syslog does, initialize it on 
the first call to syslog() if necessary.


Looks like i missed this line. Thanks a lot for pointing out. I just 
pushed an update to my PR yesterday, which simply invokes openlog on 
demand if it wasn't done yet. I would not implement it using a noop, but 
rather stay with an implicit call, since we may want to let the user to 
have the choice to use a identity string which is not equal to the 
threads name. So yea, basically the unix way. I will have another look 
in the standard, maybe i missed some more information.



I suggest the choice should not be between serial backend and syslog 
backend, but rather between serial backend (used for most simple 
applications) and IPC/message queue backend. At the end of the quie is 
the logic deciding how the packet should be sent.


An advantage of this approach is that is is also useful for 
serial-only loggers where one wants to ensure strings don't 
intermingle. Also the current implementation of uart logging inherits 
the blocking characteristics of the UART, meanings that logging blocks 
until the message has been sent.


Of course, most applications are fine with just writing directly to 
UART backend and having the queue by default would be overkill.


I am not sure if i understand you approach correctly. I just try to 
describe it in my own words and you may correct me.


We got two cases:

1. Normal case as it is now: Any invocation of LOG() uses the default 
implementation which defaults to printf/UART


2. More sophisticated approach: Additional LOG_MQUEUE module which 
overwrite the LOG() function (as in log_printfnoformat) with a threaded 
backend implementing a message queue. If a message gets send via LOG() 
the message is transferred to the backend's queue and the backend writes 
the log request to the appropriate logger (UART or syslog for example).


The only problem i see is how the backend would distinguish between a 
message for serial logging and a message for something else like syslog, 
since both logging request would be done by invoking LOG(level,"message").


I could either extend the LOG interface, which would probably break a 
lot of things and would introduce additional complexity in most cases or 
I could treat calls to LOG as UART log request and calls to (for 
example) syslog() as syslog log requests. Both calls would send a 
message to the backend, but set a different flag depending on the 
target. Then a hook functionality in the backend could decide how 
message are dispensed.



BTW, there is an option in UNIX called LOG_CONS:

> LOG_CONS   Write directly to the system console if there is an 
error while sending to the system logger.


I already implemented this functionality, but I think it would not help 
us here, since it only is aimed to allow console logging if no syslogd 
implementation is available.



Robin


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] CC2538dk Riotboot support

[Brenton Chetty]

Thanks for the advice guys, but I'm still struggling to get the cc2538dk to
pass the riotboot tests.
To: Francisco Acosta

I provided the length and start variables to link the slots.
I used the cc2538sf53.ld Linker Script.
I was not sure how to get the offset required, so i used 255 as the offset,
this value made the slot0.riot.bin file = 512KB.
I assume this correct because whenever you compile an example (not with
riotboot), it generates a .bin file with this size.

Any ideas on what i could be doing wrong?

With thanks!
Brenton


On Fri, May 24, 2019 at 2:33 PM Francisco Acosta 
wrote:

> Hi Brenton!
>
> So far I remember we didn't take it into account, and I don't know if
> someone is taking care of it.
>
> As far as I know, there are two ways of supporting that CPU:
>
> 1. The way we do it now, which is linking the image in another start
> address so the bootloader can recognise it and boot it.
>
> 2. Modify the start address on the CC2538 register dedicated to this.
> This might be a bit tricky but also interesting for the sake of research
> and compatibility.
>
> However, I'd advice the first option to have the full benefits of the
> bootloader and struggling less with the particular settings on that
> chip.
>
> Overall, the steps would be the following:
>
> 1. Adapt the linker scripts to succeed tests/cortexm_common_ldscript.
> This consists on making the linker scripts on cpu/cc2838/ldscripts
> comply with cpu/cortexm_common/ldscrpts/cortexm.ld. You might take a
> look how is it done for stm32 or sam0 families.
>
> 2. Provide the length and start variables to link slots correctly:
>- ROM_LEN
>- RAM_LEN
>- ROM_START_ADDR
>- RAM_START_ADDR
>
> Again, take a look on the supported CPUs as examples.
>
> 3. Make tests/riotboot pass
>
> 4. Perform a firmware update or flash different firmwares with different
> versions so the bootloader choses the newest.
>
> Optionally you might want to test if the WIP SUIT update format works.
>
> Don't hesitate to make more questions if you have some!
>
> Cheers,
>
> Paco.
>
>
> On 24/05/2019 13:43, Brenton Chetty wrote:
> > Hey guys, has anyone succeeded in providing riotboot support for the
> > cc2538dk board as yet?
> >
> > ___
> > devel mailing list
> > devel@riot-os.org
> > https://lists.riot-os.org/mailman/listinfo/devel
> >
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT vectors for Smartfusion2 port

[Ashim Asharaph]

Dear Juan and Hauke

Thank you for the suggestions.

To answer Juan's questions, I am not too sure about whether the vectors will 
change or not. It is likely but I might have to get a better understanding to 
know whether that is the case or not. The peripherals will definitely change 
though, depending on the FPGA configuration we use. We do have some ideas in 
mind on how to tackle this but they are not concrete yet.

To fix the dependency issue, I simply renamed the "startup_m2sxxx.S" file to 
"vectors.S". I am not too sure whether this completely solves the problem and 
is an acceptable fix or not, but hopefully that solves the problem.

Your help is much appreciated.

Kind regards
Ashim Asharaph




>>> Juan Ignacio Carrano  05/29/19 1:31 PM >>>
[The e-mail server of the sender could not be verified (SPF Record)]

Assim, Hauke,

To comment a bit on Hauke's suggestion.

On 29/5/19 08:47, Hauke Petersen wrote:
> The general approach for porting CPUs in RIOT is to rely as much as 
> possible on shared code...

That's very important, try to take advantage of what's already in RIOT.
  > . All the specific CPU
> implementations have to provide, are their interrupt vector structure 
> (see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), 

Hauke, The SmartFusion is integrated is integrated into a FPGA, so the 
vectors can change depending on how one programs it (am I right, Assim?)

It would be highly desirable if he does not have to translate the 
automatically generated assembly file into C. Specially considering it 
contains some platform-specific code (I see something about eSRAM EDAC 
and ECC mempory).

I think this is the piece of code that introduces the dependency on vectors:

https://github.com/RIOT-OS/RIOT/blob/7e3c382547430fae0a81e4f44c64d23e18629549/makefiles/arch/cortexm.inc.mk#L138

See the UNDEF. I may be wrong here, but I believe it is to prevent the 
symbols being dropped.

What you can do is either:

- Provide an empty vectors.c (to make the build system happy) AND add 
startup_m2sxxx.o to the UNDEF.

- Add a rule to build vectors.o from startup_m2sxxx.S AND also make sure
startup_m2sxxx.o does not get built.

Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Lightweight Syslog Implementation

[Juan Ignacio Carrano]

Robin,

On 28/5/19 18:53, Robin wrote:
Only problem here is that syslog as implemented in gLibc 
expects a user to issue a call to openlog first. Maybe I can make the 
call to openlog implicit and thus make it compatible to both API‘s. 


The standard works in our favor here:
"The use of openlog() is optional" and " The use of closelog() is 
optional". We can have no-ops for both functions:


#define openlog(ident, option, facility) (void)((ident), (option), 
(facility))


Another solution could be to extend the log module with a bootstrap/init 
function which defaults to do nothing in most cases.




Should not be needed if we do what unix syslog does, initialize it on 
the first call to syslog() if necessary.


One problem with the generic LOG approach that comes to my mind is that 
it looks like a all or nothing approach.


I suggest the choice should not be between serial backend and syslog 
backend, but rather between serial backend (used for most simple 
applications) and IPC/message queue backend. At the end of the quie is 
the logic deciding how the packet should be sent.


An advantage of this approach is that is is also useful for serial-only 
loggers where one wants to ensure strings don't intermingle. Also the 
current implementation of uart logging inherits the blocking 
characteristics of the UART, meanings that logging blocks until the 
message has been sent.


Of course, most applications are fine with just writing directly to UART 
backend and having the queue by default would be overkill.


When I implement the syslog 
implementation as a log module it wouldn’t be possible anymore for the 
user to decide which logs should be shipped via syslog and which logs 
only should be send over serial line.


With a queue, the decision can be made according to the PID of the 
message sender. Or, even better, according to the facility value set by 
that thread in openlog().


BTW, there is an option in UNIX called LOG_CONS:

> LOG_CONS   Write directly to the system console if there is an 
error while sending to the system logger.


The more we discuss this topic, the more I'm convinced we cannot 
overlook it if we want RIOT to be practical for large-scale deployments.


Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT vectors for Smartfusion2 port

[Hauke Petersen]

Hi Ashim,

the LPC2387 is unfortunately a very bad example, as this CPU is not very 
well maintained and does not comply with the best practices of structure 
and style that newer CPUs in RIOT use.


The general approach for porting CPUs in RIOT is to rely as much as 
possible on shared code. Keeping this in mind, all the needed startup 
code, base linker scripts, ... etc, are implemented and provided by the 
shared `cpu/cortexm_common` code path. All the specific CPU 
implementations have to provide, are their interrupt vector structure 
(see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), their 
memory layout (see e.g. `cpu/sam0_common/Makefile.include`), their clock 
initialization code (see e.g. `cpu/samd21/cpu.c`), and of course there 
peripheral driver implementations (typically in a `periph` subdir).


So with this, all you need is to extract that information above from the 
vendor libraries and you should be good to go!


Cheers,
Hauke


On 5/28/19 5:04 PM, Juan Ignacio Carrano wrote:

Hi Ashim,

I assume you are basing your SmartFusion port on some existing CPU. If 
that's the case, it would be useful to know which one. Even better if 
you can link us to a publicly accessible repo.


I have tried including this file in the new cpu folder I created but 
get the following error when trying to make:
arm-none-eabi-gcc: error: 
/home/user/Desktop/SmartFusion2/testjig/riot/2019.04/examples/hello-world/bin/sf2-starter-kit/cpu/vectors.o: 
No such file or directory




The first question is why the build system is expecting to find 
vectors.o. Not all CPUs generate that file (in your case you would 
compile startup_m2sxxx.S into startup_m2sxxx.o) I believe the answer 
to this question lies in the CPU you started with.


For example: you mention the LPC2387. If you compile any example with
BOARD=msba2 (which uses that cpu) and look inside "bin/msba2/cpu" you 
will not find any vectors.o and that's OK.


How do I use the above file correctly in the RIOT port? Is there some 
configuration that should be changed to use the file properly or 
should I convert it to a vectors.c file? If so, how do I go about 
doing so?




AFAIK you should not need to convert anything, just place the .S file 
in your CPU directory, but without knowing the full contents of the 
dir it is hard to tell what is happening.


Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT vectors for Smartfusion2 port

[Juan Ignacio Carrano]

Assim, Hauke,

To comment a bit on Hauke's suggestion.

On 29/5/19 08:47, Hauke Petersen wrote:
The general approach for porting CPUs in RIOT is to rely as much as 
possible on shared code...


That's very important, try to take advantage of what's already in RIOT.
 > . All the specific CPU
implementations have to provide, are their interrupt vector structure 
(see e.g. `cpu/samd21/vectors.c` or `cpu/stm32f4/vectors.c`), 


Hauke, The SmartFusion is integrated is integrated into a FPGA, so the 
vectors can change depending on how one programs it (am I right, Assim?)


It would be highly desirable if he does not have to translate the 
automatically generated assembly file into C. Specially considering it 
contains some platform-specific code (I see something about eSRAM EDAC 
and ECC mempory).


I think this is the piece of code that introduces the dependency on vectors:

https://github.com/RIOT-OS/RIOT/blob/7e3c382547430fae0a81e4f44c64d23e18629549/makefiles/arch/cortexm.inc.mk#L138

See the UNDEF. I may be wrong here, but I believe it is to prevent the 
symbols being dropped.


What you can do is either:

- Provide an empty vectors.c (to make the build system happy) AND add 
startup_m2sxxx.o to the UNDEF.


- Add a rule to build vectors.o from startup_m2sxxx.S AND also make sure
startup_m2sxxx.o does not get built.

Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] How to properly use cortexm_sleep

[Robert Hartung]

Hey everyone,

let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the deepest mode possible.
Which mode is possible depends on the used periphs. For STM32 sleep was
long not possible, as PM_BLOCKER_INITIAL was initialized with 1 for each
mode, which resulted in never going to a sleep mode.
From what I can see is that it is still initialized with ones?
Nevertheless, to make us of it PM_BLOCKER_INITIAL should be initialized
with 0. All periph modules should then individually block the sleep
modes they can not operate in. For now the biggest problem was the
shell/uart, as it would always block any sleep modes.
An exception are some platforms, as they have a Uart which can wake them
up from sleep modes.

I have modified the atmega1284p implementation to make use of it [0] and
[1].

Best Regards
Robert

[0]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega1284p/periph/pm.c
[1]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega_common/periph/

On 28.05.19 20:01, Kees Bakker wrote:
> Nice,
> 
> Thanks for sharing
> 
> On 28-05-19 08:48, Oleg Artamonov wrote:
>> Hi.
>>
>> Yes, but for emergency reboots only.
>>  
>> Implementations:
>> https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c
>> and
>> https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c
>>  
>> For task scheduling on sleepy devices we use RTC-based timers with 1
>> ms resolution and 1 week max period
>> (https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis;
>> on STM32L, we use regular HW RTC with SSR register, on nRF52 —
>> "software" RTC implemented on top of HW RTT unit).
>>  
>> -- 
>> /Sincerely yours,/
>> /Oleg Artamonov/
>> /+7 (916) 631-34-90/
>> /www.unwds.com/ 
>>  
>>  
>>  
>> 27.05.2019, 21:57, "Kees Bakker" :
>>
>> Hey Oleg,
>>
>> Are you using the watchdog?
>>  
>> On 27-05-19 07:30, Oleg Artamonov wrote:
>>
>> Hi
>>  
>> We do. On STM32L0, STM32L1, nRF52, etc.
>>  
>> Checking for interrupt flags is absolutely useless here - 1)
>> WFI checks for any relevant interrupt flags, 2) interrupt
>> still can happen between check and WFI.
>>  
>> -- 
>> /Sincerely yours,/
>> /Oleg Artamonov/
>> /+7 (916) 631-34-90/
>> /www.unwds.com/ 
>>  
>>  
>>  
>> 26.05.2019, 18:40, "Kees Bakker" 
>> :
>>
>> Hey
>>
>> Is there anyone using cortexm_sleep for a real
>> application? And if
>> yes, would you want to share how exactly that's done?
>>
>> Let me say that I've never written a real application with
>> RIOT, but
>> I would like to. One of the important requirements is that
>> the app
>> must be in sleep (deep sleep) and only wake up to do some
>> work.
>> And another requirement is to use the watchdog.
>>
>> That said, I'm familiar with the following Arduino pseudo
>> code.
>>
>>  while (forever) {
>>  do stuff
>>
>>  disable interrupts
>>  if !certain condition
>>  __WFI();
>>  enable interrupts
>>  }
>>
>> That "certain condition" is mostly checking that no WDT or
>> RTC interrupt
>> occurred before disabling the interrupts. These interrupts
>> are handled
>> by ISR's and they set a flag. This is a fairly common
>> thing to do, I think.
>>
>> I don't see (or understand) how this can be achieved with
>> RIOT-OS and
>> cortexm_sleep. It is essential to check the condition
>> AFTER disabling the
>> interrupts.
>>
>> --
>> Kees Bakker
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>  
>>
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ,
>>
>> ___
>> devel mailing list
>> devel@riot-os.org 
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https

Re: [riot-devel] RIOT vectors for Smartfusion2 port

[Ashim Asharaph]

Dear Juan

The board is the sf2-starter-kit and the CPU is the m2s010, which contains a 
Cortex M3.


I have made a publicly accessible repo with all the code available at:
https://github.com/ashimasharaph/SmartFusion2_riot_port



I see now that the makefile in makefiles/arch/cortexm.inc.mk has the code


# Explicitly tell the linker to link the startup code.
#   Without this the interrupt vectors will not be linked correctly!
VECTORS_O ?= $(BINDIR)/cpu/vectors.o
ifeq ($(COMMON_STARTUP),)
export UNDEF += $(VECTORS_O)
endif


and the Makefile.include in the m2s_xxx cpu folder has:

include $(RIOTMAKE)/arch/cortexm.inc.mk



How should I go about removing that code and do I need to replace it with 
anything? Any help would be appreciated.


Kind regards
Ashim Asharaph





>>> Juan Ignacio Carrano  05/28/19 5:01 PM >>>
[The e-mail server of the sender could not be verified (SPF Record)]

Hi Ashim,

I assume you are basing your SmartFusion port on some existing CPU. If 
that's the case, it would be useful to know which one. Even better if 
you can link us to a publicly accessible repo.

> I have tried including this file in the new cpu folder I 
> created but get the following error when trying to make:
> arm-none-eabi-gcc: error: 
> /home/user/Desktop/SmartFusion2/testjig/riot/2019.04/examples/hello-world/bin/sf2-starter-kit/cpu/vectors.o:
>  
> No such file or directory
> 

The first question is why the build system is expecting to find 
vectors.o. Not all CPUs generate that file (in your case you would 
compile startup_m2sxxx.S into startup_m2sxxx.o) I believe the answer to 
this question lies in the CPU you started with.

For example: you mention the LPC2387. If you compile any example with
BOARD=msba2 (which uses that cpu) and look inside "bin/msba2/cpu" you 
will not find any vectors.o and that's OK.

> How do I use the above file correctly in the RIOT port? Is there some 
> configuration that should be changed to use the file properly or should 
> I convert it to a vectors.c file? If so, how do I go about doing so?
> 

AFAIK you should not need to convert anything, just place the .S file in 
your CPU directory, but without knowing the full contents of the dir it 
is hard to tell what is happening.

Regards,

Juan.
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel