Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release

[Duo Zhang]

We have enough binding votes from IPMC now, so let's close the vote and
finish the release?

Thanks.

张铎(Duo Zhang)  于2021年5月20日周四 下午4:17写道：

> As Nathan Hartman is an ASF member now, you could ask to join the IPMC,
> then we could have 2 binding votes when releasing...
>
> And let me contact our champion, he has been really busy recently...
>
> Thanks.
>
> Byron Ellacott  于2021年5月8日周六 下午1:28写道：
>
>> +1 with caveat that I need to backport the compiler patch.
>>
>> Toolchain:
>> clang version 13.0.0 (g...@github.com:jacobly0/llvm-project.git
>> ff3f5b865edbac826fdd251f810da833dda775de)
>> Target: ez80-none-unknown-elf
>> Thread model: posix
>>
>>  - LICENSE, NOTICE, README.md, DISCLAIMER-WIP present in both
>> repositories.
>>  - Build for eZ80 using commit ID 9d4742af00 backported from master, plus
>> patch for Z80 ELF support (PR to happen when tested adequately)
>>  - Build size is 253,610 text (down from 257,713 bytes for RC0), 197 bytes
>> in data (unchanged from RC0)
>>
>> NuttShell (NSH) NuttX-10.1.0
>> nsh> free
>>  total   used   freelargest
>> Umem:   253856  66272 187584 184736
>>
>> --
>> bje
>>
>> On Tue, May 4, 2021 at 1:25 AM Alan Carvalho de Assis 
>> wrote:
>>
>> > Hi Everyone, please submit some information when you test it:
>> >
>> > - Used toolchain: i.e. last line of "gcc -v" is enough
>> > - ELF nuttx size: i.e. "arm-none-eabi-size nuttx"
>> > - Result of internal nsh free command.
>> >
>> > It will help us to track the size increase from a release to another.
>> >
>> > BR,
>> >
>> > Alan
>> >
>> > On 5/3/21, alin.jerpe...@sony.com  wrote:
>> > > Hello all,
>> > >
>> > > This is the latest tarball
>> > >
>> > > I am sorry for the confusion
>> > >
>> > > Thanks
>> > > Alin
>> > >
>> > >
>> > > -Original Message-
>> > > From: Nathan Hartman 
>> > > Sent: den 3 maj 2021 17:14
>> > > To: dev@nuttx.apache.org
>> > > Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release
>> > >
>> > > On Mon, May 3, 2021 at 1:22 AM Alin Jerpelea 
>> wrote:
>> > >>
>> > >> Hello all,
>> > >> Apache NuttX (Incubating) 10.1.0 RC1 has been staged under [1] and
>> > >> it's time to vote on accepting it for release. If approved we will
>> > >> seek final release approval from the IPMC. Voting will be open for
>> 72hr.
>> > >>
>> > >> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>> > >> are required to pass.
>> > >>
>> > >> The Apache requirements for approving a release can be found here [3]
>> > >> "Before voting +1 [P]PMC members are required to download the signed
>> > >> source code package, compile it as provided, and test the resulting
>> > >> executable on their own platform, along with also verifying that the
>> > >> package meets the requirements of the ASF policy on releases."
>> > >>
>> > >> A document to walk through some of this process has been published on
>> > >> our project wiki and can be found here [4].
>> > >>
>> > >> [ ] +1 accept (indicate what you validated - e.g. performed the
>> non-RM
>> > >> items in [4]) [ ] -1 reject (explanation required)
>> > >>
>> > >> Thank you all,
>> > >> Alin Jerpelea
>> > >>
>> > >> SCM Information:
>> > >>   Release tag: nuttx-10.1.0-RC1
>> > >>   Hash for the release incubating-nuttx tag:
>> > >> 3130ff691e386934eb276587a24d1efacf3bb30b
>> > >>   Hash for the release incubating-nuttx-apps tag:
>> > >> 4348d91d1356335483089c3865282d80f13bedcd
>> > >>
>> > >> [1]
>> > >>
>> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc
>> > >>
>> ubator/nuttx/10.1.0-RC1/__;!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4
>> > >> HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBF0cM9oFQ$
>> > >> [2]
>> https://urldefense.com/v3/__https://raw.githubusercontent.com/apach
>> > >>
>> e/incubator-nuttx/nuttx-10.1.0-RC1/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!u
>> > >> 7bO_5TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBELDkRTXA$
>> > >> [3]
>> > >>
>> https://urldefense.com/v3/__https://www.apache.org/dev/release.html*ap
>> > >>
>> proving-a-release__;Iw!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4HI0T2
>> > >> TqnSm836Wse15R0SGxhUdWk3viAcBGKE_xsSw$
>> > >> [4]
>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/dis
>> > >>
>> play/NUTTX/Validating*a*staged*Release__;Kysr!!JmoZiZGBv3RvKRSx!u7bO_5
>> > >> TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBE_QwknXQ$
>> > >
>> > >
>> > > Just to be sure I don't misunderstand, this is the latest release
>> > candidate
>> > > to be tested now?
>> > >
>> > > In the future, I recommend to increment the -RC numbers each time
>> there
>> > are
>> > > new tarballs, to avoid any potential confusion.
>> > >
>> > > If this is indeed the latest RC, I'll try to test it today.
>> > >
>> > > Thanks for all your hard work!!
>> > >
>> > > Cheers,
>> > > Nathan
>> > >
>> >
>>
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Gregory Nutt]

The failure doesn't seem to have anything to do with nimBLE.  The nimble 
app is not running at all!


Put a breakpoint on nimble_main().  I doubt that you ever get there.  
But I don't know why.


The error report is probably misleading too...  I seem to recall that 
that there is an issue that the NSH error reported is always "command 
not found" even if some other error occurs.  It does mean that NSH could 
not run the built-in command, but it does not necessarily mean that the 
built-in command was not found.


On 5/25/2021 4:51 PM, Alan Carvalho de Assis wrote:

Hi Matias and Miguel,

I just tried nimble on nrf52832-mdk board without success:

$ ./tools/configure.sh nrf52832-mdk:sdc
$ make

It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
was about 314944 bytes.

When I drop this file inside DAPLINK disk it tries to flash and create
the file FAIL.TXT with this content:

"The hex file cannot be decoded. Checksum calculation failure occurred."

Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
and after copying the nuttx.hex to DAPLINK disk the error disappeared.

Accessing the nsh terminal I can see the nimble binary, but it is not running:

NuttShell (NSH) NuttX-10.1.0-RC1
nsh> ?
help usage:  help [-v] []

   . cdecho  hexdump   mkdir pssource
  unset
   [ cpexec  ifconfig  mkfatfs   pwd   test
  usleep
   ? cmp   exit  ifdownmkrd  rmtime
  xd
   basename  dirname   false ifup  mount rmdir true
   break ddfree  kill  mvset   uname
   cat   dfhelp  lsnslookup  sleep umount

Builtin Apps:
   nimble  sh  nsh
nsh> nimble
nsh: nimble: command not found
nsh> ifconfig
bnep0   Link encap:UNSPEC at UP

nsh> nimble -h
nsh: nimble: command not found
nsh> nimble
nsh: nimble: command not found
nsh>

Initially I thought it was caused by recent update of the nimble stack
on NuttX, but I moved to a commit previous to that update and still
facing same error.

Matias, do you think it could be some issue with my crosscompiler?

I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi package:

gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
277599] (15:9-2019-q4-0ubuntu1)

Thank you very much!

BR,

Alan

On 5/25/21, Miguel Wisintainer  wrote:

Matias

Me and Alan will investigate!

Thank you so much!

Enviado do Email para
Windows 10

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Alan Carvalho de Assis]

Seams specific to nimble:

NuttShell (NSH) NuttX-10.1.0-RC1
nsh> ?
help usage:  help [-v] []

  . cdecho  hexdump   mkdir pssource
 unset
  [ cpexec  ifconfig  mkfatfs   pwd   test
 usleep
  ? cmp   exit  ifdownmkrd  rmtime
 xd
  basename  dirname   false ifup  mount rmdir true
  break ddfree  kill  mvset   uname
  cat   dfhelp  lsnslookup  sleep umount

Builtin Apps:
  nimble  sh  hello   nsh
nsh> nimble
nsh: nimble: command not found
nsh> hello
Hello, World!!
nsh> ifconfig
bnep0   Link encap:UNSPEC at UP

nsh>



On 5/25/21, Matias N.  wrote:
> I can try tomorrow. Maybe you can try enabling another app and see if you
> can run it. The "command not found" seems unrelated to nimBLE.
>
> On Tue, May 25, 2021, at 20:26, Alan Carvalho de Assis wrote:
>> Hi Matias,
>>
>> No, this is not the issue:
>>
>> Symbol: BUILTIN [=y]
>> Symbol: NSH_BUILTIN_APPS [=y]
>>
>> As you saw I used your "nrf52832-mdk:sdc" and you enabled it there.
>>
>> Is it working for you?
>>
>> BR,
>>
>> Alan
>>
>> On 5/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
>> > The problem with apps listed but not being able to run them is a common
>> > error (something worth adding
>> > to the FAQ) I faced many times. It is due to not having support for
>> > BUILTIN
>> > apps on menuconfig (you need general
>> > support as well as enabling NSH BUILTIN support). It is strange that
>> > the
>> > config is not functional though.
>> >
>> > Best,
>> > Matias
>> >
>> > On Tue, May 25, 2021, at 19:51, Alan Carvalho de Assis wrote:
>> >> Hi Matias and Miguel,
>> >>
>> >> I just tried nimble on nrf52832-mdk board without success:
>> >>
>> >> $ ./tools/configure.sh nrf52832-mdk:sdc
>> >> $ make
>> >>
>> >> It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
>> >> was about 314944 bytes.
>> >>
>> >> When I drop this file inside DAPLINK disk it tries to flash and create
>> >> the file FAIL.TXT with this content:
>> >>
>> >> "The hex file cannot be decoded. Checksum calculation failure
>> >> occurred."
>> >>
>> >> Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
>> >> and after copying the nuttx.hex to DAPLINK disk the error disappeared.
>> >>
>> >> Accessing the nsh terminal I can see the nimble binary, but it is not
>> >> running:
>> >>
>> >> NuttShell (NSH) NuttX-10.1.0-RC1
>> >> nsh> ?
>> >> help usage:  help [-v] []
>> >>
>> >>   . cdecho  hexdump   mkdir pssource
>> >> unset
>> >>   [ cpexec  ifconfig  mkfatfs   pwd   test
>> >> usleep
>> >>   ? cmp   exit  ifdownmkrd  rmtime
>> >> xd
>> >>   basename  dirname   false ifup  mount rmdir true
>> >>   break ddfree  kill  mvset   uname
>> >>   cat   dfhelp  lsnslookup  sleep umount
>> >>
>> >> Builtin Apps:
>> >>   nimble  sh  nsh
>> >> nsh> nimble
>> >> nsh: nimble: command not found
>> >> nsh> ifconfig
>> >> bnep0   Link encap:UNSPEC at UP
>> >>
>> >> nsh> nimble -h
>> >> nsh: nimble: command not found
>> >> nsh> nimble
>> >> nsh: nimble: command not found
>> >> nsh>
>> >>
>> >> Initially I thought it was caused by recent update of the nimble stack
>> >> on NuttX, but I moved to a commit previous to that update and still
>> >> facing same error.
>> >>
>> >> Matias, do you think it could be some issue with my crosscompiler?
>> >>
>> >> I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi
>> >> package:
>> >>
>> >> gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
>> >> 277599] (15:9-2019-q4-0ubuntu1)
>> >>
>> >> Thank you very much!
>> >>
>> >> BR,
>> >>
>> >> Alan
>> >>
>> >> On 5/25/21, Miguel Wisintainer > >> 
>> >> > wrote:
>> >> > Matias
>> >> >
>> >> > Me and Alan will investigate!
>> >> >
>> >> > Thank you so much!
>> >> >
>> >> > Enviado do Email
>> >> > para
>> >> > Windows 10
>> >> >
>> >> >
>> >>
>> >
>>
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Matias N.]

I can try tomorrow. Maybe you can try enabling another app and see if you can 
run it. The "command not found" seems unrelated to nimBLE.

On Tue, May 25, 2021, at 20:26, Alan Carvalho de Assis wrote:
> Hi Matias,
> 
> No, this is not the issue:
> 
> Symbol: BUILTIN [=y]
> Symbol: NSH_BUILTIN_APPS [=y]
> 
> As you saw I used your "nrf52832-mdk:sdc" and you enabled it there.
> 
> Is it working for you?
> 
> BR,
> 
> Alan
> 
> On 5/25/21, Matias N. mailto:matias%40imap.cc>> wrote:
> > The problem with apps listed but not being able to run them is a common
> > error (something worth adding
> > to the FAQ) I faced many times. It is due to not having support for BUILTIN
> > apps on menuconfig (you need general
> > support as well as enabling NSH BUILTIN support). It is strange that the
> > config is not functional though.
> >
> > Best,
> > Matias
> >
> > On Tue, May 25, 2021, at 19:51, Alan Carvalho de Assis wrote:
> >> Hi Matias and Miguel,
> >>
> >> I just tried nimble on nrf52832-mdk board without success:
> >>
> >> $ ./tools/configure.sh nrf52832-mdk:sdc
> >> $ make
> >>
> >> It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
> >> was about 314944 bytes.
> >>
> >> When I drop this file inside DAPLINK disk it tries to flash and create
> >> the file FAIL.TXT with this content:
> >>
> >> "The hex file cannot be decoded. Checksum calculation failure occurred."
> >>
> >> Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
> >> and after copying the nuttx.hex to DAPLINK disk the error disappeared.
> >>
> >> Accessing the nsh terminal I can see the nimble binary, but it is not
> >> running:
> >>
> >> NuttShell (NSH) NuttX-10.1.0-RC1
> >> nsh> ?
> >> help usage:  help [-v] []
> >>
> >>   . cdecho  hexdump   mkdir pssource
> >> unset
> >>   [ cpexec  ifconfig  mkfatfs   pwd   test
> >> usleep
> >>   ? cmp   exit  ifdownmkrd  rmtime
> >> xd
> >>   basename  dirname   false ifup  mount rmdir true
> >>   break ddfree  kill  mvset   uname
> >>   cat   dfhelp  lsnslookup  sleep umount
> >>
> >> Builtin Apps:
> >>   nimble  sh  nsh
> >> nsh> nimble
> >> nsh: nimble: command not found
> >> nsh> ifconfig
> >> bnep0   Link encap:UNSPEC at UP
> >>
> >> nsh> nimble -h
> >> nsh: nimble: command not found
> >> nsh> nimble
> >> nsh: nimble: command not found
> >> nsh>
> >>
> >> Initially I thought it was caused by recent update of the nimble stack
> >> on NuttX, but I moved to a commit previous to that update and still
> >> facing same error.
> >>
> >> Matias, do you think it could be some issue with my crosscompiler?
> >>
> >> I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi
> >> package:
> >>
> >> gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
> >> 277599] (15:9-2019-q4-0ubuntu1)
> >>
> >> Thank you very much!
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 5/25/21, Miguel Wisintainer  >> 
> >> > wrote:
> >> > Matias
> >> >
> >> > Me and Alan will investigate!
> >> >
> >> > Thank you so much!
> >> >
> >> > Enviado do Email para
> >> > Windows 10
> >> >
> >> >
> >>
> >
> 

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Alan Carvalho de Assis]

Hi Matias,

No, this is not the issue:

Symbol: BUILTIN [=y]
Symbol: NSH_BUILTIN_APPS [=y]

As you saw I used your "nrf52832-mdk:sdc" and you enabled it there.

Is it working for you?

BR,

Alan

On 5/25/21, Matias N.  wrote:
> The problem with apps listed but not being able to run them is a common
> error (something worth adding
> to the FAQ) I faced many times. It is due to not having support for BUILTIN
> apps on menuconfig (you need general
> support as well as enabling NSH BUILTIN support). It is strange that the
> config is not functional though.
>
> Best,
> Matias
>
> On Tue, May 25, 2021, at 19:51, Alan Carvalho de Assis wrote:
>> Hi Matias and Miguel,
>>
>> I just tried nimble on nrf52832-mdk board without success:
>>
>> $ ./tools/configure.sh nrf52832-mdk:sdc
>> $ make
>>
>> It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
>> was about 314944 bytes.
>>
>> When I drop this file inside DAPLINK disk it tries to flash and create
>> the file FAIL.TXT with this content:
>>
>> "The hex file cannot be decoded. Checksum calculation failure occurred."
>>
>> Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
>> and after copying the nuttx.hex to DAPLINK disk the error disappeared.
>>
>> Accessing the nsh terminal I can see the nimble binary, but it is not
>> running:
>>
>> NuttShell (NSH) NuttX-10.1.0-RC1
>> nsh> ?
>> help usage:  help [-v] []
>>
>>   . cdecho  hexdump   mkdir pssource
>> unset
>>   [ cpexec  ifconfig  mkfatfs   pwd   test
>> usleep
>>   ? cmp   exit  ifdownmkrd  rmtime
>> xd
>>   basename  dirname   false ifup  mount rmdir true
>>   break ddfree  kill  mvset   uname
>>   cat   dfhelp  lsnslookup  sleep umount
>>
>> Builtin Apps:
>>   nimble  sh  nsh
>> nsh> nimble
>> nsh: nimble: command not found
>> nsh> ifconfig
>> bnep0   Link encap:UNSPEC at UP
>>
>> nsh> nimble -h
>> nsh: nimble: command not found
>> nsh> nimble
>> nsh: nimble: command not found
>> nsh>
>>
>> Initially I thought it was caused by recent update of the nimble stack
>> on NuttX, but I moved to a commit previous to that update and still
>> facing same error.
>>
>> Matias, do you think it could be some issue with my crosscompiler?
>>
>> I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi
>> package:
>>
>> gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
>> 277599] (15:9-2019-q4-0ubuntu1)
>>
>> Thank you very much!
>>
>> BR,
>>
>> Alan
>>
>> On 5/25/21, Miguel Wisintainer > > wrote:
>> > Matias
>> >
>> > Me and Alan will investigate!
>> >
>> > Thank you so much!
>> >
>> > Enviado do Email para
>> > Windows 10
>> >
>> >
>>
>

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Matias N.]

The problem with apps listed but not being able to run them is a common error 
(something worth adding
to the FAQ) I faced many times. It is due to not having support for BUILTIN 
apps on menuconfig (you need general
support as well as enabling NSH BUILTIN support). It is strange that the config 
is not functional though.

Best,
Matias

On Tue, May 25, 2021, at 19:51, Alan Carvalho de Assis wrote:
> Hi Matias and Miguel,
> 
> I just tried nimble on nrf52832-mdk board without success:
> 
> $ ./tools/configure.sh nrf52832-mdk:sdc
> $ make
> 
> It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
> was about 314944 bytes.
> 
> When I drop this file inside DAPLINK disk it tries to flash and create
> the file FAIL.TXT with this content:
> 
> "The hex file cannot be decoded. Checksum calculation failure occurred."
> 
> Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
> and after copying the nuttx.hex to DAPLINK disk the error disappeared.
> 
> Accessing the nsh terminal I can see the nimble binary, but it is not running:
> 
> NuttShell (NSH) NuttX-10.1.0-RC1
> nsh> ?
> help usage:  help [-v] []
> 
>   . cdecho  hexdump   mkdir pssource
> unset
>   [ cpexec  ifconfig  mkfatfs   pwd   test
> usleep
>   ? cmp   exit  ifdownmkrd  rmtime
> xd
>   basename  dirname   false ifup  mount rmdir true
>   break ddfree  kill  mvset   uname
>   cat   dfhelp  lsnslookup  sleep umount
> 
> Builtin Apps:
>   nimble  sh  nsh
> nsh> nimble
> nsh: nimble: command not found
> nsh> ifconfig
> bnep0   Link encap:UNSPEC at UP
> 
> nsh> nimble -h
> nsh: nimble: command not found
> nsh> nimble
> nsh: nimble: command not found
> nsh>
> 
> Initially I thought it was caused by recent update of the nimble stack
> on NuttX, but I moved to a commit previous to that update and still
> facing same error.
> 
> Matias, do you think it could be some issue with my crosscompiler?
> 
> I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi package:
> 
> gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
> 277599] (15:9-2019-q4-0ubuntu1)
> 
> Thank you very much!
> 
> BR,
> 
> Alan
> 
> On 5/25/21, Miguel Wisintainer  > wrote:
> > Matias
> >
> > Me and Alan will investigate!
> >
> > Thank you so much!
> >
> > Enviado do Email para
> > Windows 10
> >
> >
> 

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Alan Carvalho de Assis]

Hi Matias and Miguel,

I just tried nimble on nrf52832-mdk board without success:

$ ./tools/configure.sh nrf52832-mdk:sdc
$ make

It downloaded and compiled nimble for NuttX correctly, the nuttx.bin
was about 314944 bytes.

When I drop this file inside DAPLINK disk it tries to flash and create
the file FAIL.TXT with this content:

"The hex file cannot be decoded. Checksum calculation failure occurred."

Then I ran "make menuconfig" and enabled the "Intel HEX binary format"
and after copying the nuttx.hex to DAPLINK disk the error disappeared.

Accessing the nsh terminal I can see the nimble binary, but it is not running:

NuttShell (NSH) NuttX-10.1.0-RC1
nsh> ?
help usage:  help [-v] []

  . cdecho  hexdump   mkdir pssource
 unset
  [ cpexec  ifconfig  mkfatfs   pwd   test
 usleep
  ? cmp   exit  ifdownmkrd  rmtime
 xd
  basename  dirname   false ifup  mount rmdir true
  break ddfree  kill  mvset   uname
  cat   dfhelp  lsnslookup  sleep umount

Builtin Apps:
  nimble  sh  nsh
nsh> nimble
nsh: nimble: command not found
nsh> ifconfig
bnep0   Link encap:UNSPEC at UP

nsh> nimble -h
nsh: nimble: command not found
nsh> nimble
nsh: nimble: command not found
nsh>

Initially I thought it was caused by recent update of the nimble stack
on NuttX, but I moved to a commit previous to that update and still
facing same error.

Matias, do you think it could be some issue with my crosscompiler?

I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi package:

gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
277599] (15:9-2019-q4-0ubuntu1)

Thank you very much!

BR,

Alan

On 5/25/21, Miguel Wisintainer  wrote:
> Matias
>
> Me and Alan will investigate!
>
> Thank you so much!
>
> Enviado do Email para
> Windows 10
>
>

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet 
wrote:

> Back to the business
> >> After this we managed to recompile our project using the latest NuttX
> >> sources, but it fails when trying to init the PHY irq on our STM32F427
> >> board: We get "unexpected IRQ".
> >>
> >> Yes I know that's pretty vague :-)
> >>
> >> Is there anything obvious I should have been careful with in this
> >> domain, before I dig the jtag probe to fix it (tomorrow) ?
> > I would first start by looking through the Release Notes between v7.30
> > and v10.1. Many big improvements and bug fixes happened and some of
> > them are mentioned in Compatibility Concerns along with some changes
> > you might need to make to configuration etc.
> >
> > Also another thing you can try: Has this board and PHY worked
> > correctly with v7.30? If so, you can bisect and with very few tests
> > (I'm guessing fewer than 20) find the exact commit that broke it.
>
> Release notes are hard to read but I did not find anything special about
> phy interrupts.
>
> Note that it may not be the phy interrupt. Here is my log:
>
> stm32_netinitialize: Enabling PHY power
> stm32_netinitialize: PHY reset...
> stm32_netinitialize: PHY reset done.
> stm32_netinitialize: Configuring PHY int
> F
> irq_unexpected_isr: ERROR irq: 3
> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> up_registerdump: R0: 0001 2000737c c0f2 08000101 
>   200073c8
> up_registerdump: R8:     
> 200073c8 080126ad 080126f8
> up_registerdump: xPSR: 2100 PRIMASK:  CONTROL: 
> up_registerdump: EXC_RETURN: fff9
>
> A lot of OS initialization things happen at the point, marked by the
> letter F.
>
> It seems that an unexpected IRQ happens in this interval, around the
> time the filesystem is initialized. The backtrace goes down to memory
> allocation routines through the initialization of the root inode.
>
> My guess is that AN external IRQ is triggered (possibly not the PHY IRQ)
> but the ISR handler for that one is not ready yet. I will add debug
> messages.
>
>
> I would expect that situation to be a simple NOP, but it seems that
> undefined handlers are set to this function "irq_unexpected_isr"
>
> Is that a new behaviour? a default config that I did not set properly
> when porting our old defconfig?
>
> Sebastien
>
> >
> > Nathan
>

Did you try disabling the PHY (or networking) in Kconfig to see if removing
it from the build will eliminate the hardfault?

Have you seen this about hardfault debugging:
https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=139629445#content/view/139629445

Nathan

Re: CAN example crashes

[Tim Hardisty]

On 07/05/2021 17:48, Tim wrote:

Hi,

  


SAMA5D27 (custom board) - trying to complete the port and also check that
the CAN interface works on the board, so I'm trying to use the CAN example
app



As per my other thread, Linux+VS Code+Segger all up and running so I can 
see what's going on now.


Found an error in sam_can.c for sama5 which was why it was crashing - 
have fixed and will do the necessary PR in due course.


However, the main problem is that the sama5 board files all use "can" 
but it should be "mcan"...so all the register addresses and possibly 
functions/methods are wrong :(


Before I attempt to rework it to use mcan, has anyone actually got 
Nuttx+CAN working on a sama5? It could save me loads if work if so!!??

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Gregory Nutt]

irq_unexpected_isr: ERROR irq: 3

...
My guess is that AN external IRQ is triggered (possibly not the PHY 
IRQ) but the ISR handler for that one is not ready yet. I will add 
debug messages.

IRQ 3 is a Hardfault, not an external IRQ or peripheral interrupt.
I would expect that situation to be a simple NOP, but it seems that 
undefined handlers are set to this function "irq_unexpected_isr"


Initially all interrupts vector to irq_unexpected_isr() but that is 
fixed early in irq_initialize() when the hard fault handler is attached 
to IRQ 2.  Prior to that, the hard fault would be given to 
irq_unexpected_isr(), although I don't think the serial driver has been 
initialized at that point either.

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

Back to the business

After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.


Release notes are hard to read but I did not find anything special about 
phy interrupts.


Note that it may not be the phy interrupt. Here is my log:

stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101  
  200073c8
up_registerdump: R8:      
200073c8 080126ad 080126f8

up_registerdump: xPSR: 2100 PRIMASK:  CONTROL: 
up_registerdump: EXC_RETURN: fff9

A lot of OS initialization things happen at the point, marked by the 
letter F.


It seems that an unexpected IRQ happens in this interval, around the 
time the filesystem is initialized. The backtrace goes down to memory 
allocation routines through the initialization of the root inode.


My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) 
but the ISR handler for that one is not ready yet. I will add debug 
messages.



I would expect that situation to be a simple NOP, but it seems that 
undefined handlers are set to this function "irq_unexpected_isr"


Is that a new behaviour? a default config that I did not set properly 
when porting our old defconfig?


Sebastien



Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Tue, May 25, 2021 at 10:22 AM Sebastien Lorquet  wrote:
>
> it will be easier next time.

Yes the workflow of git in general is a lot of steps to do a simple thing.

If you'd like to, you can still send patches to the mailing list. Just
please remember to name the file with ".txt" extension or the mailing
list will drop it. If you send a patch rather than a PR, someone will
convert it into a PR on GitHub, because we don't commit directly to
the repository anymore. It's part of taking the burden off of Greg and
allowing the community to split the work.

You can keep a fork of NuttX in your GitHub; then you won't need to
fork it again. You just need to remember to create a branch each time
you want to make a PR, because if you create the changes on master
then you'll end up having to delete your fork and then make a new
fork. Also it's not possible to have multiple forks of the same repo
in one GitHub account.

Note that if you want to keep your fork in GitHub, it will get
out-of-date with NuttX's repo, but you can bring it up-to-date with
something like:

Add the official repo as a remote called "upstream":
$ git remote add upstream https://github.com/apache/incubator-nuttx.git

Fetch new commits from there:
$ git fetch upstream

Make sure you're on your master branch:
$ git checkout master

Rebase your master branch to upstream/master. Assuming you haven't
made any commits on your master branch, this shouldn't have to do
anything:
$ git rebase upstream/master

Then push it back to GitHub:
$ git push origin

A lot of steps. :-) (But much faster than deleting the fork and
forking again.) This won't sync your fork with things like new tags
that are created upstream. There are other git incantations for that,
which I can't remember right now.

> Does any of the 21 queued test that I see waiting in github enable this
> driver?

I don't know the answer to that, but...

> Because if they dont (which I suspect, hence this typo) these tests are
> useless.

...we have had discussions about trying to make the pre-checks smarter
about what they check in the future.

Thanks again,
Nathan

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Miguel Wisintainer]

Matias

Me and Alan will investigate!

Thank you so much!

Enviado do Email para Windows 10

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

it will be easier next time.


Does any of the 21 queued test that I see waiting in github enable this 
driver?


Because if they dont (which I suspect, hence this typo) these tests are 
useless.


Sebastien

Le 25/05/2021 à 16:17, Sebastien Lorquet a écrit :
No, the workflow is very clear, the pull request model is a defacto 
standard that works everywhere.


But it is heavy for trivial changes. fork, mess with remotes, make a 
branch, forget to change the git config --local user.name, push, deal 
with github and my ssh agent messing with multiple ssh keys for 
different github users, etc etc and then wait for the CI to build 
megabytes of useless tests just for an obvious typo.


It was just easier to send a patch inline and have Greg merge that 
immediately. I was never happy with this change and there is no reason 
to feel better now. But there is no way back now.Just less 
contributions from me.


Sebastien

Le 25/05/2021 à 16:11, Nathan Hartman a écrit :
On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet 
 wrote:

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Thanks so much for doing that!

Regarding the process, did you have any difficulty, i.e., anything
that should be improved in our docs explaining the workflow?

Cheers,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

No, the workflow is very clear, the pull request model is a defacto 
standard that works everywhere.


But it is heavy for trivial changes. fork, mess with remotes, make a 
branch, forget to change the git config --local user.name, push, deal 
with github and my ssh agent messing with multiple ssh keys for 
different github users, etc etc and then wait for the CI to build 
megabytes of useless tests just for an obvious typo.


It was just easier to send a patch inline and have Greg merge that 
immediately. I was never happy with this change and there is no reason 
to feel better now. But there is no way back now.Just less contributions 
from me.


Sebastien

Le 25/05/2021 à 16:11, Nathan Hartman a écrit :

On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet  wrote:

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Thanks so much for doing that!

Regarding the process, did you have any difficulty, i.e., anything
that should be improved in our docs explaining the workflow?

Cheers,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet  wrote:
>
> done, what a process for a 7-character change...
>
> The PHY and cable detection worked perfectly fine in our project.
>
> Sebastien

Thanks so much for doing that!

Regarding the process, did you have any difficulty, i.e., anything
that should be improved in our docs explaining the workflow?

Cheers,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Le 24/05/2021 à 23:04, Nathan Hartman a écrit :

On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet  wrote:

Hello,

There is a typo in the PCA9555 driver at line 817:
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
CONFIG_PCA9555_INT_NCALLBACKS.

Good catch! Please feel free to open a PR.


After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.

Nathan

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Matias N.]

Hi Miguel,
from the looks of it, it is a problem with NuttX's Bluetooth host-layer. 
There's an unhandled opcode which corresponds to "scan enable", which is not 
being recognized when the controller sends "command complete".

In my case I used nimBLE for host layer which works well. You can try to 
reproduce nrf52832-mdk's sdc config which AFAIK is configured to use nimBLE.
I know others use other stacks but I'm not sure which one.

Best,
Matias

On Sun, May 23, 2021, at 19:01, Miguel Wisintainer wrote:
> 
> 
> 
> Hello Brennan
> 
> Plans changed, i had spent a lot of time today on NRF52832 then i suspect 
> that should be a Softdevice Version (132)
> Then i ported the NRF52840 and repeated all the process, and finally that 
> error was removed.
> Look the boot
> 
> ABCDEG
> bt_initialize: btdev 0x47384
> bt_hci_cmd_create: opcode 0c03 param_len 0
> bt_buf_alloc: buf 0x20002c40 type 0 reserve 0
> bt_hci_cmd_create: buf 0x20002c40
> bt_buf_extend: buf 0x20002c40 len 3
> bt_hci_cmd_send_sync: opcode 0c03 len 3
> hci_tx_kthread: started
> bt_buf_addref: buf 0x20002c40 (old) ref 1 type 0
> hci_tx_kthread: Sending command 0c03 buf 0x20002c40 to driver
> bt_hci_send: passing CMD 3075 to softdevice
> bt_buf_release: buf 0x20002c40 ref 2 type 0
> bt_buf_release: Remaining references: 1
> on_hci: received CMD_COMPLETE from softdevice (opcode: 3075, status: 0x3)
> bt_buf_alloc: buf 0x20002c28 type 1 reserve 1
> bt_buf_extend: buf 0x20002c28 len 6
> bt_hci_receive: buf 0x20002c28 len 6
> priority_rx_work: list 0x20002c64
> priority_rx_work: buf 0x20002c28 type 1 len 6
> bt_buf_consume: buf 0x20002c28 len 2
> hci_cmd_complete: opcode 0c03
> bt_buf_consume: buf 0x20002c28 len 3
> hci_reset_complete: status 0
> bt_buf_addref: buf 0x20002c28 (old) ref 1 type 1
> bt_buf_release: buf 0x20002c40 ref 1 type 0
> bt_buf_release: Buffer freed: 0x20002c40
> bt_buf_release: buf 0x20002c28 ref 2 type 1
> bt_buf_release: Remaining references: 1
> bt_buf_release: buf 0x20002c40 ref 0 type 0
> bt_buf_release: Remaining references: 255
> bt_buf_release: buf 0x20002c28 ref 1 type 1
> bt_buf_release: Buffer freed: 0x20002c28
> bt_hci_cmd_create: opcode 1003 param_len 0
> bt_buf_alloc: buf 0x20002c28 type 0 reserve 0
> bt_hci_cmd_create: buf 0x20002c28
> bt_buf_extend: buf 0x20002c28 len 3
> bt_hci_cmd_send_sync: opcode 1003 len 3
> bt_buf_addref: buf 0x20002c28 (old) ref 1 type 0
> hci_tx_kthread: Sending command 1003 buf 0x20002c28 to driver
> bt_hci_send: passing CMD 4099 to softdevice
> bt_buf_release: buf 0x20002c28 ref 2 type 0
> bt_buf_release: Remaining references: 1
> on_hci: received CMD_COMPLETE from softdevice (opcode: 4099, status: 0x3)
> bt_buf_alloc: buf 0x20002c40 type 1 reserve 1
> bt_buf_extend: buf 0x20002c40 len 14
> bt_hci_receive: buf 0x20002c40 len 14
> priority_rx_work: list 0x20002c64
> priority_rx_work: buf 0x20002c40 type 1 len 14
> bt_buf_consume: buf 0x20002c40 len 2
> hci_cmd_complete: opcode 1003
> bt_buf_consume: buf 0x20002c40 len 3
> hci_cmd_complete: Unhandled opcode 1003
> bt_buf_addref: buf 0x20002c40 (old) ref 1 type 1
> bt_buf_release: buf 0x20002c28 ref 1 type 0
> bt_buf_release: Buffer freed: 0x20002c28
> bt_buf_release: buf 0x20002c40 ref 2 type 1
> bt_buf_release: Remaining references: 1
> bt_buf_release: buf 0x20002c28 ref 0 type 0
> bt_buf_release: Remaining references: 255
> read_local_features_complete: status 0
> bt_buf_release: buf 0x20002c40 ref 1 type 1
> bt_buf_release: Buffer freed: 0x20002c40
> bt_hci_cmd_create: opcode 1001 param_len 0
> bt_buf_alloc: buf 0x20002c40 type 0 reserve 0
> bt_hci_cmd_create: buf 0x20002c40
> bt_buf_extend: buf 0x20002c40 len 3
> bt_hci_cmd_send_sync: opcode 1001 len 3
> bt_buf_addref: buf 0x20002c40 (old) ref 1 type 0
> hci_tx_kthread: Sending command 1001 buf 0x20002c40 to driver
> bt_hci_send: passing CMD 4097 to softdevice
> bt_buf_release: buf 0x20002c40 ref 2 type 0
> bt_buf_release: Remaining references: 1
> on_hci: received CMD_COMPLETE from softdevice (opcode: 4097, status: 0x1)
> bt_buf_alloc: buf 0x20002c28 type 1 reserve 1
> bt_buf_extend: buf 0x20002c28 len 14
> bt_hci_receive: buf 0x20002c28 len 14
> priority_rx_work: list 0x20002c64
> priority_rx_work: buf 0x20002c28 type 1 len 14
> bt_buf_consume: buf 0x20002c28 len 2
> hci_cmd_complete: opcode 1001
> bt_buf_consume: buf 0x20002c28 len 3
> hci_cmd_complete: Unhandled opcode 1001
> bt_buf_addref: buf 0x20002c28 (old) ref 1 type 1
> bt_buf_release: buf 0x20002c40 ref 1 type 0
> bt_buf_release: Buffer freed: 0x20002c40
> bt_buf_release: buf 0x20002c28 ref 2 type 1
> bt_buf_release: Remaining references: 1
> bt_buf_release: buf 0x20002c40 ref 0 type 0
> bt_buf_release: Remaining references: 255
> read_local_ver_complete: status 0
> bt_buf_release: buf 0x20002c28 ref 1 type 1
> bt_buf_release: Buffer freed: 0x20002c28
> bt_hci_cmd_create: opcode 1009 param_len 0
> bt_buf_alloc: buf 0x20002c28 type 0 reserve 0
> bt_hci_cmd_create: buf 0x20002c28
> bt_buf_extend: buf 0x20002c28 len 3
> 

RE: (Late) heads-up for new risc-v soc and board

[Alin.Jerpelea]

Nice Work!

-Original Message-
From: Abdelatif Guettouche  
Sent: den 24 maj 2021 21:39
To: dev@nuttx.apache.org
Subject: Re: (Late) heads-up for new risc-v soc and board

Nice work!  Thanks for the contribution!

On Mon, May 24, 2021 at 8:34 PM Janne Rosberg 
wrote:

> Hi Alan,
>
> Yes, it has FPGA “build-in” so you can do very nice processing with that.
> Also 4+1 cores running on 600+Mhz so it’s almost a supercomputer. 
> Let’s see what we can squeeze out of it.
> Later on hoping to get SMP config working….
>
> Janne
>
> From: Alan Carvalho de Assis 
> Date: Monday, 24. May 2021 at 22.13
> To: dev@nuttx.apache.org 
> Subject: Re: (Late) heads-up for new risc-v soc and board Hi Janne,
>
> Very nice! Kudos!!!
>
> So, this SoC has FPGA integrated on it?
>
> BR,
>
> Alan
>
> On 5/24/21, Janne Rosberg  wrote:
> > Hi all devs,
> >
> > First of all, it’s nice to be back on (public) NuttX development. 
> > It’s
> been
> > a while since last time. 
> >
> > We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle 
> > evaluation board.
> > Basic things already works (uart and gpios) so we can boot to nsh.
> > First PR #3770 is already “pending”
> >
> > If there is anybody who is working on this SoC please let us know so
> that we
> > can combine our work forces…
> > But anyway, we continue with peripheral drivers; I2C already done 
> > others
> to
> > follow.
> >
> > This work is was made possible by TII. 
> > https://urldefense.com/v3/__https://github.com/tiiuae__;!!JmoZiZGBv3
> > RvKRSx!pWpWHd7coS7_nWVWDrp6nYpBdWSYzz7oHtzqJDufQjN29r4NgJ9Gv0LOrKNYj
> > 5-NHQ$  so all
> PR’s
> > are coming from there.
> >
> > Br,
> > Janne
> >
> >
>

Re: GitHub actions concurrency

[Brennan Ashton]

On Mon, May 24, 2021, 2:09 PM Nathan Hartman 
wrote:

> I noticed this message [1] from Jarek Potiuk to builds@a.o about a new
> concurrency feature of GitHub Actions. Interesting to us?
>
> [1]
> https://mail-archives.apache.org/mod_mbox/www-builds/202105.mbox/%3cCAH067R=0A0oQhn2SghOKmdj561KvXGKjMG6x_ROQqdf=6vs...@mail.gmail.com%3e


I saw the GitHub announcement as well, we will want to move to it, but as
it is an early beta feature I think is makes sense to see how some other
projects like Apache Airflow find it works.

--Brennan