Re: riscv64 libm link question

[ken . dickey]

On 2023-09-18 15:10, Alan C. Assis wrote:
..

Did you enable CONFIG_LIBM in the menuconfig?

Normally it is enough if your arch correctly configured.


Yep. Enabled.

I added

  LDLIBS += $(APPDIR)/../nuttx/libs/libm/libm.a

to the Makefile and the Scheme interpreter works -- some console 
wackyness, gc bug, but simple tests run.


Now I can progress!

Thanks again..
-KenD

Re: riscv64 libm link question

[Alan C. Assis]

Hi Ken,

On 9/18/23, ken.dic...@whidbey.com  wrote:
> On 2023-09-18 13:08, Alan C. Assis wrote:
>
>> The thumb rule when starting with NuttX is using an existent
>> configuration as base.
>
> OK.
>
>> Unfortunately the menuconfig is not prepared (better say it cannot) to
>> fix all dependencies for an driver or application (because of the
>> flexibility to use things in different ways on NuttX).
>
> Yes. I found Kconfig quite fragile.
>
> My hope was that selecting the basic interpreter in menuconfig would
> result in a working basic interpreter as this option exists in the base
> NuttX release.
>
> NuttX boots fine and `nsh` runs.  A CLI console based interpreter should
> be no problem as no extra drivers are required.
>
> I tried building on x86 Linux, but with the same result -- working nsh
> but failing bas & scheme.  `nm -u` shows both interpreters need to be
> linked with libm.
>
> I just have no idea how the NuttX build system specifies link libraries,
> i.e. how to link an application with libm.
>
> I will keep at it.  Thanks for the help.

Did you enable CONFIG_LIBM in the menuconfig?

Normally it is enough if your arch correctly configured.

BR,

Alan

Re: riscv64 libm link question

[ken . dickey]

On 2023-09-18 13:08, Alan C. Assis wrote:


The thumb rule when starting with NuttX is using an existent
configuration as base.


OK.


Unfortunately the menuconfig is not prepared (better say it cannot) to
fix all dependencies for an driver or application (because of the
flexibility to use things in different ways on NuttX).


Yes. I found Kconfig quite fragile.

My hope was that selecting the basic interpreter in menuconfig would 
result in a working basic interpreter as this option exists in the base 
NuttX release.


NuttX boots fine and `nsh` runs.  A CLI console based interpreter should 
be no problem as no extra drivers are required.


I tried building on x86 Linux, but with the same result -- working nsh 
but failing bas & scheme.  `nm -u` shows both interpreters need to be 
linked with libm.


I just have no idea how the NuttX build system specifies link libraries, 
i.e. how to link an application with libm.


I will keep at it.  Thanks for the help.
-KenD

Re: Link error building c++ app with master branch

[Alan C. Assis]

AFAIK gdb/JTAG using openocd works fine.

ESP32S3 has internal USB_SERIAL_JTAG, so you don't need external hardware!

BR,

Alan

On 9/18/23, Mike Moretti  wrote:
> Hi,
>
> Thanks.  That worked.
>
> Sorry, I got as far as grepping for pthread_key_create, saw that it
> existed in the code, and then just figured it would be easier to ask
> here again, as after a month of this kind of thing, I'm pretty tired of
> fighting with configuration/building/crashes in NuttX.
>
> After months of trying, we actually finally got this app working, a
> little over a week ago, on the esp32-devkit NuttX 12.2.1 release.
> However, unfortunately, the app, without any modifications other than
> the change in NuttX board/configuration, doesn't seem to work at all on
> the ESP32S3 with either 12.2.1 or master.  (The app is a sort of
> specialized communications router that uses udp and uart, etc; it's very
> linuxy/posixy and uses epoll and a bunch of other linux/posix apis).
> I'm not really sure what I'm going to do now. Debugging apps running
> under NuttX is way more difficult than I thought it would be, as I don't
> see any easy way to do JTAG/gdb as you can with other MCU RTOSes, and
> there are just so many layers and configurations.
>
> -m
>
> On 9/18/2023 4:19 PM, Alan C. Assis wrote:
>> Hi Mike,
>>
>> Let me explain the mental process I follow to fix this kind of error!
>>
>> The error message in this case is very "clear"
>>
>> undefined reference to `pthread_key_create'
>>
>> So let see where it is defined:
>>
>> $ cd nuttxspace/nuttx
>>
>> $ git grep pthread_key_create
>> ...
>> libs/libc/pthread/pthread_keycreate.c:int pthread_key_create(FAR
>> pthread_key_t *key,
>> ...
>>
>> Ok, just open libs/libc/pthread/Make.defs and see what symbol we need
>> to enable to get pthread_keycreate.c compiled:
>>
>> ifneq ($(CONFIG_TLS_NELEM),0)
>> CSRCS += pthread_keycreate.c pthread_setspecific.c pthread_getspecific.c
>> CSRCS += pthread_keydelete.c
>> endif
>>
>> Hmm, basically it is testing if CONFIG_TLS_NELEM != 0
>>
>> So, open menuconfig:
>>
>> $ make menuconfig
>>
>> And search for CONFIG_TLS_NELEM (press "/" inside menuconfig and type
>> TLS_NELEM and press ENTER)
>>
>> Bingo:
>> Symbol: TLS_NELEM [=0]
>>
>> You will need to increase it.
>>
>> BR,
>>
>> Alan
>>
>> On 9/18/23, Mike Moretti  wrote:
>>> Unfortunately, using master seems to come with yet other problems. I'm
>>> getting a link error:
>>>
>>> xtensa-esp32s3-elf-ld:
>>> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_110construct_Ev+0xc):
>>>
>>> undefined reference to `pthread_key_create'
>>> xtensa-esp32s3-elf-ld:
>>> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_19destruct_EPv+0x4):
>>>
>>> undefined reference to `pthread_setspecific'
>>> xtensa-esp32s3-elf-ld:
>>> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal.__cxa_get_globals_fast+0xc):
>>>
>>> undefined reference to `pthread_getspecific'
>>> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
>>> in function `std::__1::__libcpp_tls_create(int*, void (*)(void*))':
>>> nuttx/include/libcxx/__threading_support:551: undefined reference to
>>> `pthread_key_create'
>>> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
>>> in function `std::__1::__libcpp_tls_set(int, void*)':
>>> nuttx/include/libcxx/__threading_support:561: undefined reference to
>>> `pthread_setspecific'
>>> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
>>> in function `std::__1::__libcpp_tls_get(int)':
>>> nuttx/include/libcxx/__threading_support:556: undefined reference to
>>> `pthread_getspecific'
>>> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
>>> in function `std::__1::__libcpp_tls_set(int, void*)':
>>> nuttx/include/libcxx/__threading_support:561: undefined reference to
>>> `pthread_setspecific'
>>>
>>>
>>> Our custom app uses C++ and these specific config options (because
>>> they're necessary for the app to compile):
>>>
>>> CONFIG_LIBC_LOCALE=y
>>> CONFIG_HAVE_CXX=y
>>> CONFIG_HAVE_CXXINITIALIZE=y
>>> CONFIG_LIBCXX=y
>>> CONFIG_LIBCXXABI=y
>>> CONFIG_CXX_STANDARD="gnu++17"
>>> CONFIG_CXX_EXCEPTION=y
>>> CONFIG_CXX_RTTI=y
>>>
>>> -m
>>>
>>> On 9/18/2023 3:19 PM, Petro Karashchenko wrote:
 Using a released version is usually better, but since EPS32S3 has
 active
 feature development using master can give you better features support.
 That
 is obviously a tradeoff you need to make.
 I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to
 build
 a product on top of it, but there are still many features that I hope
 gona
 be added soon (like USB host support for example), so I'm staying on
 master
 currently.

 Best regards,
 Petro

 пн, 18 вер. 2023 р. о 22:15 Mike Moretti 
 пише:

> Hi,
>
> I'm using 12.2.1, the latest release.  The more I work with this chip

Re: Link error building c++ app with master branch

[Mike Moretti]

Hi,

Thanks.  That worked.

Sorry, I got as far as grepping for pthread_key_create, saw that it 
existed in the code, and then just figured it would be easier to ask 
here again, as after a month of this kind of thing, I'm pretty tired of 
fighting with configuration/building/crashes in NuttX.


After months of trying, we actually finally got this app working, a 
little over a week ago, on the esp32-devkit NuttX 12.2.1 release. 
However, unfortunately, the app, without any modifications other than 
the change in NuttX board/configuration, doesn't seem to work at all on 
the ESP32S3 with either 12.2.1 or master.  (The app is a sort of 
specialized communications router that uses udp and uart, etc; it's very 
linuxy/posixy and uses epoll and a bunch of other linux/posix apis).  
I'm not really sure what I'm going to do now. Debugging apps running 
under NuttX is way more difficult than I thought it would be, as I don't 
see any easy way to do JTAG/gdb as you can with other MCU RTOSes, and 
there are just so many layers and configurations.


-m

On 9/18/2023 4:19 PM, Alan C. Assis wrote:

Hi Mike,

Let me explain the mental process I follow to fix this kind of error!

The error message in this case is very "clear"

undefined reference to `pthread_key_create'

So let see where it is defined:

$ cd nuttxspace/nuttx

$ git grep pthread_key_create
...
libs/libc/pthread/pthread_keycreate.c:int pthread_key_create(FAR
pthread_key_t *key,
...

Ok, just open libs/libc/pthread/Make.defs and see what symbol we need
to enable to get pthread_keycreate.c compiled:

ifneq ($(CONFIG_TLS_NELEM),0)
CSRCS += pthread_keycreate.c pthread_setspecific.c pthread_getspecific.c
CSRCS += pthread_keydelete.c
endif

Hmm, basically it is testing if CONFIG_TLS_NELEM != 0

So, open menuconfig:

$ make menuconfig

And search for CONFIG_TLS_NELEM (press "/" inside menuconfig and type
TLS_NELEM and press ENTER)

Bingo:
Symbol: TLS_NELEM [=0]

You will need to increase it.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:

Unfortunately, using master seems to come with yet other problems. I'm
getting a link error:

xtensa-esp32s3-elf-ld:
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_110construct_Ev+0xc):

undefined reference to `pthread_key_create'
xtensa-esp32s3-elf-ld:
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_19destruct_EPv+0x4):

undefined reference to `pthread_setspecific'
xtensa-esp32s3-elf-ld:
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal.__cxa_get_globals_fast+0xc):

undefined reference to `pthread_getspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
in function `std::__1::__libcpp_tls_create(int*, void (*)(void*))':
nuttx/include/libcxx/__threading_support:551: undefined reference to
`pthread_key_create'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
in function `std::__1::__libcpp_tls_set(int, void*)':
nuttx/include/libcxx/__threading_support:561: undefined reference to
`pthread_setspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
in function `std::__1::__libcpp_tls_get(int)':
nuttx/include/libcxx/__threading_support:556: undefined reference to
`pthread_getspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
in function `std::__1::__libcpp_tls_set(int, void*)':
nuttx/include/libcxx/__threading_support:561: undefined reference to
`pthread_setspecific'


Our custom app uses C++ and these specific config options (because
they're necessary for the app to compile):

CONFIG_LIBC_LOCALE=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_LIBCXX=y
CONFIG_LIBCXXABI=y
CONFIG_CXX_STANDARD="gnu++17"
CONFIG_CXX_EXCEPTION=y
CONFIG_CXX_RTTI=y

-m

On 9/18/2023 3:19 PM, Petro Karashchenko wrote:

Using a released version is usually better, but since EPS32S3 has active
feature development using master can give you better features support.
That
is obviously a tradeoff you need to make.
I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to
build
a product on top of it, but there are still many features that I hope
gona
be added soon (like USB host support for example), so I'm staying on
master
currently.

Best regards,
Petro

пн, 18 вер. 2023 р. о 22:15 Mike Moretti 
пише:


Hi,

I'm using 12.2.1, the latest release.  The more I work with this chip
the more I'm wondering if I'm going to have to move to using master.
I've been trying to avoid not using an actual release version of NuttX.

-m

On 9/18/2023 3:08 PM, Petro Karashchenko wrote:

Hello Mike,

Which version of nuttx code are you using? Recently I was dealing with
UART1/2 on ESP32S3 and managed those to be working in
https://github.com/apache/nuttx/pull/10467
There were few issues including some clocking configuration problem as

well

as wrong pin functions used for UART1.

At the end I was able to even run RS485 with EPS32S3 and make a kind of
a
loopback test connecting UART1

Re: Link error building c++ app with master branch

[Alan C. Assis]

Hi Mike,

Let me explain the mental process I follow to fix this kind of error!

The error message in this case is very "clear"

undefined reference to `pthread_key_create'

So let see where it is defined:

$ cd nuttxspace/nuttx

$ git grep pthread_key_create
...
libs/libc/pthread/pthread_keycreate.c:int pthread_key_create(FAR
pthread_key_t *key,
...

Ok, just open libs/libc/pthread/Make.defs and see what symbol we need
to enable to get pthread_keycreate.c compiled:

ifneq ($(CONFIG_TLS_NELEM),0)
CSRCS += pthread_keycreate.c pthread_setspecific.c pthread_getspecific.c
CSRCS += pthread_keydelete.c
endif

Hmm, basically it is testing if CONFIG_TLS_NELEM != 0

So, open menuconfig:

$ make menuconfig

And search for CONFIG_TLS_NELEM (press "/" inside menuconfig and type
TLS_NELEM and press ENTER)

Bingo:
Symbol: TLS_NELEM [=0]

You will need to increase it.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:
> Unfortunately, using master seems to come with yet other problems. I'm
> getting a link error:
>
> xtensa-esp32s3-elf-ld:
> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_110construct_Ev+0xc):
>
> undefined reference to `pthread_key_create'
> xtensa-esp32s3-elf-ld:
> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_19destruct_EPv+0x4):
>
> undefined reference to `pthread_setspecific'
> xtensa-esp32s3-elf-ld:
> nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal.__cxa_get_globals_fast+0xc):
>
> undefined reference to `pthread_getspecific'
> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
> in function `std::__1::__libcpp_tls_create(int*, void (*)(void*))':
> nuttx/include/libcxx/__threading_support:551: undefined reference to
> `pthread_key_create'
> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
> in function `std::__1::__libcpp_tls_set(int, void*)':
> nuttx/include/libcxx/__threading_support:561: undefined reference to
> `pthread_setspecific'
> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
> in function `std::__1::__libcpp_tls_get(int)':
> nuttx/include/libcxx/__threading_support:556: undefined reference to
> `pthread_getspecific'
> xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o):
> in function `std::__1::__libcpp_tls_set(int, void*)':
> nuttx/include/libcxx/__threading_support:561: undefined reference to
> `pthread_setspecific'
>
>
> Our custom app uses C++ and these specific config options (because
> they're necessary for the app to compile):
>
> CONFIG_LIBC_LOCALE=y
> CONFIG_HAVE_CXX=y
> CONFIG_HAVE_CXXINITIALIZE=y
> CONFIG_LIBCXX=y
> CONFIG_LIBCXXABI=y
> CONFIG_CXX_STANDARD="gnu++17"
> CONFIG_CXX_EXCEPTION=y
> CONFIG_CXX_RTTI=y
>
> -m
>
> On 9/18/2023 3:19 PM, Petro Karashchenko wrote:
>> Using a released version is usually better, but since EPS32S3 has active
>> feature development using master can give you better features support.
>> That
>> is obviously a tradeoff you need to make.
>> I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to
>> build
>> a product on top of it, but there are still many features that I hope
>> gona
>> be added soon (like USB host support for example), so I'm staying on
>> master
>> currently.
>>
>> Best regards,
>> Petro
>>
>> пн, 18 вер. 2023 р. о 22:15 Mike Moretti 
>> пише:
>>
>>> Hi,
>>>
>>> I'm using 12.2.1, the latest release.  The more I work with this chip
>>> the more I'm wondering if I'm going to have to move to using master.
>>> I've been trying to avoid not using an actual release version of NuttX.
>>>
>>> -m
>>>
>>> On 9/18/2023 3:08 PM, Petro Karashchenko wrote:
 Hello Mike,

 Which version of nuttx code are you using? Recently I was dealing with
 UART1/2 on ESP32S3 and managed those to be working in
 https://github.com/apache/nuttx/pull/10467
 There were few issues including some clocking configuration problem as
>>> well
 as wrong pin functions used for UART1.

 At the end I was able to even run RS485 with EPS32S3 and make a kind of
 a
 loopback test connecting UART1-RS485 <-> UART2-RS485 on the same device
>>> and
 exchange data between those UARTs.

 Please check if your code base contains my fixes.

 Looking forward to hearing from you,
 Petro

 пн, 18 вер. 2023 р. о 21:59 Mike Moretti 
>>> пише:
> Hi,
>
> I'm having trouble with NuttX on the ESP32S3 trying to get UART1
> (configured on the default pins) working via /dev/ttyS1.  The driver
> code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
> you enable it in the configs, however, testing via
> serialblaster/serialrx (and our own custom app) doesn't seem to send
> or
> receive anything on uart1.  I've tried swapping my connections to the
> pins, testing every pin on the devkit board with serialblaster and
> nothing ever comes out.  I don't have this problem on an esp32 devkit
> (w

Link error building c++ app with master branch

[Mike Moretti]

Unfortunately, using master seems to come with yet other problems. I'm 
getting a link error:


xtensa-esp32s3-elf-ld: 
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_110construct_Ev+0xc): 
undefined reference to `pthread_key_create'
xtensa-esp32s3-elf-ld: 
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal._ZN10__cxxabiv112_GLOBAL__N_19destruct_EPv+0x4): 
undefined reference to `pthread_setspecific'
xtensa-esp32s3-elf-ld: 
nuttx/staging/libxx.a(cxa_exception_storage.o):(.literal.__cxa_get_globals_fast+0xc): 
undefined reference to `pthread_getspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o): 
in function `std::__1::__libcpp_tls_create(int*, void (*)(void*))':
nuttx/include/libcxx/__threading_support:551: undefined reference to 
`pthread_key_create'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o): 
in function `std::__1::__libcpp_tls_set(int, void*)':
nuttx/include/libcxx/__threading_support:561: undefined reference to 
`pthread_setspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o): 
in function `std::__1::__libcpp_tls_get(int)':
nuttx/include/libcxx/__threading_support:556: undefined reference to 
`pthread_getspecific'
xtensa-esp32s3-elf-ld: nuttx/staging/libxx.a(cxa_exception_storage.o): 
in function `std::__1::__libcpp_tls_set(int, void*)':
nuttx/include/libcxx/__threading_support:561: undefined reference to 
`pthread_setspecific'



Our custom app uses C++ and these specific config options (because 
they're necessary for the app to compile):


CONFIG_LIBC_LOCALE=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_LIBCXX=y
CONFIG_LIBCXXABI=y
CONFIG_CXX_STANDARD="gnu++17"
CONFIG_CXX_EXCEPTION=y
CONFIG_CXX_RTTI=y

-m

On 9/18/2023 3:19 PM, Petro Karashchenko wrote:

Using a released version is usually better, but since EPS32S3 has active
feature development using master can give you better features support. That
is obviously a tradeoff you need to make.
I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to build
a product on top of it, but there are still many features that I hope gona
be added soon (like USB host support for example), so I'm staying on master
currently.

Best regards,
Petro

пн, 18 вер. 2023 р. о 22:15 Mike Moretti  пише:


Hi,

I'm using 12.2.1, the latest release.  The more I work with this chip
the more I'm wondering if I'm going to have to move to using master.
I've been trying to avoid not using an actual release version of NuttX.

-m

On 9/18/2023 3:08 PM, Petro Karashchenko wrote:

Hello Mike,

Which version of nuttx code are you using? Recently I was dealing with
UART1/2 on ESP32S3 and managed those to be working in
https://github.com/apache/nuttx/pull/10467
There were few issues including some clocking configuration problem as

well

as wrong pin functions used for UART1.

At the end I was able to even run RS485 with EPS32S3 and make a kind of a
loopback test connecting UART1-RS485 <-> UART2-RS485 on the same device

and

exchange data between those UARTs.

Please check if your code base contains my fixes.

Looking forward to hearing from you,
Petro

пн, 18 вер. 2023 р. о 21:59 Mike Moretti 

пише:

Hi,

I'm having trouble with NuttX on the ESP32S3 trying to get UART1
(configured on the default pins) working via /dev/ttyS1.  The driver
code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
you enable it in the configs, however, testing via
serialblaster/serialrx (and our own custom app) doesn't seem to send or
receive anything on uart1.  I've tried swapping my connections to the
pins, testing every pin on the devkit board with serialblaster and
nothing ever comes out.  I don't have this problem on an esp32 devkit
(with either uart1 or uart2).  It seems to only happen on the esp32s3
devkit.  I can successfully use serialblaster/serialrx on /dev/ttyS0 and
see the output/enter text.

Is there something I'm missing?

Thanks,
-m

Re: riscv64 libm link question

[Alan C. Assis]

Hi Ken,

On 9/18/23, ken.dic...@whidbey.com  wrote:
> On 2023-09-18 12:05, Alan C. Assis wrote:
>> Hi Ken,
>>
>> Are you enabling the same symbols as in the sim bas or bastest ?
>
> I just used menuconfig interpreters bas selection
>
> Raspian:RasPi4:~/RISCV/NuttX/nuttx >>> grep CONFIG_INTERPRETER_BAS
> .config
> CONFIG_INTERPRETER_BAS_VERSION="2.4"
> CONFIG_INTERPRETER_BAS_PRIORITY=100
> CONFIG_INTERPRETER_BAS_STACKSIZE=4096
> CONFIG_INTERPRETER_BAS_VT100=y
> # CONFIG_INTERPRETER_BAS_USE_LR0 is not set
> # CONFIG_INTERPRETER_BAS_USE_SELECT is not set
> # CONFIG_INTERPRETER_BAS_HAVE_FTRUNCATE is not set
>
> Otherwise, basically same as
>./tools/configure.sh star64:nsh
>
> as I am building for VisionFive 3 riscv64 SoC.
>

The thumb rule when starting with NuttX is using an existent
configuration as base.

Unfortunately the menuconfig is not prepared (better say it cannot) to
fix all dependencies for an driver or application (because of the
flexibility to use things in different ways on NuttX).

After you got more experience with the system you can end-up figuring
things up, but normally it will require: 1) looking the symbols
dependence on Kconfig; 2) Looking the Makefiles/CMake that uses that
sysmbol to compile a file; 3) Looking the source code file to
understand which other symbol is needed.

BR,

Alan

Re: riscv64 libm link question

[ken . dickey]

On 2023-09-18 12:05, Alan C. Assis wrote:

Hi Ken,

Are you enabling the same symbols as in the sim bas or bastest ?


I just used menuconfig interpreters bas selection

Raspian:RasPi4:~/RISCV/NuttX/nuttx >>> grep CONFIG_INTERPRETER_BAS 
.config

CONFIG_INTERPRETER_BAS_VERSION="2.4"
CONFIG_INTERPRETER_BAS_PRIORITY=100
CONFIG_INTERPRETER_BAS_STACKSIZE=4096
CONFIG_INTERPRETER_BAS_VT100=y
# CONFIG_INTERPRETER_BAS_USE_LR0 is not set
# CONFIG_INTERPRETER_BAS_USE_SELECT is not set
# CONFIG_INTERPRETER_BAS_HAVE_FTRUNCATE is not set

Otherwise, basically same as
  ./tools/configure.sh star64:nsh

as I am building for VisionFive 3 riscv64 SoC.

-KenD

Re: /dev/ttyS1 doesn't seem to work on ESP32S3

[Petro Karashchenko]

Using a released version is usually better, but since EPS32S3 has active
feature development using master can give you better features support. That
is obviously a tradeoff you need to make.
I'm trying to fix all the issues I meet with ESP32S3 as I'm trying to build
a product on top of it, but there are still many features that I hope gona
be added soon (like USB host support for example), so I'm staying on master
currently.

Best regards,
Petro

пн, 18 вер. 2023 р. о 22:15 Mike Moretti  пише:

> Hi,
>
> I'm using 12.2.1, the latest release.  The more I work with this chip
> the more I'm wondering if I'm going to have to move to using master.
> I've been trying to avoid not using an actual release version of NuttX.
>
> -m
>
> On 9/18/2023 3:08 PM, Petro Karashchenko wrote:
> > Hello Mike,
> >
> > Which version of nuttx code are you using? Recently I was dealing with
> > UART1/2 on ESP32S3 and managed those to be working in
> > https://github.com/apache/nuttx/pull/10467
> > There were few issues including some clocking configuration problem as
> well
> > as wrong pin functions used for UART1.
> >
> > At the end I was able to even run RS485 with EPS32S3 and make a kind of a
> > loopback test connecting UART1-RS485 <-> UART2-RS485 on the same device
> and
> > exchange data between those UARTs.
> >
> > Please check if your code base contains my fixes.
> >
> > Looking forward to hearing from you,
> > Petro
> >
> > пн, 18 вер. 2023 р. о 21:59 Mike Moretti 
> пише:
> >
> >> Hi,
> >>
> >> I'm having trouble with NuttX on the ESP32S3 trying to get UART1
> >> (configured on the default pins) working via /dev/ttyS1.  The driver
> >> code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
> >> you enable it in the configs, however, testing via
> >> serialblaster/serialrx (and our own custom app) doesn't seem to send or
> >> receive anything on uart1.  I've tried swapping my connections to the
> >> pins, testing every pin on the devkit board with serialblaster and
> >> nothing ever comes out.  I don't have this problem on an esp32 devkit
> >> (with either uart1 or uart2).  It seems to only happen on the esp32s3
> >> devkit.  I can successfully use serialblaster/serialrx on /dev/ttyS0 and
> >> see the output/enter text.
> >>
> >> Is there something I'm missing?
> >>
> >> Thanks,
> >> -m
> >>
>
>

Re: UARTs ttyS and esp32

[Alan C. Assis]

Please open arch/xtensa/src/esp32/esp32_serial.c and search for
uart_register() function. Notice that it is wrapped by some #ifdef,
that need to be satisfied to that function be called.

Also if you enter inside boards/xtensa and "git grep UART1" or UART2
you will find some board configuration that uses that port. Compare
these config with your config and to see what configuration option you
are missing.

Any of these two strategies will work to figure out the issue.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:
> Hi,
>
> There are a bunch of configuration options for various peripherals,
> uart0,1,2, i2c0,1, spi0,1...  It appears that enabling say UART1 or
> UART2 (and configuring their pins) doesn't actually automatically
> register it as a ttyS in /devices.  Is there some reason for this? Do I
> have to manually register every uart other than uart0/ttyS0 in order to
> use it with as a character device via file i/o?  This just seems like
> some kind of oversight to me.  I've seen that if I enable I2C0 it shows
> up in /dev as /dev/i2c0.  SPI devices don't seem to show up either.  I
> have SPI2 enabled but see no spi device in /dev at all.  I don't see
> anything in the documentation about this and am just trying to figure
> out what we're expected to do to be able to access these devices.
>
> Thanks,
> -m
>
>
>

Re: UARTs ttyS and esp32

[Petro Karashchenko]

Hello Mike,

Usually most of the "/dev/XXX" devices are registered at board level (in
xxx_bringup() call
https://github.com/apache/nuttx/blob/master/boards/xtensa/esp32s3/esp32s3-devkit/src/esp32s3_bringup.c
).
Enabling peripherals does not always lead to registration of "/dev/XXX"
node as drivers may be used in much complex hierarchy, so that is
definitely a board level decision.
With UARTs it is a bit different as "/dev/ttySX" nodes are usually
registered at "xxx_serialinit()" (like "xtensa_serialinit()" for esp32s3
for example), so you do not need to register that at board level. You can
check in the code the exact conditions that have to be met for registration
to happen in "xxx_serialinit()".

Best regards,
Petro

пн, 18 вер. 2023 р. о 21:42 Mike Moretti  пише:

> Hi,
>
> There are a bunch of configuration options for various peripherals,
> uart0,1,2, i2c0,1, spi0,1...  It appears that enabling say UART1 or
> UART2 (and configuring their pins) doesn't actually automatically
> register it as a ttyS in /devices.  Is there some reason for this? Do I
> have to manually register every uart other than uart0/ttyS0 in order to
> use it with as a character device via file i/o?  This just seems like
> some kind of oversight to me.  I've seen that if I enable I2C0 it shows
> up in /dev as /dev/i2c0.  SPI devices don't seem to show up either.  I
> have SPI2 enabled but see no spi device in /dev at all.  I don't see
> anything in the documentation about this and am just trying to figure
> out what we're expected to do to be able to access these devices.
>
> Thanks,
> -m
>
>
>

Re: /dev/ttyS1 doesn't seem to work on ESP32S3

[Mike Moretti]

Hi,

I'm using 12.2.1, the latest release.  The more I work with this chip 
the more I'm wondering if I'm going to have to move to using master.  
I've been trying to avoid not using an actual release version of NuttX.


-m

On 9/18/2023 3:08 PM, Petro Karashchenko wrote:

Hello Mike,

Which version of nuttx code are you using? Recently I was dealing with
UART1/2 on ESP32S3 and managed those to be working in
https://github.com/apache/nuttx/pull/10467
There were few issues including some clocking configuration problem as well
as wrong pin functions used for UART1.

At the end I was able to even run RS485 with EPS32S3 and make a kind of a
loopback test connecting UART1-RS485 <-> UART2-RS485 on the same device and
exchange data between those UARTs.

Please check if your code base contains my fixes.

Looking forward to hearing from you,
Petro

пн, 18 вер. 2023 р. о 21:59 Mike Moretti  пише:


Hi,

I'm having trouble with NuttX on the ESP32S3 trying to get UART1
(configured on the default pins) working via /dev/ttyS1.  The driver
code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
you enable it in the configs, however, testing via
serialblaster/serialrx (and our own custom app) doesn't seem to send or
receive anything on uart1.  I've tried swapping my connections to the
pins, testing every pin on the devkit board with serialblaster and
nothing ever comes out.  I don't have this problem on an esp32 devkit
(with either uart1 or uart2).  It seems to only happen on the esp32s3
devkit.  I can successfully use serialblaster/serialrx on /dev/ttyS0 and
see the output/enter text.

Is there something I'm missing?

Thanks,
-m

Re: /dev/ttyS1 doesn't seem to work on ESP32S3

[Petro Karashchenko]

Hello Mike,

Which version of nuttx code are you using? Recently I was dealing with
UART1/2 on ESP32S3 and managed those to be working in
https://github.com/apache/nuttx/pull/10467
There were few issues including some clocking configuration problem as well
as wrong pin functions used for UART1.

At the end I was able to even run RS485 with EPS32S3 and make a kind of a
loopback test connecting UART1-RS485 <-> UART2-RS485 on the same device and
exchange data between those UARTs.

Please check if your code base contains my fixes.

Looking forward to hearing from you,
Petro

пн, 18 вер. 2023 р. о 21:59 Mike Moretti  пише:

> Hi,
>
> I'm having trouble with NuttX on the ESP32S3 trying to get UART1
> (configured on the default pins) working via /dev/ttyS1.  The driver
> code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when
> you enable it in the configs, however, testing via
> serialblaster/serialrx (and our own custom app) doesn't seem to send or
> receive anything on uart1.  I've tried swapping my connections to the
> pins, testing every pin on the devkit board with serialblaster and
> nothing ever comes out.  I don't have this problem on an esp32 devkit
> (with either uart1 or uart2).  It seems to only happen on the esp32s3
> devkit.  I can successfully use serialblaster/serialrx on /dev/ttyS0 and
> see the output/enter text.
>
> Is there something I'm missing?
>
> Thanks,
> -m
>

Re: riscv64 libm link question

[Alan C. Assis]

Hi Ken,

Are you enabling the same symbols as in the sim bas or bastest ?

$ cd nuttxspace/nuttx

$ cd boards/

$ git grep "BAS=y"
sim/sim/sim/configs/bas/defconfig:CONFIG_INTERPRETERS_BAS=y
sim/sim/sim/configs/bastest/defconfig:CONFIG_INTERPRETERS_BAS=y

$ cd ..

$ ./tools/configure.sh sim:bastest

$ make -j
Create version.h
LN: platform/board to /home/alan/nuttxspace/apps/platform/dummy
Register: nsh
Register: sh
Register: bas
Register: hello
Register: bastest
CP:  /home/alan/nuttxspace/nuttx/include/nuttx/config.h
CP:  /home/alan/nuttxspace/nuttx/include/nuttx/fs/hostfs.h
LD:  nuttx


$ ./nuttx
login: admin
password: Administrator
User Logged-in!
nsh> ?
help usage:  help [-v] []

.   cp  exitmkdir   pwd truncate
[   cmp false   mkfatfs rm  uname
?   dirname fdinfo  mkrdrmdir   umount
alias   dd  freemount   set unset
unalias df  helpmv  sleep   uptime
basenamedmesg   hexdump pidof   source  usleep
break   echokillpowerofftestxd
cat env losetup printf  time
cd  execls  ps  true

Builtin Apps:
basbastesthello  nshsh
nsh> bastest
Registering romdisk at /dev/ram6
Mounting ROMFS filesystem at target=/mnt/romfs with source=/dev/ram6
nsh> ls /mnt/romfs/
/mnt/romfs:
 test01.bas
 test02.bas
 test03.bas
 test04.bas
 test05.bas
 test06.bas
 test07.bas
 test08.bas
 test09.bas
 test10.bas
 test11.bas
 test12.bas
 test13.bas
 test14.bas
 test15.bas
 test16.bas
 test17.bas
 test18.bas
 test19.bas
 test20.bas
 test21.bas
 test22.bas
 test23.bas
 test24.bas
 test25.bas
 test26.bas
 test27.bas
 test28.bas
 test29.bas
 test30.bas
 test31.bas
 test32.bas
 test33.bas
 test34.bas
 test35.bas
 test36.bas
 test37.bas
 test37.dat
 test38.bas
 test39.bas
 test40.bas
 test41.bas
 test42.bas
 test43.bas
 test44.bas
 test45.bas
 test46.bas
 test47.bas
 test48.bas
 test49.bas
 test50.bas
 test51.bas
 test52.bas
nsh> bas /mnt/romfs/test01.bas
 1
hello
 0.0002
 2e-06
 2e-07

nsh>

BR,

Alan

On 9/18/23, ken.dic...@whidbey.com  wrote:
> Ah.  I tried using `make menuconfig` to build the Basic interpreter.
>
>
> Raspian:RasPi4:~/RISCV/NuttX/apps >>> riscv64-linux-gnu-gcc-nm -u
> bin/bas
>   U atan
>   U ceil
>   U cos
>   U exp
>   U floor
>   U fmod
>   U log
>   U log10
>   U log2
>   U pow
>   U sin
>   U sqrt
>   U tan
>
> Same result with the released `Bas` interpreter, so perhaps a general
> build problem related to aarch64/arm64 linux build environment?
>
> I have an old Intel/x86 box in the closet.  I will try to resurect it
> and see if I can build on x86 with the same result.
>
> FYI,
> -KenD
>

/dev/ttyS1 doesn't seem to work on ESP32S3

[Mike Moretti]

Hi,

I'm having trouble with NuttX on the ESP32S3 trying to get UART1 
(configured on the default pins) working via /dev/ttyS1.  The driver 
code for esp32s3_serial.c seems to configure uart1 as /dev/ttys1 when 
you enable it in the configs, however, testing via 
serialblaster/serialrx (and our own custom app) doesn't seem to send or 
receive anything on uart1.  I've tried swapping my connections to the 
pins, testing every pin on the devkit board with serialblaster and 
nothing ever comes out.  I don't have this problem on an esp32 devkit 
(with either uart1 or uart2).  It seems to only happen on the esp32s3 
devkit.  I can successfully use serialblaster/serialrx on /dev/ttyS0 and 
see the output/enter text.


Is there something I'm missing?

Thanks,
-m

UARTs ttyS and esp32

[Mike Moretti]

Hi,

There are a bunch of configuration options for various peripherals, 
uart0,1,2, i2c0,1, spi0,1...  It appears that enabling say UART1 or 
UART2 (and configuring their pins) doesn't actually automatically 
register it as a ttyS in /devices.  Is there some reason for this? Do I 
have to manually register every uart other than uart0/ttyS0 in order to 
use it with as a character device via file i/o?  This just seems like 
some kind of oversight to me.  I've seen that if I enable I2C0 it shows 
up in /dev as /dev/i2c0.  SPI devices don't seem to show up either.  I 
have SPI2 enabled but see no spi device in /dev at all.  I don't see 
anything in the documentation about this and am just trying to figure 
out what we're expected to do to be able to access these devices.


Thanks,
-m

Re: riscv64 libm link question

[ken . dickey]

Ah.  I tried using `make menuconfig` to build the Basic interpreter.


Raspian:RasPi4:~/RISCV/NuttX/apps >>> riscv64-linux-gnu-gcc-nm -u 
bin/bas

 U atan
 U ceil
 U cos
 U exp
 U floor
 U fmod
 U log
 U log10
 U log2
 U pow
 U sin
 U sqrt
 U tan

Same result with the released `Bas` interpreter, so perhaps a general 
build problem related to aarch64/arm64 linux build environment?


I have an old Intel/x86 box in the closet.  I will try to resurect it 
and see if I can build on x86 with the same result.


FYI,
-KenD

Re: ESP32S3 arbitrary crash when no optimization configured

[Bill Rees]

Hi All;

    From the discussion the reason for CONFIG_DEBUG_NOOPT to fail is 
already known. Is this true?


Confused and ignorant
Bill Rees

On 9/18/2023 8:55 AM, Tiago Medicci Serrano wrote:

Hi Mike,

NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise, few practical applications would be possible and you'd
need to reconsider stack sizes, for instance. So, please don't disable
optimization while building practical applications.

Usually, it isn't needed to disable optimization to debug the code, but If
you really need to turn it off to debug a specific function, consider using
the attribute `__attribute__((optimize(0)))`.

Best regards,

Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis 
escreveu:


Hi Mike,

I remember facing similar issue with ESP32 in the past.

Because I started using NuttX with ARM chip and in the past the GCC
toolchain has some issue with you are trying to compile debug symbols
(-g) and optimization enabled (-O2) I always disabled optimization
while enabling debugging. (Fortunately those day are gone, currently
gcc for ARM Cortex chips work fine with -g and -O2 at same time).

So when I started working with Xtensa I replicated this same behavior,
disabling the optimization and enabling the debug. So it started to
fail.

So some friends with more experience in Xtensa instructed me to just
use the -g and -O2 at same time. And I never investigate further about
it.

Probably this same issue will happen on ESP-IDF (just guessing, I
didn't check it). I think it could be a good place to start your
investigation.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:

Hi,

I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
figure out why it crashes on boot with our custom board/app.  It turns
out that turning off CONFIG_DEBUG_FULLOPT and turning on
CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
default from all the other esp32s3 configurations has FULLOPT on and
NOOPT off.  So, to verify it wasn't just in our custom board/app, I
tried this on the default esp32s3-devkit:wifi configuration, and IT DID
THE SAME THING, it crashes!  This is the second time I've had an issue
with random configuration settings causing the nuttx code to crash
arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
doing the same thing, which I previously posted about).

What the heck is going on?  Is the esp32/s3 port really this unstable?

-m

Re: ESP32S3 arbitrary crash when no optimization configured

[Nathan Hartman]

On Mon, Sep 18, 2023 at 12:07 PM Mike Moretti 
wrote:

> This is the kind of thing that really should be documented somewhere.
> In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
> disallow it being changed, or make FULLOPT the default for every platform?



Sometimes you really do need to disable optimization or you cannot
single-step through code in a coherent manner.

Yes, that could affect stack sizes and other things. Debugging can be a
tricky business.

Cheers
Nathan

Re: ESP32S3 arbitrary crash when no optimization configured

[Alan C. Assis]

Hi Mike,

Yes, I just noticed this option in the Kconfig:

choice
prompt "Optimization Level"
default DEBUG_NOOPT if DEBUG_SYMBOLS
default DEBUG_FULLOPT if !DEBUG_SYMBOLS

Probably this is from the days when GCC for ARM and other chips didn't
work well with debug enable and optimization enabled.

I think this is not a requirement anymore. But it is hard to say,
because NuttX support *a lot* of different architectures beyond ARM
and Xtensa.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:
> This is the kind of thing that really should be documented somewhere.
> In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or
> disallow it being changed, or make FULLOPT the default for every platform?
>
> I only stumbled upon this because I missed copying one single config
> line (the FULLOPT=y one) from the sample esp32s3 config files to our
> custom board file and didn't think it actually mattered when I was
> diffing the generated configs with the sample generated configs for
> verification (because, you know, it's just "optimization", and normally
> in any other typical development environment I would actually want noopt
> for debugging).  And without it, the default was NOOPT and crashes.
>
> -m
>
>
> On 9/18/2023 11:55 AM, Tiago Medicci Serrano wrote:
>> Hi Mike,
>>
>> NuttX + Espressif's SoCs are intended to be built with optimization
>> enabled. Otherwise, few practical applications would be possible and
>> you'd
>> need to reconsider stack sizes, for instance. So, please don't disable
>> optimization while building practical applications.
>>
>> Usually, it isn't needed to disable optimization to debug the code, but
>> If
>> you really need to turn it off to debug a specific function, consider
>> using
>> the attribute `__attribute__((optimize(0)))`.
>>
>> Best regards,
>>
>> Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis 
>> escreveu:
>>
>>> Hi Mike,
>>>
>>> I remember facing similar issue with ESP32 in the past.
>>>
>>> Because I started using NuttX with ARM chip and in the past the GCC
>>> toolchain has some issue with you are trying to compile debug symbols
>>> (-g) and optimization enabled (-O2) I always disabled optimization
>>> while enabling debugging. (Fortunately those day are gone, currently
>>> gcc for ARM Cortex chips work fine with -g and -O2 at same time).
>>>
>>> So when I started working with Xtensa I replicated this same behavior,
>>> disabling the optimization and enabling the debug. So it started to
>>> fail.
>>>
>>> So some friends with more experience in Xtensa instructed me to just
>>> use the -g and -O2 at same time. And I never investigate further about
>>> it.
>>>
>>> Probably this same issue will happen on ESP-IDF (just guessing, I
>>> didn't check it). I think it could be a good place to start your
>>> investigation.
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 9/18/23, Mike Moretti  wrote:
 Hi,

 I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
 figure out why it crashes on boot with our custom board/app.  It turns
 out that turning off CONFIG_DEBUG_FULLOPT and turning on
 CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
 default from all the other esp32s3 configurations has FULLOPT on and
 NOOPT off.  So, to verify it wasn't just in our custom board/app, I
 tried this on the default esp32s3-devkit:wifi configuration, and IT DID
 THE SAME THING, it crashes!  This is the second time I've had an issue
 with random configuration settings causing the nuttx code to crash
 arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
 doing the same thing, which I previously posted about).

 What the heck is going on?  Is the esp32/s3 port really this unstable?

 -m

>>
>
>

Re: ESP32S3 arbitrary crash when no optimization configured

[Bill Rees]

Hi Mike;


I haven't seen any screen dump of the error message(s). Are there any logs?

Bill

On 9/18/2023 9:04 AM, Mike Moretti wrote:
This is the kind of thing that really should be documented somewhere. 
In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or 
disallow it being changed, or make FULLOPT the default for every 
platform?


I only stumbled upon this because I missed copying one single config 
line (the FULLOPT=y one) from the sample esp32s3 config files to our 
custom board file and didn't think it actually mattered when I was 
diffing the generated configs with the sample generated configs for 
verification (because, you know, it's just "optimization", and 
normally in any other typical development environment I would actually 
want noopt for debugging).  And without it, the default was NOOPT and 
crashes.


-m


On 9/18/2023 11:55 AM, Tiago Medicci Serrano wrote:

Hi Mike,

NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise, few practical applications would be possible and 
you'd

need to reconsider stack sizes, for instance. So, please don't disable
optimization while building practical applications.

Usually, it isn't needed to disable optimization to debug the code, 
but If
you really need to turn it off to debug a specific function, consider 
using

the attribute `__attribute__((optimize(0)))`.

Best regards,

Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis 
escreveu:


Hi Mike,

I remember facing similar issue with ESP32 in the past.

Because I started using NuttX with ARM chip and in the past the GCC
toolchain has some issue with you are trying to compile debug symbols
(-g) and optimization enabled (-O2) I always disabled optimization
while enabling debugging. (Fortunately those day are gone, currently
gcc for ARM Cortex chips work fine with -g and -O2 at same time).

So when I started working with Xtensa I replicated this same behavior,
disabling the optimization and enabling the debug. So it started to
fail.

So some friends with more experience in Xtensa instructed me to just
use the -g and -O2 at same time. And I never investigate further about
it.

Probably this same issue will happen on ESP-IDF (just guessing, I
didn't check it). I think it could be a good place to start your
investigation.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:

Hi,

I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
figure out why it crashes on boot with our custom board/app.  It turns
out that turning off CONFIG_DEBUG_FULLOPT and turning on
CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
default from all the other esp32s3 configurations has FULLOPT on and
NOOPT off.  So, to verify it wasn't just in our custom board/app, I
tried this on the default esp32s3-devkit:wifi configuration, and IT 
DID

THE SAME THING, it crashes!  This is the second time I've had an issue
with random configuration settings causing the nuttx code to crash
arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for 
esp32

doing the same thing, which I previously posted about).

What the heck is going on?  Is the esp32/s3 port really this unstable?

-m

Re: ESP32S3 arbitrary crash when no optimization configured

[Mike Moretti]

This is the kind of thing that really should be documented somewhere.  
In bold, "DO NOT TURN OFF OPTIMIZATION because...". Either that or 
disallow it being changed, or make FULLOPT the default for every platform?


I only stumbled upon this because I missed copying one single config 
line (the FULLOPT=y one) from the sample esp32s3 config files to our 
custom board file and didn't think it actually mattered when I was 
diffing the generated configs with the sample generated configs for 
verification (because, you know, it's just "optimization", and normally 
in any other typical development environment I would actually want noopt 
for debugging).  And without it, the default was NOOPT and crashes.


-m


On 9/18/2023 11:55 AM, Tiago Medicci Serrano wrote:

Hi Mike,

NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise, few practical applications would be possible and you'd
need to reconsider stack sizes, for instance. So, please don't disable
optimization while building practical applications.

Usually, it isn't needed to disable optimization to debug the code, but If
you really need to turn it off to debug a specific function, consider using
the attribute `__attribute__((optimize(0)))`.

Best regards,

Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis 
escreveu:


Hi Mike,

I remember facing similar issue with ESP32 in the past.

Because I started using NuttX with ARM chip and in the past the GCC
toolchain has some issue with you are trying to compile debug symbols
(-g) and optimization enabled (-O2) I always disabled optimization
while enabling debugging. (Fortunately those day are gone, currently
gcc for ARM Cortex chips work fine with -g and -O2 at same time).

So when I started working with Xtensa I replicated this same behavior,
disabling the optimization and enabling the debug. So it started to
fail.

So some friends with more experience in Xtensa instructed me to just
use the -g and -O2 at same time. And I never investigate further about
it.

Probably this same issue will happen on ESP-IDF (just guessing, I
didn't check it). I think it could be a good place to start your
investigation.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:

Hi,

I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
figure out why it crashes on boot with our custom board/app.  It turns
out that turning off CONFIG_DEBUG_FULLOPT and turning on
CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
default from all the other esp32s3 configurations has FULLOPT on and
NOOPT off.  So, to verify it wasn't just in our custom board/app, I
tried this on the default esp32s3-devkit:wifi configuration, and IT DID
THE SAME THING, it crashes!  This is the second time I've had an issue
with random configuration settings causing the nuttx code to crash
arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
doing the same thing, which I previously posted about).

What the heck is going on?  Is the esp32/s3 port really this unstable?

-m

Re: ESP32S3 arbitrary crash when no optimization configured

[Tiago Medicci Serrano]

Hi Mike,

NuttX + Espressif's SoCs are intended to be built with optimization
enabled. Otherwise, few practical applications would be possible and you'd
need to reconsider stack sizes, for instance. So, please don't disable
optimization while building practical applications.

Usually, it isn't needed to disable optimization to debug the code, but If
you really need to turn it off to debug a specific function, consider using
the attribute `__attribute__((optimize(0)))`.

Best regards,

Em seg., 18 de set. de 2023 às 12:05, Alan C. Assis 
escreveu:

> Hi Mike,
>
> I remember facing similar issue with ESP32 in the past.
>
> Because I started using NuttX with ARM chip and in the past the GCC
> toolchain has some issue with you are trying to compile debug symbols
> (-g) and optimization enabled (-O2) I always disabled optimization
> while enabling debugging. (Fortunately those day are gone, currently
> gcc for ARM Cortex chips work fine with -g and -O2 at same time).
>
> So when I started working with Xtensa I replicated this same behavior,
> disabling the optimization and enabling the debug. So it started to
> fail.
>
> So some friends with more experience in Xtensa instructed me to just
> use the -g and -O2 at same time. And I never investigate further about
> it.
>
> Probably this same issue will happen on ESP-IDF (just guessing, I
> didn't check it). I think it could be a good place to start your
> investigation.
>
> BR,
>
> Alan
>
> On 9/18/23, Mike Moretti  wrote:
> > Hi,
> >
> > I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
> > figure out why it crashes on boot with our custom board/app.  It turns
> > out that turning off CONFIG_DEBUG_FULLOPT and turning on
> > CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
> > default from all the other esp32s3 configurations has FULLOPT on and
> > NOOPT off.  So, to verify it wasn't just in our custom board/app, I
> > tried this on the default esp32s3-devkit:wifi configuration, and IT DID
> > THE SAME THING, it crashes!  This is the second time I've had an issue
> > with random configuration settings causing the nuttx code to crash
> > arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
> > doing the same thing, which I previously posted about).
> >
> > What the heck is going on?  Is the esp32/s3 port really this unstable?
> >
> > -m
> >
>


-- 
Tiago Medicci Serrano

Embedded Software Engineer
MSc Electronics/Microelectronics
m: +55 (19) 981403886 <+55+(19)+981403886>
e: tiago.medi...@gmail.com
a: Campinas, Brazil
Follow me:

Re: epoll oddities following setup/teardown optimizations

[Alan C. Assis]

Hi Wang Bowen and Marten,

Is it possible to include an ostest with this code to avoid similar
regression in the future?

BR,

Alan

On 9/18/23, 汪博文  wrote:
> Hi,
>
> I did the epoll optimization last year. And your analysis is right. The new
> epoll implementation has BUG and I has reproduced this issue locally based
> on your description.
> I’m very sorry that this issue has affected your nuttx upgrade. I will fix
> this issue as soon as possible. Thanks.
>
> Regards
> Wang Bowen
>
> #/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
> This e-mail and its attachments contain confidential information from
> XIAOMI, which is intended only for the person or entity whose address is
> listed above. Any use of the information contained herein in any way
> (including, but not limited to, total or partial disclosure, reproduction,
> or dissemination) by persons other than the intended recipient(s) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!**/#
>

Re: ESP32S3 arbitrary crash when no optimization configured

[Alan C. Assis]

Hi Mike,

I remember facing similar issue with ESP32 in the past.

Because I started using NuttX with ARM chip and in the past the GCC
toolchain has some issue with you are trying to compile debug symbols
(-g) and optimization enabled (-O2) I always disabled optimization
while enabling debugging. (Fortunately those day are gone, currently
gcc for ARM Cortex chips work fine with -g and -O2 at same time).

So when I started working with Xtensa I replicated this same behavior,
disabling the optimization and enabling the debug. So it started to
fail.

So some friends with more experience in Xtensa instructed me to just
use the -g and -O2 at same time. And I never investigate further about
it.

Probably this same issue will happen on ESP-IDF (just guessing, I
didn't check it). I think it could be a good place to start your
investigation.

BR,

Alan

On 9/18/23, Mike Moretti  wrote:
> Hi,
>
> I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to
> figure out why it crashes on boot with our custom board/app.  It turns
> out that turning off CONFIG_DEBUG_FULLOPT and turning on
> CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The
> default from all the other esp32s3 configurations has FULLOPT on and
> NOOPT off.  So, to verify it wasn't just in our custom board/app, I
> tried this on the default esp32s3-devkit:wifi configuration, and IT DID
> THE SAME THING, it crashes!  This is the second time I've had an issue
> with random configuration settings causing the nuttx code to crash
> arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32
> doing the same thing, which I previously posted about).
>
> What the heck is going on?  Is the esp32/s3 port really this unstable?
>
> -m
>

RE: epoll oddities following setup/teardown optimizations

[汪博文]

Hi,

I did the epoll optimization last year. And your analysis is right. The new 
epoll implementation has BUG and I has reproduced this issue locally based on 
your description.
I’m very sorry that this issue has affected your nuttx upgrade. I will fix this 
issue as soon as possible. Thanks.

Regards
Wang Bowen

#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

ESP32S3 arbitrary crash when no optimization configured

[Mike Moretti]

Hi,

I'm using NuttX 12.2.1 with ESP32S3 and have been trying for days to 
figure out why it crashes on boot with our custom board/app.  It turns 
out that turning off CONFIG_DEBUG_FULLOPT and turning on 
CONFIG_DEBUG_NOOPT is what's causing my issue (via menuconfig).  The 
default from all the other esp32s3 configurations has FULLOPT on and 
NOOPT off.  So, to verify it wasn't just in our custom board/app, I 
tried this on the default esp32s3-devkit:wifi configuration, and IT DID 
THE SAME THING, it crashes!  This is the second time I've had an issue 
with random configuration settings causing the nuttx code to crash 
arbitrarily.  (The first was enabling CONFIG_DEBUG_ASSERTIONS for esp32 
doing the same thing, which I previously posted about).


What the heck is going on?  Is the esp32/s3 port really this unstable?

-m

Re: riscv64 libm link question

[ken . dickey]

As I am building on aarch64/arm64 Linux, someone might have a better 
time with x86.


I made a git repo:

   https://github.com/KenDickey/nuttx-umb-scheme

This goes into apps/interpreters.

The code has been reliably ported a lot and should run on most targets 
with command line console.


Sample code:

  (+ 1/2 1/3 1/6) ;; --> 1
  (sqrt -4) ;; --> 0+2i
  ((lambda (n) (* n n)) (sqrt -4)) ;; --> -4

Note that there is nothing time critical about this -- fine to wait 
until after the upcoming NuttX Workshop!



Thanks again for all.
-KenD

Re: ESP32S3 partition sizes?

[Tiago Medicci Serrano]

Hi Mike,

We have plans to make a simpler bootloader for the devices. For now, I
think it'd be better to document on one of the devices (ESP32, for
instance) and link that page on the others SoCs.

Once again, thank you for your contribution ;)

Best regards,

Em dom., 17 de set. de 2023 às 09:54, Mike Moretti
 escreveu:

> Hi,
>
> That part of the documentation looks like it is specific to esp32 only
> (not esp32s or esp32c).  This info applies to all the esp32 variants (s,
> c, h, etc).  That's why I was wondering where this should end up...
> There doesn't seem to be a place for esp32 non-variant-specific
> documentation.
>
> I think I may end up having to make it part of the bootloader readme and
> then put a brief blurb ("for more info or to change partition sizes,
> etc") on each of the 3 variant documentation pages pointing to it.  If
> anyone has a better idea let me know.
>
> Thanks,
> -m
>
> On 9/17/2023 8:39 AM, Tomek CEDRO wrote:
> > Thanks Mike for willing to contribute your discoveries :-)
> > I guess you can put this info into ESP32 documentation as there is a
> > section dedicated for bootloader and partitioning?
> >
> > https://nuttx.apache.org/docs/latest/platforms/xtensa/esp32/index.html
> >
> > Also there is FAQ section that may fit the need :-)
> >
>
>

-- 
Tiago Medicci Serrano

Embedded Software Engineer
MSc Electronics/Microelectronics
m: +55 (19) 981403886 <+55+(19)+981403886>
e: tiago.medi...@gmail.com
a: Campinas, Brazil
Follow me:

epoll oddities following setup/teardown optimizations

[Mårten Svanfeldt]

Hi,


Our software heavily relies on epoll based wait/event loops, using mixes of 
"real" FDs (mostly sockets), eventfd and timerfds, and after upgrading to Nuttx 
12.2.1 I have some oddities in behaviour that I think can be traced to the 
optimizations in 
https://github.com/apache/nuttx/commit/25bfd437fe5b30d0221c68288e27fb7efc57fe0c


The behaviour can easily be triggered by creating an epoll fd, adding two 
timerfd with same timeout to it and then doing a loop with epoll_wait. First 
iteration (on my board) epoll_wait will return 2, with 2 events having EPOLLIN 
set, as expected, however second time epoll_wait is called (with infinite 
timeout) it returns immediately, returning 0 (zero) meaning no ready fds which 
as far as I can read the spec of epoll_wait (in the linux kernel) is an invalid 
return for an infinite wait.


Reading the code and trying to debug using prints (without affecting the 
timing) I think the following is what happens:


  1.  epoll_wait blocks on nxsem_wait, waiting for the semaphore to be 
signaled. Semcount is decreased so it becomes -1.
  2.  timerfd1 expires, timerfd_timeout calls poll_notify which in turn signals 
the semaphore. Semcount increased by 1 so it becomes 0.
  3.  timerfd2 expires, timerfd_timeout calls poll_notify which in turn signals 
the semaphore again. Semcount increased by 1 so it becomes 1.
  4.  epoll_wait is woken up, processed the fds, copies revent etc to the 
output indicating (correctly) that both fds have been affected. epoll_wait 
returns 2.
  5.  epoll_wait is called again. nxsem_wait is called, but as semcount is 
already 1 it returns immediately so epoll_wait does not go to sleep. When 
processing fds all revents is now still zero, so epoll_wait returns 0 (as in 
fact there is nothing ready to process).

It is possible that the epoll_wait wakeup happens before timerfd2 expiration, 
however timerfd2 expiration definitley happens before epoll_teardown processes 
all the fds.

I am not sure about the correct way to handle this, and the setup/teardown 
optimizations in themselves seems good and desirable. Could someone who was 
involved in writing or reviewing the original patch maybe comment if my 
analysis seems wrong of if you have any idea how to solve this?

Regards
Marten Svanfeldt