On Mon, Nov 23, 2020 at 5:18 PM Gregory Nutt wrote:
> You can try the section on hardfault debugging here:
> https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That
> starts at slide 17:
>
> /Set a breakpoint on up_hardfault and up_assert//Set the PC equal to
> the
I'm thiking that we could extend nuttx-gdbinit so that it offers an easy way to
see registeres from CURRENT_REGS so that you can get a register dump without a
console. Also, we could have a function that could take the LR and set the PC
in order to go to most likely place of hardfault
You can try the section on hardfault debugging here:
https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That
starts at slide 17:
/Set a breakpoint on up_hardfault and up_assert//Set the PC equal to
the LR//Select assembly single step//And step to bx lr instruction
in
Some months ago I implemented the basic architectural support for
STM32G47xxx and I noticed that occasionally, during startup, I am
getting stuck in _up_assert(). It is not happening consistently. It's
intermittent. I'm not really sure why. Any ideas what I should look
for? Here is the backtrace:
Hi Vadim,
Add an entry in section .flashxip or .text for the _udivmoddi4.o and move
it to see if you can clear the error.
See
https://github.com/PX4/PX4-Autopilot/blob/master/boards/nxp/fmurt1062-v1/nuttx-config/scripts/ocram-script.ld#L105-L137
For what it takes to position an obj module.
Thank you for your prompt reply, David!
I already have nsh config working from 4MB internal flash which starts from
0x7000. I am not using neither Hyperflash nor external flash. This has also
been verified by measuring voltage values on CE low pins of each chip. Someone
else was also
My idea is to pick up g_statenames symbol, as nuttx-gdbinit does. However, I
couldn't find
a way to do this since it is a static array of character arrays, which requires
knowledge of each
entry length to be used. I guess there should be a way to do it but I couldn't
figure it out.
Best,
https://hackaday.com/2020/11/22/espressif-leaks-esp32-c3-a-wifi-soc-thats-risc-v-and-is-esp8266-pin-compatible/
https://www.cnx-software.com/2020/11/22/esp32-c3-wifi-ble-risc-v-processor-is-pin-to-pin-compatible-with-esp8266/
The state names is an enumeration from the NuttX side. I'm not sure
if we can use the same technique to retrieve it.
When adding the Xtensa/ESP32 stack info, I did some re-organisation
which should ease adding a new architecture. But that code will need
to wait for the next release before it
Nevermind, I thought I needed to correct register offsets and I only messed
them up.
I added the commands to my gdb startup and now works as expected. Maybe we
could do the same
to pass register addresses for other architectures and to set the array of
state names?
On Mon, Nov 23, 2020, at
Can you see that NuttX was detected and the offsets are correct from OpenOCD?
Do you have this in your OpenOCD config file: $_TARGETNAME configure -rtos nuttx
I do this with an STM32F4
source [find target/stm32f4x.cfg]
$_TARGETNAME configure -rtos nuttx
On Mon, Nov 23, 2020 at 4:00 PM Matias
Hi Vadim,
I do not recall all the deltas from the 1062 to the 1064. But the 1064 may
have other IP changes, and memory map differences
You should create a board new directory imxrt1060-evk. And make the changes
there.
You will need to know what kind of memory is embedded. Hyper flash or QSPI
Ahh, I didn't know what you were refering to by "post file". I understand now.
This should really be documented somewhere in our own docs, as I understand
this should work with mainline openocd.
Maybe this approach could be extended so that the number of tasks states is also
obtained and does
Hello,
My name is Vadim. I am new to NuttX and to the embedded world in general. I am
trying to compile NuttX nshocram configuration for IMXRT1064-EVK board using
1060 configuration with changes to flash-ocram.ld and imxrt_flexspi_nor_boot.h.
In imxrt_flexspi_nor_boot.h, I changed
Our in-house build system has a modified configure.sh that allows #include
directives
in defconfig files and subsequent entries to override the inherited config
vars, like this:
~/nuttx/boards/arm/stm32l4/haltian-example-board/configs/nsh-dbg$ cat defconfig
#include "../nsh/defconfig"
#
> This is what I tried and works. This is much better than being forced
> to use a specific configuration to get the offsets right or having to rebuild
> openocd each time.
> I will polish the approach and open a draft PR to show how it works.
As I said above, you don't have to do that. The
I wonder if we could automate that? Instead of separate debug vs
production configurations, could not configure.sh/c just create a debug
configuration by disabling optimization, enabling symbols, enabling
debug features, assertions, basic error and warning output?
Of course specialize
Hi,
sorry for mixing up the discussions. Also, maybe I wasn't clear from my last
email, what I did
was to try my second suggestion about adding symbols to NuttX to store the
offsets of the
required elements of the tcb. This is what I tried and works. This is much
better than being forced
to use
Perfect! Let's do this as time permits.
-Original Message-
From: Alan Carvalho de Assis [mailto:acas...@gmail.com]
Sent: Monday, November 23, 2020 5:09 AM
To: dev@nuttx.apache.org
Subject: Re: Should TASK_NAME_SIZE be changed in most configs?
Yes, I think nsh-debug will make its
Yes, I think nsh-debug will make its intention clear.
On 11/23/20, Gregory Nutt wrote:
> It has always been the policy to disable debug features in all shipped
> configurations. They were considered production configurations not
> debug configurations.
>
> Configurations that have debug enable
It has always been the policy to disable debug features in all shipped
configurations. They were considered production configurations not
debug configurations.
Configurations that have debug enable could, perhaps, be named like
nsh-debug.
On 11/23/2020 5:38 AM, Alan Carvalho de Assis
I think we need to have a good compromise between features and size.
For instance, the default "nsh" demo should be small, basically just
the terminal and minimum support to its commands to work, like the
PROCFS to get 'free' working.
Also keep in mind that for debugging purpose we need to
> Do you think this is due to the
I would say so.
I agree better debugging out of the box is a good way to go. We have to
weigh that against the past goal of: Minimum size image. It was a first
impression thing. This was why debug had to be tuned off in all Kconfig.
The first question to
Sounds good. Will be testing on some hardware as well when the RC is cut.
On Mon, Nov 23, 2020 at 2:20 AM Brennan Ashton
wrote:
>
> I am looking to cut the RC0 early this week. There have been a lot of
> bug fixes that have gone in in the last few weeks (almost 60 patched
> backported), and I
24 matches
Mail list logo
