RE: Nuttx Task Trace

2021-01-07 Thread Yuuichi.A.Nakamura 
Dear Sebastian,

> NuttX/nuttx/include/sys/syscall_lookup.h:350:18: error: attempt to use 
> poisoned "getenv"

PX4 project seems to prohibit some APIs by using GCC #pragma in 
src/include/visibility.h
#pragma GCC poison getenv setenv putenv

Because NuttX Task Trace creates wrappers for all APIs to get syscall trace, 
the prohibited APIs by pragma will be used.
If you have no need to use syscall trace, removing 
“CONFIG_SCHED_INSTRUMENTATION_SYSCALL=y” may solve the problem.
Or, the PX4 project build system may should be fixed not to include 
visibility.h when compiling the NuttX kernel code.
Anyway, basically it seems the matter of PX4 project. I’m not familiar with the 
project, sorry.

Thanks,
Yuuichi Nakamura


From: Sebastian Glatz 
Sent: Thursday, January 7, 2021 11:00 PM
To: dev@nuttx.apache.org
Cc: Nakamura, Yuuichi (Sony) 
Subject: Re: Nuttx Task Trace

Dear Yuuichi
I have changed the configuration by invoking: make px4_fmu-v5_default menuconfig
The corresponding configfile is: 
PX4-Autopilot/boards/px4/fmu-v5/nuttx-config/nsh/defconfig
With these changes:
+CONFIG_DRIVER_NOTE=y
+CONFIG_DRIVER_NOTECTL=y
-CONFIG_SCHED_INSTRUMENTATION_EXTERNAL=y
+CONFIG_SCHED_INSTRUMENTATION_FILTER=y
+CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER=y
+CONFIG_SCHED_INSTRUMENTATION_SYSCALL=y
-CONFIG_SCHED_WAITPID=y
+CONFIG_SYSTEM_SYSTEM=y
+CONFIG_SYSTEM_TRACE=y
Then when I build the target: make px4_fmu-v5_default
I would get errors in the autogenerated code, such as:
NuttX/nuttx/include/sys/syscall_lookup.h:350:18: error: attempt to use poisoned 
"getenv"
If you have any ideas what I could try, please let me know.

Thank you,
Sebastian

On Tue, Jan 5, 2021 at 8:33 AM 
mailto:yuuichi.a.nakam...@sony.com>> wrote:
Hi Sebastian,

I had mainly tested NuttX Task Trace with spresense:nsh and maix-bit:nsh.
I confirmed the feature by the latest source code by changing the following 
configs and found that it still works.
If possible, would you share the configuration to get the error ?

diff boards/arm/cxd56xx/spresense/configs/nsh/defconfig 
boards/arm/cxd56xx/spresense/configs/nsh-trace/defconfig
28a29,30
> CONFIG_DRIVER_NOTE=y
> CONFIG_DRIVER_NOTECTL=y
45c47,50
< CONFIG_SCHED_WAITPID=y
---
> CONFIG_SCHED_INSTRUMENTATION=y
> CONFIG_SCHED_INSTRUMENTATION_FILTER=y
> CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER=y
> CONFIG_SCHED_INSTRUMENTATION_SYSCALL=y
52a58,59
> CONFIG_SYSTEM_SYSTEM=y
> CONFIG_SYSTEM_TRACE=y

Thanks,
Yuuichi Nakamura

-Original Message-
From: Sebastian Glatz 
mailto:sebastian.gl...@voliro.com>>
Sent: Wednesday, December 30, 2020 9:49 PM
To: dev@nuttx.apache.org
Subject: Nuttx Task Trace

Hi all,

I want to set up *NuttX Task Trace *to profile and debug performance related 
issues of our PX4 modification.

For that I have followed this description:
https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html#nuttx-kernel-configuration
I have edited the .config file. I tried it for both the PX4 project (running on 
Pixhawk 4) and a plain STM32 blink LED app (running on STM32 Blue Pill). 
Neither would build with those kernel configurations in place.

I would get make errors like this:
make[3]: Entering directory '~/nuttx/apps/system/trace'
CC: trace.c
:0:6: error: expected identifier or '(' before numeric constant

Has someone successfully used NuttX Task Trace? How did you proceed?
Also does anyone have some comments on my error message?

Best,
Seb


--
[Voliro AG]
Sebastian Glatz
Robotics Engineer | Voliro AG
phone:  +41 44 632 41 92
mobile:
site:  www.voliro.com
address:  Weinbergstrasse 35, 8092 Zurich - Switzerland
[https://storage.googleapis.com/voliro.com/linkedin.png]
[https://storage.googleapis.com/voliro.com/youtube.png]
[https://storage.googleapis.com/voliro.com/instagram.png]

IMPORTANT: The contents of this email and any attachments are confidential. It 
is strictly forbidden to share any part of this message with any third party, 
without a written consent of the sender. If you received this message by 
mistake, please reply to this message and follow with its deletion, so that we 
can ensure such a mistake does not occur in the future.

Re: SPI Driver Balkanization

2021-01-07 Thread Brennan Ashton 
On Thu, Jan 7, 2021 at 9:51 PM Grr  wrote:
>
> It is abstracted, for example see this file.
>
> >
> > https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
> >
>
> You mean  GPIO_MCP2515_CS? I don't quite understand its definition
>
> #define GPIO_MCP2515_CS   (GPIO_OUTPUT|GPIO_OTYPER_PP(0)|GPIO_SPEED_2MHz|\
>GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)
>
> I guess it's a way to combine different configuration bits with pin 4.
>
> Problem is it's only defined for pin 4 and only in a handful of STM32
> boards.

This is board and arch specific and cannot be more generalized than that.
They will have different requirements for pullups, speed, etc.  The define
should also start with BOARD_ but some use GPIO_.  This is the case
for all PINs including UART, GPIO, SPI, USB, etc...

Most systems besides SPI or GPIO you wont have to directly pass this
pin config you just define something like

#define BOARD_UART_0_TX_PIN (GPIO_INPUT | GPIO_PULLUP | GPIO_FUNC_UART
| GPIO_PIN16)
#define BOARD_UART_1_RX_PIN (GPIO_INPUT | GPIO_PULLUP | GPIO_FUNC_UART
| GPIO_PIN3)

and the drivers will already have conditionals on those being defined.

SPI is just a little special because you dont _need_ a CS gpio pin,
but frequently you want it.  So you end up with the board specific hooks
for what pin to turn on.
as is here
https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140

SPI drivers cannot depend on a fixed name for the CS pin because you may
have multiple instances (what I thought you were asking to support)

>
> What happens if I want to use that driver with a PIC32MX board and I'm not
> a kernel developer?
> What happens if pin 4 is already used and I *need* to use pin 5 and again
> I'm not a kernel developer?

You just update the define in your board.h file to include a mapping for what
is wired up to pin 5.  When you are bringing up your board one of the first
things you should do is define the pins in your board.h

>
> My idea is to bring that level of configuration ability into menuconfig
>
> Are those GPIO_* macros work across architectures so they can be brought to
> menuconfig and combined there in a newbie-friendly way? It seems
> GPIO_OUTPUT exists in all architectures but I don't know it if works the
> same way everywhere

Changing how pins are defined would break everyone so that is unlikely to
change, and it is also not really something that can easily be mapped to
Kconfig.

You already have to add the initialization logic and this is just
another step in that.

--Brennan

Re: SPI Driver Balkanization

2021-01-07 Thread Grr 
It is abstracted, for example see this file.

>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>

You mean  GPIO_MCP2515_CS? I don't quite understand its definition

#define GPIO_MCP2515_CS   (GPIO_OUTPUT|GPIO_OTYPER_PP(0)|GPIO_SPEED_2MHz|\
   GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)

I guess it's a way to combine different configuration bits with pin 4.

Problem is it's only defined for pin 4 and only in a handful of STM32
boards.

What happens if I want to use that driver with a PIC32MX board and I'm not
a kernel developer?
What happens if pin 4 is already used and I *need* to use pin 5 and again
I'm not a kernel developer?

My idea is to bring that level of configuration ability into menuconfig

Are those GPIO_* macros work across architectures so they can be brought to
menuconfig and combined there in a newbie-friendly way? It seems
GPIO_OUTPUT exists in all architectures but I don't know it if works the
same way everywhere

Re: SPI Driver Balkanization

2021-01-07 Thread Brennan Ashton 
On Thu, Jan 7, 2021 at 8:20 PM Grr  wrote:
>
> I've been working towards creating a unified (character or SocketCAN)
> driver model for SPI CAN controller MCP2515 and I found out that SPI_*
> macro family allow platform-neutral SPI device control but there's one
> thing I cannot find:
>
> Is it possible to abstract chip select (CS) definition and usage in a
> similar way?

It is abstracted, for example see this file.
https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140

There is a case for each device on the SPI bus and with that the driver.

>
> Question arises from the fact that most SPI drivers are initialized (and
> *de facto supported*) per board but many (if not most) boards offer SPI
> external connectivity so any *collection* of SPI devices can be connected
> to any such board
>
> Since most drivers are initialized *per board*, any given *supported*
> device cannot be used in any given board without initialization being
> "ported" to that board, something a basic user cannot do

The MCP2515 dynamically allocates so this is not a problem:
https://github.com/apache/incubator-nuttx/blob/c8ff295d59c0360943abcaf19177cd0556f37f47/drivers/can/mcp2515.c#L2529

The problem here is that it hard codes the chip select:
https://github.com/apache/incubator-nuttx/blob/c8ff295d59c0360943abcaf19177cd0556f37f47/drivers/can/mcp2515.c#L333

This number (0) should be held by the driver structure and passed in
at instantiation time.  This would be a welcome change.
Then you can in your boards spi logic I mentioned above have
SPIDEV_CANBUS(0)
and
SPIDEV_CANBUS(1)
and this will all just settle out.


Does this address your concern?

--Brennan

SPI Driver Balkanization

2021-01-07 Thread Grr 
I've been working towards creating a unified (character or SocketCAN)
driver model for SPI CAN controller MCP2515 and I found out that SPI_*
macro family allow platform-neutral SPI device control but there's one
thing I cannot find:

Is it possible to abstract chip select (CS) definition and usage in a
similar way?

Question arises from the fact that most SPI drivers are initialized (and
*de facto supported*) per board but many (if not most) boards offer SPI
external connectivity so any *collection* of SPI devices can be connected
to any such board

Since most drivers are initialized *per board*, any given *supported*
device cannot be used in any given board without initialization being
"ported" to that board, something a basic user cannot do

Another related problem (discussed between Gregory Nutt and Sebastien
Lorquet in
https://nuttx.yahoogroups.narkive.com/7qv88uHr/proposal-support-multiple-spi-devices-of-same-type)
is support of multiple similar devices in the same bus

The solution to problem A is to have an abstraction mechanism for CS that
can be used not only in driver code but in menuconfig so user is able to
configure any possible combination of boards and *external* busses and
devices to exploit NuttX device support.

Is there or could be such abstraction mechanism to complement SPI_*?

For problem B, I've seen hints in Bob Feretich's ADXL372 driver but
couldn't find use of it to learn how. I've seen device IDs have an index
but I still don't know how its used

Any hint or opinion is greatly appreciated

TIA

Grr

Re: Handling of newbie-oriented fixes

2021-01-07 Thread Grr 
I just finished basic edition but my connection is veeery slow right now so
I'll upload it until tomorrow morning

I incorporated the ASCII function map and completely linearized the document

I need to check the last part about nsh and such but the rest of the
document is exact and up to date



El mié, 6 ene 2021 a las 2:23, Brennan Ashton ()
escribió:

> On Tue, Jan 5, 2021 at 2:46 PM Grr  wrote:
> >
> > Thank you for your response. I'll check that
> I assume that this is your github user https://github.com/sigdl  If
> that is the case
> you can create your PR against the Apache repo with this link:
> https://github.com/apache/incubator-nuttx/compare/master...sigdl:master
>
> >
> > I also offered a function map to add to your
> NuttX+Initialization+Sequence
> > document
> >
> > Please check
> https://www.mail-archive.com/dev@nuttx.apache.org/msg05417.html
> > and let me know if it's useful or how can it be improved to be so
>
> Sorry I had forgotten to respond, eventually I think most of that Wiki
> will make its way into
> the documentation over at nuttx.apache.org/docs/latest but that will
> take quite some
> time, so keeping the wiki up to date would be most welcome.  If you create
> an
> account and send me the username I will be happy to give you
> permissions to edit that
> page as you think it makes sense.
>
> --Brennan
>

Re: Nuttx Task Trace

2021-01-07 Thread Sebastian Glatz 
Dear Yuuichi

I have changed the configuration by invoking: make px4_fmu-v5_default
menuconfig
The corresponding configfile is:
PX4-Autopilot/boards/px4/fmu-v5/nuttx-config/nsh/defconfig
With these changes:
+CONFIG_DRIVER_NOTE=y
+CONFIG_DRIVER_NOTECTL=y
-CONFIG_SCHED_INSTRUMENTATION_EXTERNAL=y
+CONFIG_SCHED_INSTRUMENTATION_FILTER=y
+CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER=y
+CONFIG_SCHED_INSTRUMENTATION_SYSCALL=y
-CONFIG_SCHED_WAITPID=y
+CONFIG_SYSTEM_SYSTEM=y
+CONFIG_SYSTEM_TRACE=y

Then when I build the target: make px4_fmu-v5_default
I would get errors in the autogenerated code, such as:
NuttX/nuttx/include/sys/syscall_lookup.h:350:18: error: attempt to use
poisoned "getenv"

If you have any ideas what I could try, please let me know.

Thank you,
Sebastian

On Tue, Jan 5, 2021 at 8:33 AM  wrote:

> Hi Sebastian,
>
> I had mainly tested NuttX Task Trace with spresense:nsh and maix-bit:nsh.
> I confirmed the feature by the latest source code by changing the
> following configs and found that it still works.
> If possible, would you share the configuration to get the error ?
>
> diff boards/arm/cxd56xx/spresense/configs/nsh/defconfig
> boards/arm/cxd56xx/spresense/configs/nsh-trace/defconfig
> 28a29,30
> > CONFIG_DRIVER_NOTE=y
> > CONFIG_DRIVER_NOTECTL=y
> 45c47,50
> < CONFIG_SCHED_WAITPID=y
> ---
> > CONFIG_SCHED_INSTRUMENTATION=y
> > CONFIG_SCHED_INSTRUMENTATION_FILTER=y
> > CONFIG_SCHED_INSTRUMENTATION_IRQHANDLER=y
> > CONFIG_SCHED_INSTRUMENTATION_SYSCALL=y
> 52a58,59
> > CONFIG_SYSTEM_SYSTEM=y
> > CONFIG_SYSTEM_TRACE=y
>
> Thanks,
> Yuuichi Nakamura
>
> -Original Message-
> From: Sebastian Glatz 
> Sent: Wednesday, December 30, 2020 9:49 PM
> To: dev@nuttx.apache.org
> Subject: Nuttx Task Trace
>
> Hi all,
>
> I want to set up *NuttX Task Trace *to profile and debug performance
> related issues of our PX4 modification.
>
> For that I have followed this description:
>
> https://nuttx.apache.org/docs/latest/guides/tasktraceuser.html#nuttx-kernel-configuration
> I have edited the .config file. I tried it for both the PX4 project
> (running on Pixhawk 4) and a plain STM32 blink LED app (running on STM32
> Blue Pill). Neither would build with those kernel configurations in place.
>
> I would get make errors like this:
> make[3]: Entering directory '~/nuttx/apps/system/trace'
> CC: trace.c
> :0:6: error: expected identifier or '(' before numeric
> constant
>
> Has someone successfully used NuttX Task Trace? How did you proceed?
> Also does anyone have some comments on my error message?
>
> Best,
> Seb
>


-- 
[image: Voliro AG]

Sebastian Glatz
Robotics Engineer | Voliro AG
phone:  +41 44 632 41 92 <+41+44+632+41+92>
mobile:
site:  www.voliro.com
address:  Weinbergstrasse 35, 8092 Zurich - Switzerland



IMPORTANT: The contents of this email and any attachments are confidential.
It is strictly forbidden to share any part of this message with any third
party, without a written consent of the sender. If you received this
message by mistake, please reply to this message and follow with its
deletion, so that we can ensure such a mistake does not occur in the
future.

Re: Error in sninfo with argument

2021-01-07 Thread spudaneco 
You really need to analyze the hard fault to have any understanding.  My guess 
would be something unrelated like a stack overrun.Sent from my Galaxy
 Original message From: Alan Carvalho de Assis 
 Date: 1/7/21  6:15 AM  (GMT-06:00) To: 
dev@nuttx.apache.org, thiha_...@yahoo.com Subject: Re: Error in sninfo with 
argument Hi Thiha,Well, if this is a configuration issue, then it is better to 
use apre-defined board configuration, in this case you can look 
at:boards/arm/stm32/stm32f103-minimum/configs/rfid-rc522I never saw this type 
of crash on "syslog" before.Also save the current .config that is crashing, 
later you will able tocompare it with the working config to understand why it 
was crashing.Maybe the crash it not related to "syslog", but it is in some 
linejust below the syslog() line.BR,AlanOn 1/7/21, Thiha Kyaw 
 wrote:> Dear Nuttx,>> I did a bit more debugging in 
NuttX-10.0.1 on STM32F4Discovery.>> I add a below line in stm32_bringup.c to 
make sure that syslog function> with argument.>> syslog(LOG_INFO, "INFO: 
stm32_mfrc522initialize() : %d \n", 10);>> Error is as follow.>> NuttShell 
(NSH) NuttX-10.0.1> nsh> ABCDF> INFO: stm32_mfrc522initialize() : 
arm_hardfault: PANIC!!! Hard fault: ABCDF>> I believe I need to set some 
settings in menuconfig. Please guide me how to> solve the syslog issue.>> 
syslog is important to do the debugging.>> Thanks.>> Regards,> Thiha Kyaw> 
On Sat, Jan 2, 2021 at 11:52 PM Thiha Kyaw  wrote:>>> Dear 
Alan, I use NuttShell (NSH) NuttX-10.0.0. Board is STM32F4Discovery 
(STM32F407G-DISC1). Regards,>> Thiha Kyaw On Sat, Jan 2, 2021 at 11:15 
PM Alan Carvalho de Assis>> >> wrote:> Hi Thiha,>> 
Thank you for reporting this issue.>> Could you please supply more 
information?>> What NuttX version are you using? Is it from mainline? If 
so, did you>>> get this same issue using NuttX 10.0 or 9.1 ?>> BR,>> 
Alan>> On 1/2/21, Thiha Kyaw  wrote:>>> > Dear 
Nuttx,>>>  > I am facing the problem in sensor debugging.>>>  > Simple 
debug print using sninfo is working well.>>>  > But sninfo with argument 
throws *arm_hardfault: PANIC!!!*>>>  > For example,>>> > 
sninfo("ADXL372_FIFO_CTL = 0x%02x\n", reg_content);>>>  > Is there any 
missing configuration?>>>  > [image: image.png]>>>  > Please guide 
me.>>>  > Thanks.>>> > -->>> > Yours Sincerely,>>> > Thiha Kyaw>>> 
>> -->> Yours Sincerely,>> Thiha Kyaw> --> Yours Sincerely,> Thiha 
Kyaw>

Re: Error in sninfo with argument

2021-01-07 Thread Alan Carvalho de Assis 
Hi Thiha,

Well, if this is a configuration issue, then it is better to use a
pre-defined board configuration, in this case you can look at:
boards/arm/stm32/stm32f103-minimum/configs/rfid-rc522

I never saw this type of crash on "syslog" before.

Also save the current .config that is crashing, later you will able to
compare it with the working config to understand why it was crashing.

Maybe the crash it not related to "syslog", but it is in some line
just below the syslog() line.

BR,

Alan

On 1/7/21, Thiha Kyaw  wrote:
> Dear Nuttx,
>
> I did a bit more debugging in NuttX-10.0.1 on STM32F4Discovery.
>
> I add a below line in stm32_bringup.c to make sure that syslog function
> with argument.
>
> syslog(LOG_INFO, "INFO: stm32_mfrc522initialize() : %d \n", 10);
>
> Error is as follow.
>
> NuttShell (NSH) NuttX-10.0.1
> nsh> ABCDF
> INFO: stm32_mfrc522initialize() : arm_hardfault: PANIC!!! Hard fault: ABCDF
>
> I believe I need to set some settings in menuconfig. Please guide me how to
> solve the syslog issue.
>
> syslog is important to do the debugging.
>
> Thanks.
>
> Regards,
> Thiha Kyaw
>
>
>
>
> On Sat, Jan 2, 2021 at 11:52 PM Thiha Kyaw  wrote:
>
>> Dear Alan,
>>
>> I use NuttShell (NSH) NuttX-10.0.0.
>>
>> Board is STM32F4Discovery (STM32F407G-DISC1).
>>
>> Regards,
>> Thiha Kyaw
>>
>> On Sat, Jan 2, 2021 at 11:15 PM Alan Carvalho de Assis
>> 
>> wrote:
>>
>>> Hi Thiha,
>>>
>>> Thank you for reporting this issue.
>>>
>>> Could you please supply more information?
>>>
>>> What NuttX version are you using? Is it from mainline? If so, did you
>>> get this same issue using NuttX 10.0 or 9.1 ?
>>>
>>> BR,
>>>
>>> Alan
>>>
>>> On 1/2/21, Thiha Kyaw  wrote:
>>> > Dear Nuttx,
>>> >
>>> > I am facing the problem in sensor debugging.
>>> >
>>> > Simple debug print using sninfo is working well.
>>> >
>>> > But sninfo with argument throws *arm_hardfault: PANIC!!!*
>>> >
>>> > For example,
>>> > sninfo("ADXL372_FIFO_CTL = 0x%02x\n", reg_content);
>>> >
>>> > Is there any missing configuration?
>>> >
>>> > [image: image.png]
>>> >
>>> > Please guide me.
>>> >
>>> > Thanks.
>>> > --
>>> > Yours Sincerely,
>>> > Thiha Kyaw
>>> >
>>>
>>
>>
>> --
>> Yours Sincerely,
>> Thiha Kyaw
>>
>
>
> --
> Yours Sincerely,
> Thiha Kyaw
>

Re: Error in sninfo with argument

2021-01-07 Thread Thiha Kyaw 
Dear Nuttx,

I did a bit more debugging in NuttX-10.0.1 on STM32F4Discovery.

I add a below line in stm32_bringup.c to make sure that syslog function
with argument.

syslog(LOG_INFO, "INFO: stm32_mfrc522initialize() : %d \n", 10);

Error is as follow.

NuttShell (NSH) NuttX-10.0.1
nsh> ABCDF
INFO: stm32_mfrc522initialize() : arm_hardfault: PANIC!!! Hard fault: ABCDF

I believe I need to set some settings in menuconfig. Please guide me how to
solve the syslog issue.

syslog is important to do the debugging.

Thanks.

Regards,
Thiha Kyaw




On Sat, Jan 2, 2021 at 11:52 PM Thiha Kyaw  wrote:

> Dear Alan,
>
> I use NuttShell (NSH) NuttX-10.0.0.
>
> Board is STM32F4Discovery (STM32F407G-DISC1).
>
> Regards,
> Thiha Kyaw
>
> On Sat, Jan 2, 2021 at 11:15 PM Alan Carvalho de Assis 
> wrote:
>
>> Hi Thiha,
>>
>> Thank you for reporting this issue.
>>
>> Could you please supply more information?
>>
>> What NuttX version are you using? Is it from mainline? If so, did you
>> get this same issue using NuttX 10.0 or 9.1 ?
>>
>> BR,
>>
>> Alan
>>
>> On 1/2/21, Thiha Kyaw  wrote:
>> > Dear Nuttx,
>> >
>> > I am facing the problem in sensor debugging.
>> >
>> > Simple debug print using sninfo is working well.
>> >
>> > But sninfo with argument throws *arm_hardfault: PANIC!!!*
>> >
>> > For example,
>> > sninfo("ADXL372_FIFO_CTL = 0x%02x\n", reg_content);
>> >
>> > Is there any missing configuration?
>> >
>> > [image: image.png]
>> >
>> > Please guide me.
>> >
>> > Thanks.
>> > --
>> > Yours Sincerely,
>> > Thiha Kyaw
>> >
>>
>
>
> --
> Yours Sincerely,
> Thiha Kyaw
>


-- 
Yours Sincerely,
Thiha Kyaw