Re: Re: d_len/d_buf arbitration for s32k1xx_flexcan

[Carlos Sanchez]

Hi Peter,

I have submitted a PR with a couple of fixes to s32k1xx_flexcan.c:
https://github.com/apache/nuttx/pull/8058

Among those, there is a fix to MAXMB field initialization in MCR. The
effects of that wrong init is the HW will use mailboxes the driver does not
configure nor check, causing RX data loss. This use gets more frequent as
the CAN frame arrival rate overcomes the interrupt handler frequency, as
the first mailboxes are not empty. I am wondering if this might have
affected your measurements when you decided not to use a work queue for RX
because you observed frame loss.

As I do not have the means to test heavy CAN traffic flow, I am just
pointing it to you. In my code, I have changed to a work queue based RX and
I have seen no problems so far (but IMHO it would be wiser to retest on
whatever setup you detected the frame loss originally).

BR

Carlos

On Wed, Jan 4, 2023 at 1:37 PM Peter van der Perk 
wrote:

> Hi,
>
> It seems that calling can_input directly from IRQ got broken since the IOB
> rewrite.
> Before can_input only used dev->d_appdata, but now can_input overwrites
> the dev->d_buf pointer as well.
>
> https://github.com/apache/nuttx/blob/779a610ca3ba495640b49d6c36bce89784955e0d/net/can/can_input.c#L231
> dev-
> >d_len
> always has been fixed to sizeof(struct can_frame) or sizeof(struct
> canfd_frame) depending on kconfig setting.
>
> Once the whole IOB rewrite gets in, is mature and is fully documented I
> can took a look at the mechanism again.
>
> Short term you could either go back to an older version of NuttX, or try
> to schedule the workqueue for can_input and see if you can enough
> throughput.
>
> Yours sincerely,
>
> Peter van der Perk
>
> -Original Message-
> From: raiden00pl 
> Sent: Wednesday, January 4, 2023 10:01 AM
> To: dev@nuttx.apache.org
> Subject: Re: d_len/d_buf arbitration for s32k1xx_flexcan
>
> Related issue:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fnuttx%2Fissues%2F5142&data=05%7C01%7Cpeter.vanderperk%40nxp.com%7C99afe46e15344b2883eb08daee32418c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C638084196858222395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HIk%2Fza58GP94ZSc1ANtynWEz3fD3o6PV05Kv90ORYig%3D&reserved=0
> .
> Not using a work queue to handle CAN RX is basically wrong. Unfortunately
> all NXP SocketCAN drivers are affected.
>
> wt., 3 sty 2023 o 19:38 Xiang Xiao  napisał(a):
>
> >   Sorry, "you must do..." may confuse you. What I mean is the CAN driver.
> >
> > On Wed, Jan 4, 2023 at 2:30 AM Carlos Sanchez
> >  wrote:
> >
> > > Hi Xiang,
> > >
> > > Please note what I describe is not caused by my code using multiple
> > > threads, but is happening on Nuttx upstream. My code is single
> > > threaded, but s32k1xx_flexcan driver (and several other Socket CAN
> > > drivers as they all seem to be derived from the same code base) does
> > > some things on the thread I call write() from, and some other things
> > > on CANWORK work queue thread.
> > > My understanding is that net code is structured so work queue
> > > threads are used, generally, but in Socket CAN drivers this was
> > > "waived" to avoid
> > data
> > > loss, causing the problem I describe.
> > >
> > > Thanks,
> > >
> > > Carlos
> > >
> > > On Tue, Jan 3, 2023 at 6:56 PM Xiang Xiao
> > > 
> > > wrote:
> > >
> > > > Since tx/rx share the same d_len/d_buf, you must do send/recv in
> > > > one
> > and
> > > > only thread(either by system work thread or driver dedicated
> > > > thread) to avoid the race condition you describe below.
> > > >
> > > > On Wed, Jan 4, 2023 at 1:45 AM Carlos Sanchez
> > > >  wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > I am observing an extrange behavior: under heavy-error CAN TX
> > scenario
> > > > (no
> > > > > acks so TX fails always), usually after the second call to
> > > > > write() my writes fail. This is expected as s32k1xx_flexcan has
> > > > > two TX mailboxes
> > > and
> > > > > from my understanding of the code there is no other buffering
> > > > > (on
> > this
> > > > > specific CAN driver at least).
> > > > >
> > > > > However, if I enable CAN errors, and depending on runtime sync
> > > conditions
> > > > > (basically, if I put a breakpoint on s32k1xx_txpoll) then all
> > > > > the
> > > writes
> > > > > after the first silently fail, without really trying to send
> > > > > anything
> > > (I
> > > > > see on ESR2 register than second TX mailbox does not really
> > > > > become
> > > > active).
> > > > >
> > > > > After some debugging, I have seen that the CANWORK=LPWORK thread
> > > > > has scheduled calls to s32k1xx_error_work, overwrites
> > > > > d_buf/d_len to send
> > > the
> > > > > error frames in. But TX polling does not always happen in
> > > > > CANWORK
> > > thread:
> > > > > it does when it comes from s32

Re: Problem with exported lib

[Roberto Bucher]

Thanks Gustavo

sorry for late replay..

Why are not all these flags and the correct ld.tmp files exported when 
we generate the nuttx-export file?


It will be corrected in the future or do we modify our files that 
automatically generate nuttx binaries to this?


Thanks again

Roberto


On 1/5/23 14:52, Gustavo Henrique Nihei wrote:

Hi Roberto,

Since https://github.com/apache/nuttx/pull/7208 the NuttX build system
preprocesses every linker script file of a given configuration.
We've recently updated the makefiles and linker scripts of every supported
chip from the ESP32 family to benefit from this.
So you may need to update your out-of-tree build system to also preprocess
each linker script file (e.g. using "-E" argument from GCC) and pass the
output files to xtensa-esp32-elf-ld.
Notice that you'll need to provide all the include paths to GCC so that it
is able to find the headers required at the processing phase.

As a reference, if you build "esp32-devkitc:nsh" with "make V=1", you'll
notice that for each ".ld" file the build system will generate a new one
suffixed with ".ld.tmp", which are the ones to be passed to the Linker:


*CPP:
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/esp32_rom.ld->
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/esp32_rom.ld.tmp

xtensa-esp32-elf-gcc -E -P -x c -isystem
/home/nihei/Projects/NuttX/nuttx/include -D__NuttX__ -DNDEBUG -D__KERNEL__
  -I /home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/chip -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/common -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/lx6 -I
/home/nihei/Projects/NuttX/nuttx/sched
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/esp32_rom.ld
-o
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/esp32_rom.ld.tmp*


*CPP:
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/flat_memory.ld->
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/flat_memory.ld.tmpxtensa-esp32-elf-gcc
-E -P -x c -isystem /home/nihei/Projects/NuttX/nuttx/include -D__NuttX__
-DNDEBUG -D__KERNEL__  -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/chip -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/common -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/lx6 -I
/home/nihei/Projects/NuttX/nuttx/sched
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/flat_memory.ld
-o
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/flat_memory.ld.tmp*


*CPP:
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/legacy_sections.ld->
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/legacy_sections.ld.tmp

xtensa-esp32-elf-gcc -E -P -x c -isystem
/home/nihei/Projects/NuttX/nuttx/include -D__NuttX__ -DNDEBUG -D__KERNEL__
  -I /home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/chip -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/common -I
/home/nihei/Projects/NuttX/nuttx/arch/xtensa/src/lx6 -I
/home/nihei/Projects/NuttX/nuttx/sched
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/legacy_sections.ld
-o
  
/home/nihei/Projects/NuttX/nuttx/boards/xtensa/esp32/esp32-devkitc/../common/scripts/legacy_sections.ld.tmp*

Best regards,
Gustavo.

On Thu, Jan 5, 2023 at 4:31 AM Roberto Bucher 
wrote:


Hi

I have a new configuration for an Olimex-ESP32-PoE board. I can compile
and build the nuttx flash without problems.

I did a

make export

and putted the generated nuttx-export folder into another project
(pysimCoder). The Makefile of the project, which correctly works with my
STM32 boards, fails the compilation of the image for esp32 with this
strange message:


xtensa-esp32-elf-ld -nostdlib --gc-sections --cref
-Map=/home/bucher/sviluppo/NUTTX/nuttx/nuttx.map -L
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/libs
--entry=__start  -T
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/esp32_rom.ld

-T
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flat_memory.ld

-T
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/legacy_sections.ld

\
-o ../test  \
nuttx_main.o test.o  nuttx_main-builtintab.o
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/lib/libpyblk.a --start-group
-lsched -ldrivers -lboards -lc -lmm -larch -lxx -lapps -lnet -lfs
-lbinfmt -lwireless -lboard -lboard
/home/bucher/sviluppo/GITHUB/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/libgcc.a

--end-group
*xtensa-esp32-elf-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flat_memory.ld:32:

ignoring invalid character `#' in expression**
**xtensa-esp32-elf-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flat_memory.ld:32:

syntax error**
**make: *** [Makefile:133: ../test] Error