Re: Problem with running nuttx on imxrt1020

[michal . lyszczek]

On 2025-02-17 08:48:28, Simin Feng (CW) wrote:
 
> dump_assert_info: Assertion failed panic: at file: :0 task: Idle_Task 
> process: Kernel 0x600031dd

Seems like you need to enable debug as there is file and line missing from log.

Enable debug symbols and more debug prints, also canaries for stack monitoring
and try to rerun - maybe some more useful information will be revealed.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature

Problem with running nuttx on imxrt1020

[Simin Feng (CW)]

Hello,

I am attempting to runing nuttx on NXP imxrt1020 board.
I have downloaded the latest version from the https://nuttx.apache.org/
and follow the getting started steps:

1../tools/configure.sh imxrt1020-evk:nsh
2.make menuconfig
3.make


However, After I flashed the nuttx.hex with J-Link into the board and try get 
nsh info from lpuart COM there is only below dump info.
Could you please help check why the nuttx can not runing nsh normally on 
imxrt1020?

dump_assert_info: Current Version: NuttX  12.8.0 3bf704ad13 Feb 17 2025 
15:21:34 arm
dump_assert_info: Assertion failed panic: at file: :0 task: Idle_Task process: 
Kernel 0x600031dd
up_dump_register: R0: 20201240 R1:  R2: 6001448c  R3: 0007
up_dump_register: R4: 0003 R5: 20200b80 R6: 20201240  FP: 6001448c
up_dump_register: R8:  SB: 20200c44 SL: 0002 R11: 
up_dump_register: IP:  SP: 20202c30 LR: 6000363b  PC: 6000363b
up_dump_register: xPSR: 6003 BASEPRI: 0080 CONTROL: 
up_dump_register: EXC_RETURN: 
dump_stacks: ERROR: Stack pointer is not within the stack
dump_stackinfo: User Stack:
dump_stackinfo:   base: 0
dump_stackinfo:   size: 
stack_dump: 0:        

dump_tasks:PID GROUP PRI POLICY   TYPENPX STATE   EVENT  SIGMASK
  STACKBASE  STACKSIZE   COMMAND




Thank you.

Simin

Re: [VOTE] NuttX Contributing Guidelines update 202502.

[Tiago Medicci Serrano]

Hi!

Thanks, Tomek, for summarizing it.

I liked Nathan's proposal. Instead of simply increasing the number of
reviewers from 2 to 4, we can adopt tags (we can even evaluate if the bot
can do it automatically), and, based on such categories, we have new
requirements for the reviewers.

Considering that, I'd drop the concept of *Lazy Consensus* (item 19)
because it covers my main concern:

We *should* try to keep NuttX as stable and backwards compatible as
> feasible so that people can adopt NuttX and count on it to keep
> working for them in the long run.
> At the same time,
>
>
>
> *we need to be very careful not to make rules thatare too strict and
> inflexible, because then we would risk turning awaycontributors and we
> would end up with old cruft that is really brokenand generating a lot of
> complaints but can't be fixed because it wouldbreak the rules.*
> So we need to strike a good balance.


We don't need a general rule and 4 reviewers for Documentation and new chip
bring-ups. We need 4 (or even more) reviewers for changes that break
production-ready interfaces.

Best regards,

Em dom., 16 de fev. de 2025 às 15:45, Tomek CEDRO 
escreveu:

> Thank you Nathan :-)
>
> I just noticed that we missed self review can be added to 17 :-P
>
> I am allergic to bureaucracy myself. All this is to improve project
> quality not to make life harder. But also avoid obvious situations
> like self merging, sending untested changes, making breaking changes
> standard, and in general distinguishing lack of self-compatibility
> from fake innovation. NuttX is really unique in modern ICT world of
> enforced changes and we should nurture that quality over quantity
> approach. This is why there are no changes in requirements yet until
> everyone is happy and we sort things out :-)
>
> I checked that NuttX supports over 15 different architectures, 342
> unique boards, and over 1600 different configurations!! 2024Q4 we had
> 1233 commits in nuttx repo and 228 commits in nuttx-apps repo :-)
>
> Some good things already noticed is the increase in reviewers activity
> and this was my main goal behind point 14 whatever final form it gets,
> PR and git messages improved already, and we are working on
> distributed test tools, so the situation seems quite motivational and
> constructive, big thank you everyone for that :-)
>
> Have a good day folks :-)
> Tomek
>
>
> On Sun, Feb 16, 2025 at 6:31 PM Nathan Hartman 
> wrote:
> >
> > On Sat, Feb 15, 2025 at 4:53 PM Tomek CEDRO  wrote:
> > >
> > > Okay so here goes the vote results :-)
> >
> > Thanks, Tomek, for doing all of this!
> >
> > I would like to add some more of my thoughts:
> >
> > Regarding these rules:
> >
> > 9. Zero trust approach to user testing
> > 10. Breaking changes not welcome.
> > 11. Respect for long term maintenance and self-compatibility
> > 12. Breaking changes handling process
> > 14. Minimum code reviews 2 -> 4
> >
> > Raiden said something very relevant (in #11) that I would like to expand
> upon:
> >
> > > Not every interface in NuttX is equally mature. Until we
> > > establish which API is stable and which is not, this change is bad.
> > > Breaking a stable API should be avoided, breaking an unstable and
> > > under development API should be allowed.
> >
> > We *should* try to keep NuttX as stable and backwards compatible as
> > feasible so that people can adopt NuttX and count on it to keep
> > working for them in the long run.
> >
> > At the same time, we need to be very careful not to make rules that
> > are too strict and inflexible, because then we would risk turning away
> > contributors and we would end up with old cruft that is really broken
> > and generating a lot of complaints but can't be fixed because it would
> > break the rules.
> >
> > So we need to strike a good balance.
> >
> > How to strike a good balance?
> >
> > When deciding how easy or hard it should be to change some code, we
> > should consider:
> > * How new or mature the area of code is
> > * How well the area of code works (known buggy .. known good)
> > * How much will changes in this code affect other parts of the system
> > * How well the area conforms to established standards
> >
> > Then:
> >
> > Code in mainline that is relatively new, known buggy, and won't affect
> > too much the rest of the system should be allowed to change easily.
> > Not too much discussions, votes, and other ceremony needed here. Just
> > make the change with one reviewer (not from same org) and move on...
> >
> > Code in mainline that has existed for a long time, is mature, known to
> > be working well, and will break many parts of the system if changed,
> > should require careful consideration before changing. We shouldn't
> > outright forbid such a change; maybe it's a "breaking" change but
> > still needs to happen for important reasons. This is an area that
> > needs lots of input, so, there should be a good discussion in the
> > mailing lists, possibly including a [VOTE] to decide should we ma

Re: ESP32C3 Using UART1 in RS485 mode with HW flowcontrol

[Tiago Medicci Serrano]

Hi Erik,

Would you mind opening an issue at https://github.com/apache/nuttx/issues?

It isn't clear which SoC you are testing, but it seems to be a RISC-V-based
Espressif SoC (ESP32-C3, perhaps). For ESP32-C3, we have two
implementations: a legacy

implementation and a common

implementation. The legacy implementation is intended to be deprecated as
soon as the common implementation reaches the same support level. The
so-called common implementation shares sources between all the supported
RISC-V-based devices (ESP32-C3, ESP32-C6 and ESP32-H2).

The legacy implementation theoretically supports RS485, but it doesn't
build the `arch/risc-v/src/common/espressif/esp_serial.c` (which is used by
the common implementation). So it isn't clear how you are enabling the
RS485 mode.

For the common implementation, neither RS485 nor hardware flow control has
been implemented yet. Can you please provide more details on issues to
track it down?

Best regards,

Em seg., 17 de fev. de 2025 às 16:49, Erik Englund 
escreveu:

> While kiddo is home from school with a fever, I thought i would give NuttX
> a go again, living mostly in the Zephyr-world for the past years.
> Great job starting to implement cmake buildsystem, as keeping out-of-tree
> build directories greatly reduces the cases where you need to reclone the
> entire project due to build system errors, especially after a git pull
> without remembering to do a clean/distclean etc!
>
> Im building from master, couldnt see any relevant changes since 12.8.0.
>
> Enabling flow control in the build instantly crashes the build as the
> function:
> esp_rxflowcontrol (arch/risc-v/src/common/espressif/esp_serial.c) is
> trying to call the function esp_lowputc_set_iflow which isnt included in
> the build. It seem to exist in:
> arch/risc-v/src/esp32c3-legacy/esp32c3_lowputc.c
> Is the entine ESP32 lineup being merged to a ton of hal/hal_ll files
> instead of the old pure implementation?
>
> Anyways, flowcontrol seem to be setup in esp_setup (esp_serial.c) so just
> using that code in esp_rxflowcontrol should fix this issue.
>
> I setup UART1 in RS485 mode: dl0 and dl1 enabled + enable rs485 mode.
> CTS blocks transmission as intended if CTS isnt pulled to GND.
> But RTS signal is just pulling the pin high for a few microseconds before
> going low again,  right before transmitting the message.
>
> [image: image.png]
>
>
> The issue is seen when echoing to the serialport from nsh as when opening
> the serial device in a application and transmitting data.
>
> Is this a misconfiguration or a known issue?
>
>
>
>

Re: FB console/terminal

[Tim Hardisty]

Just thinking out loud...

Would NuttX benefit from a FrameBuffer stdout driver (e.g. /dev/fbcon) 
that allowed a pipe/dup to replace stdout, or the use of 
CONFIG_NSH_ALTSTDOUT and/or CONFIG_ALTSTDERR for console output?


In my case, this is just for MCUboot messages in the case of bootloader 
issues; to let the user know what's going on and, perhaps, guide the 
user through recovery procedures. The LCD is the only display available, 
as a serial console is not available to the user for this embedded 
device. But could be a generally useful thing?


On 16/02/2025 10:45, Alan C. Assis wrote:

Hi Tim,

I think there is not a framebuffer text in place for NuttX, but you can use
the code to handle text fonts from nx graphics to render the text directly
in the framebuffer.

For Linux some years ago I used fbtext
https://sourceforge.net/projects/fbtext/ to print a message from initrd to
let user know a secret key the decript the disk.

Alternatively if you want to print images in the screen you can use
something like fbprint ( https://github.com/Weinsen/fbprint ).

BR,

Alan

On Saturday, February 15, 2025, Tim Hardisty 
wrote:


What is efficient solution to just do text though?


On 15 Feb 2025, at 13:42, Alan C. Assis  wrote:

Hi Tim,

You can create a NuttX application with LVGL and display your message or
image.

Actually you don't need to use a graphic library if you just want to

write

in the framebuffer, you can convert image to display directly in the
/dev/fb0

BR,

Alan


On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty 
wrote:

Hello NuttX Colleagues!

During MCUboot I want to display text messages on the framebuffer LCD
driver (/dev/fb). This could either be via a FB console (useful for
other reasons) or a FB terminal, or something else.

I also quite like the idea of my main graphics app - LVGL based - having
a console option (for syslog messages, perhaps), so perhaps LVGL is an
option, but I'm wanting to keep the size down of course.

Which of the NuttX armoury of features might be a good choice for this?

Thanks!

TimJTi

ESP32C3 Using UART1 in RS485 mode with HW flowcontrol

[Erik Englund]

While kiddo is home from school with a fever, I thought i would give NuttX
a go again, living mostly in the Zephyr-world for the past years.
Great job starting to implement cmake buildsystem, as keeping out-of-tree
build directories greatly reduces the cases where you need to reclone the
entire project due to build system errors, especially after a git pull
without remembering to do a clean/distclean etc!

Im building from master, couldnt see any relevant changes since 12.8.0.

Enabling flow control in the build instantly crashes the build as the
function:
esp_rxflowcontrol (arch/risc-v/src/common/espressif/esp_serial.c) is trying
to call the function esp_lowputc_set_iflow which isnt included in the
build. It seem to exist in:
arch/risc-v/src/esp32c3-legacy/esp32c3_lowputc.c
Is the entine ESP32 lineup being merged to a ton of hal/hal_ll files
instead of the old pure implementation?

Anyways, flowcontrol seem to be setup in esp_setup (esp_serial.c) so just
using that code in esp_rxflowcontrol should fix this issue.

I setup UART1 in RS485 mode: dl0 and dl1 enabled + enable rs485 mode.
CTS blocks transmission as intended if CTS isnt pulled to GND.
But RTS signal is just pulling the pin high for a few microseconds before
going low again,  right before transmitting the message.

[image: image.png]


The issue is seen when echoing to the serialport from nsh as when opening
the serial device in a application and transmitting data.

Is this a misconfiguration or a known issue?

Re: FB console/terminal

[Tomek CEDRO]

Yes that would be a nice feature also for testing the LCD and should
be easy to implement for output only mode when no input is required
:-) Input would require serial port like transport, keyboard, or
on-screen keyboard that makes things a bit more complicated :-)
Tomek

On Mon, Feb 17, 2025 at 8:11 PM Tim Hardisty  wrote:
>
> Just thinking out loud...
>
> Would NuttX benefit from a FrameBuffer stdout driver (e.g. /dev/fbcon)
> that allowed a pipe/dup to replace stdout, or the use of
> CONFIG_NSH_ALTSTDOUT and/or CONFIG_ALTSTDERR for console output?
>
> In my case, this is just for MCUboot messages in the case of bootloader
> issues; to let the user know what's going on and, perhaps, guide the
> user through recovery procedures. The LCD is the only display available,
> as a serial console is not available to the user for this embedded
> device. But could be a generally useful thing?
>
> On 16/02/2025 10:45, Alan C. Assis wrote:
> > Hi Tim,
> >
> > I think there is not a framebuffer text in place for NuttX, but you can use
> > the code to handle text fonts from nx graphics to render the text directly
> > in the framebuffer.
> >
> > For Linux some years ago I used fbtext
> > https://sourceforge.net/projects/fbtext/ to print a message from initrd to
> > let user know a secret key the decript the disk.
> >
> > Alternatively if you want to print images in the screen you can use
> > something like fbprint ( https://github.com/Weinsen/fbprint ).
> >
> > BR,
> >
> > Alan
> >
> > On Saturday, February 15, 2025, Tim Hardisty 
> > wrote:
> >
> >> What is efficient solution to just do text though?
> >>
> >>> On 15 Feb 2025, at 13:42, Alan C. Assis  wrote:
> >>>
> >>> Hi Tim,
> >>>
> >>> You can create a NuttX application with LVGL and display your message or
> >>> image.
> >>>
> >>> Actually you don't need to use a graphic library if you just want to
> >> write
> >>> in the framebuffer, you can convert image to display directly in the
> >>> /dev/fb0
> >>>
> >>> BR,
> >>>
> >>> Alan
> >>>
>  On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty 
>  wrote:
> 
>  Hello NuttX Colleagues!
> 
>  During MCUboot I want to display text messages on the framebuffer LCD
>  driver (/dev/fb). This could either be via a FB console (useful for
>  other reasons) or a FB terminal, or something else.
> 
>  I also quite like the idea of my main graphics app - LVGL based - having
>  a console option (for syslog messages, perhaps), so perhaps LVGL is an
>  option, but I'm wanting to keep the size down of course.
> 
>  Which of the NuttX armoury of features might be a good choice for this?
> 
>  Thanks!
> 
>  TimJTi
> 
> 



-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FB console/terminal

[Alan C. Assis]

Hi Tim,

Actually that could be a great idea!

Maybe even the debug and initialization message from syslog could be
printed to this fbcon interface.

BR,

Alan

On Mon, Feb 17, 2025 at 4:11 PM Tim Hardisty 
wrote:

> Just thinking out loud...
>
> Would NuttX benefit from a FrameBuffer stdout driver (e.g. /dev/fbcon)
> that allowed a pipe/dup to replace stdout, or the use of
> CONFIG_NSH_ALTSTDOUT and/or CONFIG_ALTSTDERR for console output?
>
> In my case, this is just for MCUboot messages in the case of bootloader
> issues; to let the user know what's going on and, perhaps, guide the
> user through recovery procedures. The LCD is the only display available,
> as a serial console is not available to the user for this embedded
> device. But could be a generally useful thing?
>
> On 16/02/2025 10:45, Alan C. Assis wrote:
> > Hi Tim,
> >
> > I think there is not a framebuffer text in place for NuttX, but you can
> use
> > the code to handle text fonts from nx graphics to render the text
> directly
> > in the framebuffer.
> >
> > For Linux some years ago I used fbtext
> > https://sourceforge.net/projects/fbtext/ to print a message from initrd
> to
> > let user know a secret key the decript the disk.
> >
> > Alternatively if you want to print images in the screen you can use
> > something like fbprint ( https://github.com/Weinsen/fbprint ).
> >
> > BR,
> >
> > Alan
> >
> > On Saturday, February 15, 2025, Tim Hardisty 
> > wrote:
> >
> >> What is efficient solution to just do text though?
> >>
> >>> On 15 Feb 2025, at 13:42, Alan C. Assis  wrote:
> >>>
> >>> Hi Tim,
> >>>
> >>> You can create a NuttX application with LVGL and display your message
> or
> >>> image.
> >>>
> >>> Actually you don't need to use a graphic library if you just want to
> >> write
> >>> in the framebuffer, you can convert image to display directly in the
> >>> /dev/fb0
> >>>
> >>> BR,
> >>>
> >>> Alan
> >>>
>  On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty  >
>  wrote:
> 
>  Hello NuttX Colleagues!
> 
>  During MCUboot I want to display text messages on the framebuffer LCD
>  driver (/dev/fb). This could either be via a FB console (useful for
>  other reasons) or a FB terminal, or something else.
> 
>  I also quite like the idea of my main graphics app - LVGL based -
> having
>  a console option (for syslog messages, perhaps), so perhaps LVGL is an
>  option, but I'm wanting to keep the size down of course.
> 
>  Which of the NuttX armoury of features might be a good choice for
> this?
> 
>  Thanks!
> 
>  TimJTi
> 
> 
>

Re: FB console/terminal

[Tim Hardisty]

Input could be usb keyboard, otherwise the lvgl terminal app with its lvgl 
keyboard works. Output only mode for this I think.

> On 17 Feb 2025, at 21:25, Tomek CEDRO  wrote:
> 
> Yes that would be a nice feature also for testing the LCD and should
> be easy to implement for output only mode when no input is required
> :-) Input would require serial port like transport, keyboard, or
> on-screen keyboard that makes things a bit more complicated :-)
> Tomek
> 
>> On Mon, Feb 17, 2025 at 8:11 PM Tim Hardisty  wrote:
>> 
>> Just thinking out loud...
>> 
>> Would NuttX benefit from a FrameBuffer stdout driver (e.g. /dev/fbcon)
>> that allowed a pipe/dup to replace stdout, or the use of
>> CONFIG_NSH_ALTSTDOUT and/or CONFIG_ALTSTDERR for console output?
>> 
>> In my case, this is just for MCUboot messages in the case of bootloader
>> issues; to let the user know what's going on and, perhaps, guide the
>> user through recovery procedures. The LCD is the only display available,
>> as a serial console is not available to the user for this embedded
>> device. But could be a generally useful thing?
>> 
>>> On 16/02/2025 10:45, Alan C. Assis wrote:
>>> Hi Tim,
>>> 
>>> I think there is not a framebuffer text in place for NuttX, but you can use
>>> the code to handle text fonts from nx graphics to render the text directly
>>> in the framebuffer.
>>> 
>>> For Linux some years ago I used fbtext
>>> https://sourceforge.net/projects/fbtext/ to print a message from initrd to
>>> let user know a secret key the decript the disk.
>>> 
>>> Alternatively if you want to print images in the screen you can use
>>> something like fbprint ( https://github.com/Weinsen/fbprint ).
>>> 
>>> BR,
>>> 
>>> Alan
>>> 
>>> On Saturday, February 15, 2025, Tim Hardisty 
>>> wrote:
>>> 
 What is efficient solution to just do text though?
 
> On 15 Feb 2025, at 13:42, Alan C. Assis  wrote:
> 
> Hi Tim,
> 
> You can create a NuttX application with LVGL and display your message or
> image.
> 
> Actually you don't need to use a graphic library if you just want to
 write
> in the framebuffer, you can convert image to display directly in the
> /dev/fb0
> 
> BR,
> 
> Alan
> 
>> On Sat, Feb 15, 2025 at 7:45 AM Tim Hardisty 
>> wrote:
>> 
>> Hello NuttX Colleagues!
>> 
>> During MCUboot I want to display text messages on the framebuffer LCD
>> driver (/dev/fb). This could either be via a FB console (useful for
>> other reasons) or a FB terminal, or something else.
>> 
>> I also quite like the idea of my main graphics app - LVGL based - having
>> a console option (for syslog messages, perhaps), so perhaps LVGL is an
>> option, but I'm wanting to keep the size down of course.
>> 
>> Which of the NuttX armoury of features might be a good choice for this?
>> 
>> Thanks!
>> 
>> TimJTi
>> 
>> 
> 
> 
> 
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [VOTE] NuttX Contributing Guidelines update 202502.

[Tomek CEDRO]

On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano
 wrote:
> Hi!
> Thanks, Tomek, for summarizing it.
>
> I liked Nathan's proposal. Instead of simply increasing the number of
> reviewers from 2 to 4, we can adopt tags (we can even evaluate if the bot
> can do it automatically), and, based on such categories, we have new
> requirements for the reviewers.
>
> Considering that, I'd drop the concept of *Lazy Consensus* (item 19)
> because it covers my main concern:
>
> We *should* try to keep NuttX as stable and backwards compatible as
> > feasible so that people can adopt NuttX and count on it to keep
> > working for them in the long run.
> > At the same time,
> >
> > *we need to be very careful not to make rules thatare too strict and
> > inflexible, because then we would risk turning awaycontributors and we
> > would end up with old cruft that is really brokenand generating a lot of
> > complaints but can't be fixed because it wouldbreak the rules.*
> > So we need to strike a good balance.
>
> We don't need a general rule and 4 reviewers for Documentation and new chip
> bring-ups. We need 4 (or even more) reviewers for changes that break
> production-ready interfaces.

Yeah I just wanted rules to be as simple as possible and generic that
would avoid exceptions. If exceptions are required then maybe another
simple rule should be added? The problem is we don't really know what
change will break what and lots of PRs had testing section as short as
"CI" nothing more :-P

So is it okay to keep 2 reviewers for version bumps and documentation
updates and 4 for the rest? Maybe its good to have two rules: 2
reviews for trivial updates like version bumps and documentation
update (what else?) and 4 reviews for all other PRs?

Thanks! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info