tmedicci commented on PR #8926:
URL: https://github.com/apache/nuttx/pull/8926#issuecomment-1492036259

   > I tested the above modification after updating to arm-none-eabi-gcc 12.2.1 
and now the event is happening even removing the delay in the alarm_main.c:
   > 
   > ```
   > NuttShell (NSH) NuttX-12.0.0
   > nsh> ?
   > help usage:  help [-v] [<cmd>]
   > 
   >     .         cat       df        free      mount     rmdir     truncate  
   >     [         cd        dmesg     help      mv        set       uname     
   >     ?         cp        echo      hexdump   printf    sleep     umount    
   >     alias     cmp       env       kill      ps        source    unset     
   >     unalias   dirname   exec      ls        pwd       test      uptime    
   >     basename  date      exit      mkdir     reboot    time      usleep    
   >     break     dd        false     mkrd      rm        true      xd        
   > 
   > Builtin Apps:
   >     alarm    hello    nsh      ostest   sh       smp      taskset  
   > nsh> alarm 10
   > alarm_daemon started
   > alarm_daemon: Running
   > Opening /dev/rtc0
   > Alarm 0 set in 10 seconds
   > nsh> 
   > nsh> ps
   >   PID GROUP CPU PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK        
   STACK COMMAND
   >     0     0   0   0 FIFO     Kthread N-- Assigned           
0000000000000000 001000 CPU0 IDLE
   >     1     1   1   0 FIFO     Kthread N-- Assigned           
0000000000000000 001000 CPU1 IDLE
   >     3     3 --- 200 RR       Task    --- Waiting  MQ empty  
0000000000000000 000976 cxd56_pm_tk
   >     4     4   0 100 RR       Task    --- Running            
0000000000000000 002000 spresense_n
   >     6     6   1 100 RR       Task    --- Running            
0000000000000000 002000 alarm_daemn
   > nsh> alarm_daemon: alarm 0 received
   > 
   > nsh>
   > ```
   
   Just confirming: 
   
   1) Did you apply the `EXAMPLES_APP` patch? (removing `usleep` to force the 
other core to run the `alarm_daemon`?)
   2) Did you use the Spresense board, right? (armv7-m)
   3) Is this the result after applying the same kind of approaching at 
`nuttx/arch/arm/src/armv7-m/arm_schedulesigaction.c`?
   4) Using older versions of GCC, was the signal delivered?
   5) Considering the newest version of the compiler, prior to applying this 
patch, does the firmware crash?
     
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to