NuttX 10.3 release plan
Hi all, Our latest release (NuttX 10.2) was on 2021-11-28. I think that we can remove the DISCLAIMER and start the release process for 10.3 on the following schedule W10 -- Master Stability Window (keep the merging of risky PRs to a minimum this week) W11.2 -- Create the 10.2 release branch W11.2-13.1 -- Stabilize / test / release notes W13.1 -- Tag RC0 and call for PPMC / Community Vote W14(or when we have the votes) Call for IPMC Vote W14.6 -- Update site and announce (we have to wait for download mirrors to sync). Best regards Alin
Re: SPI problem
I reached to move a little forward by analyzing the SPI on the nucleo-144 STM32F7 board, and I found out that the problem is now in the calling of SPI_SELECT in the nuttx/drivers/spi/spi_transfer.c and the spi_transfer function. This are the values in the seq structure before launching the SPI_SELECT command. nsh> spi bus BUS EXISTS? Bus 0: NO Bus 1: NO Bus 2: YES Bus 3: NO nsh> spi exch -b2 -x4 aabbccdd Sending: AA BB CC DD seq -> dev: 0x17, mode: 3, nbits: 8, ntrans: 1, freq: 400 Received: FF FF FF FF To avoid the dump error I modified the seq->dev from 0x17 to 0x0004... It seems that the seq->dev value is not correct... Best regards Roberto On 3/6/22 13:47, Roberto Bucher wrote: Thanks Petro I've modified the nucleo-144/src/stm32_spi.c file by simply adding: struct spi_dev_s *g_spiX; and by adding spi_register(g_spiX, X); in the where X is the spi device number (in my example spi2) in the shell the /dev/spi2 is available. Best regards Roberto On 3/6/22 12:49, Petro Karashchenko wrote: Hello Roberto, I'm asking this because I examined nucleo-144 board source code and currently I do not see a "spi_register" call in board init files. So I assume that you have some modified code and it is very hard to make any conclusions while not seeing the code. Best regards, Petro нд, 6 бер. 2022 р. о 13:40 Petro Karashchenko пише: Hello Roberto, It would be good if you can dump assembly that is generated. What I see is that "intspi_register(FAR structspi_dev_s *spi, intbus)", so I'm assuming that R0 should be "spi" and R1 should be "bus", but in your dump "R0: 0001 R1: 2004e840" those seems to be inverted (0001 seems to be a "bus" and "2004e840" seems to be a "spi" pointer). The assembly code will show light on the dump that you provided. As an alternative you can provide the defconfig that you use if you are not using a custom board. Best regards, Petro нд, 6 бер. 2022 р. о 10:54 Roberto Bucher пише: When I enable some dubug configs I get the following error by enter in the serial shell: sert: Assertion failed at file:spi/spi_driver.c line: 358 arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800 R3: 20010684 arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370 FP: 20010670 arm_registerdump: R8: SB: SL: R11: arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad PC: 0800648e arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: 0004 arm_registerdump: EXC_RETURN: ffe9 arm_dump_stack: User Stack: On the line 358 of spi_driver.c there is this assertion: /* Sanity check */ DEBUGASSERT(spi != NULL && (unsigned)bus < 1000); Any Idea? Best regards Roberto
Re: nuttx lora sx127x device use for help
Set power to 14 Waiting for data sx127x_lora_isr0_process: ISR0: IRQ = 0x70 sx127x_lora_isr0_process: Invalid LORA RX data! On 3/7/2022 14:32，王国柱 wrote： Oh, sorry for the mistake in the email just now, the device running sx127x -r has been waiting for data Set power to 14 Waiting for data sx127x_lora_isr0_process: ISR0: IRQ = 0x70 sx127x_lora_isr0_process: Invalid LORA RX data! And the device that executes sx127x -t has been sending data, sx127x_write: buflen=5 sx127x_opmode_set: opmode_set 2->2 Sesx127x_lora_isr0_process: ISR0: IRQ = 0x08 sx127x_lora_isr0_process: WARNING: Interrupt not processed, opmode=2 nsx127x_isr0_process: Failed to process ISR0 -22 d sx127x_opmode_set: opmode_set 2->4 5 bytes sx127x_lora_isr0_process: ISR0: IRQ = 0x08 sx127x_opmode_set: opmode_set 4->2 wait 5 sec ... GPIO_SX127X_DIO0 is configured with PC1, how can I debug it now? #defineGPIO_SX127X_DIO0 (GPIO_INPUT|GPIO_FLOAT|GPIO_EXTI|GPIO_PORTC|GPIO_PIN1) On 3/4/2022 01:14，Alan Carvalho de Assis wrote： Yes, that is correct. Which pin did you use to receive interrupt (GPIO_SX127X_DIO0) ? Try to monitor this pin to see it changes status when other device transmit. Also you can double check if the other device is transmitting using a RTL-SDR device. BR, Alan On 3/3/22, Prelude wrote: When I use it, one device sends a command using 'sx127x -t', and the other receives a command using 'sx127x -r'. Look at the apps/examples/sx127x_demo/sx127x_demo.c，Is this OK? 回复的原邮件 | 发件人 | 王国柱 | | 日期 | 2022年03月03日 12:17 | | 收件人 | acas...@gmail.com | | 抄送至 | dev@nuttx.apache.org | | 主题 | Re: nuttx lora sx127x device use for help | I tested the two devices with an oscilloscope and both have signals, but there is no communication between the two devices. One is always sending data, and the other is waiting to receive data. Does the communication between the two devices need to be networked first? That's what it used to be, but I used two boards to execute sx127x -r on one of the boards and sx127x -t on the other, expecting communication between the two boards, but it didn't work as expected . Do you need any other configuration? the first board: nsh> sx127x -t Start sx127x_demo LORA modulation Set frequency to 93000 Set power to 14 Send 5 bytes the sencond boad: nsh> sx127x -r Start sx127x_demo LORA modulation Set frequency to 93000 Set power to 14 Waiting for data
Re: nuttx lora sx127x device use for help
Hi,Now the receiving section has been waiting for data, entering the interrupt, GPIO_SX127X_DIO0 is configured with PC1, how can I debug it now? #defineGPIO_SX127X_DIO0 (GPIO_INPUT|GPIO_FLOAT|GPIO_EXTI|GPIO_PORTC|GPIO_PIN1) sx127x_write: buflen=5 sx127x_opmode_set: opmode_set 2->2 Sesx127x_lora_isr0_process: ISR0: IRQ = 0x08 sx127x_lora_isr0_process: WARNING: Interrupt not processed, opmode=2 nsx127x_isr0_process: Failed to process ISR0 -22 d sx127x_opmode_set: opmode_set 2->4 5 bytes sx127x_lora_isr0_process: ISR0: IRQ = 0x08 sx127x_opmode_set: opmode_set 4->2 wait 5 sec ... On 3/4/2022 01:14，Alan Carvalho de Assis wrote： Yes, that is correct. Which pin did you use to receive interrupt (GPIO_SX127X_DIO0) ? Try to monitor this pin to see it changes status when other device transmit. Also you can double check if the other device is transmitting using a RTL-SDR device. BR, Alan On 3/3/22, Prelude wrote: When I use it, one device sends a command using 'sx127x -t', and the other receives a command using 'sx127x -r'. Look at the apps/examples/sx127x_demo/sx127x_demo.c，Is this OK? 回复的原邮件 | 发件人 | 王国柱 | | 日期 | 2022年03月03日 12:17 | | 收件人 | acas...@gmail.com | | 抄送至 | dev@nuttx.apache.org | | 主题 | Re: nuttx lora sx127x device use for help | I tested the two devices with an oscilloscope and both have signals, but there is no communication between the two devices. One is always sending data, and the other is waiting to receive data. Does the communication between the two devices need to be networked first? That's what it used to be, but I used two boards to execute sx127x -r on one of the boards and sx127x -t on the other, expecting communication between the two boards, but it didn't work as expected . Do you need any other configuration? the first board: nsh> sx127x -t Start sx127x_demo LORA modulation Set frequency to 93000 Set power to 14 Send 5 bytes the sencond boad: nsh> sx127x -r Start sx127x_demo LORA modulation Set frequency to 93000 Set power to 14 Waiting for data
Re: nuttx lora sx127x device use for help
I see! So, it is reporting a CRC error.
Do you have a low cost RTL-SDR? It could help you to identify what the
TX is sent incorrectly. This LoRa example was working fine. Could it
be some hardware issue?
BR,
Alan
On 3/7/22, 王国柱 wrote:
> Here is to judge whether the data is valid according to the interrupted
> attitude, and it is not realistic to add a print statement。
> nuttx\drivers\wireless\lpwan\sx127x\sx127x.c
>
>
> #ifdef CONFIG_LPWAN_SX127X_RXSUPPORT
> /* RX DONE */
>
>
> case SX127X_OPMODE_RX:
> case SX127X_OPMODE_RXSINGLE:
> {
> /* REVISIT: Always check PAYLOADCRCERR even CRCONPAYLOAD not set
> */
>
>
> if ((irq & SX127X_LRM_IRQ_PAYLOADCRCERR) != 0)
> {
> data_valid = false;
> }
>
>
> if (data_valid)
> {
> ret = sx127x_lora_rxhandle(dev);
> if (ret > 0)
> {
> if (dev->pfd)
> {
> /* Data available for input */
>
>
> dev->pfd->revents |= POLLIN;
>
>
> wlinfo("Wake up polled fd\n");
> nxsem_post(dev->pfd->sem);
> }
>
>
> /* Wake-up any thread waiting in recv */
>
>
> nxsem_post(&dev->rx_sem);
> }
> }
> else
> {
> /* RX Data invalid */
>
>
> wlinfo("Invalid LORA RX data!\n");
> }
> On 3/7/2022 18:02，Alan Carvalho de Assis wrote：
> Try to print the received data that generated the "Invalid LORA RX data"
>
> On Monday, March 7, 2022, 王国柱 wrote:
>
> Set power to 14
> Waiting for data
>
> sx127x_lora_isr0_process: ISR0: IRQ = 0x70
> sx127x_lora_isr0_process: Invalid LORA RX data!
>
>
>
>
>
> On 3/7/2022 14:32，王国柱 wrote：
> Oh, sorry for the mistake in the email just now, the device running sx127x
> -r has been waiting for data
> Set power to 14
> Waiting for data
>
> sx127x_lora_isr0_process: ISR0: IRQ = 0x70
> sx127x_lora_isr0_process: Invalid LORA RX data!
>
>
> And the device that executes sx127x -t has been sending data,
>
>
>
> sx127x_write: buflen=5
> sx127x_opmode_set: opmode_set 2->2
> Sesx127x_lora_isr0_process: ISR0: IRQ = 0x08
> sx127x_lora_isr0_process: WARNING: Interrupt not processed, opmode=2
> nsx127x_isr0_process: Failed to process ISR0 -22
> d sx127x_opmode_set: opmode_set 2->4
> 5 bytes
> sx127x_lora_isr0_process: ISR0: IRQ = 0x08
> sx127x_opmode_set: opmode_set 4->2
> wait 5 sec ...
>
>
>
>
>
>
> GPIO_SX127X_DIO0 is configured with PC1, how can I debug it now?
> #defineGPIO_SX127X_DIO0
> (GPIO_INPUT|GPIO_FLOAT|GPIO_EXTI|GPIO_PORTC|GPIO_PIN1)
>
>
>
>
> On 3/4/2022 01:14，Alan Carvalho de Assis wrote：
> Yes, that is correct.
>
> Which pin did you use to receive interrupt (GPIO_SX127X_DIO0) ?
>
> Try to monitor this pin to see it changes status when other device
> transmit. Also you can double check if the other device is
> transmitting using a RTL-SDR device.
>
> BR,
>
> Alan
>
> On 3/3/22, Prelude wrote:
> When I use it, one device sends a command using 'sx127x -t', and the other
> receives a command using 'sx127x -r'.
> Look at the apps/examples/sx127x_demo/sx127x_demo.c，Is this OK?
>
>
>
>
>
> 回复的原邮件
> | 发件人 | 王国柱 |
> | 日期 | 2022年03月03日 12:17 |
> | 收件人 | acas...@gmail.com |
> | 抄送至 | dev@nuttx.apache.org |
> | 主题 | Re: nuttx lora sx127x device use for help |
> I tested the two devices with an oscilloscope and both have signals, but
> there is no communication between the two devices.
> One is always sending data, and the other is waiting to receive data. Does
> the communication between the two devices need to be networked first?
>
>
> That's what it used to be, but I used two boards to execute sx127x -r on one
> of the boards and sx127x -t on the other, expecting communication between
> the two boards, but it didn't work as expected . Do you need any other
> configuration?
> the first board:
> nsh> sx127x -t
> Start sx127x_demo
> LORA modulation
> Set frequency to 93000
> Set power to 14
>
> Send 5 bytes
>
>
> the sencond boad:
> nsh> sx127x -r
> Start sx127x_demo
> LORA modulation
> Set frequency to 93000
> Set power to 14
> Waiting for data
>
>
>
>
RE: Serial RX DMA polling
Hi Michal, > rather from board level section Yes Have a look at this example. https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/init.cpp#L243-L247 -Original Message- From: Michal Lenc Sent: Sunday, March 6, 2022 2:38 PM To: dev@nuttx.apache.org Subject: Serial RX DMA polling Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc
Re: SPI problem
Hello Roberto, I think that the problem is in the line's: "stm32_gpiowrite(g_spigpio[devid], !selected);". Those should be "stm32_gpiowrite(g_spigpio[SPIDEVID_INDEX(devid)], !selected);". Please try to see if that helps. Best regards, Petro пн, 7 бер. 2022 р. о 12:46 Roberto Bucher пише: > I reached to move a little forward by analyzing the SPI on the nucleo-144 > STM32F7 board, and I found out that the problem is now in the calling of > SPI_SELECT in the nuttx/drivers/spi/spi_transfer.c and the spi_transfer > function. > > This are the values in the seq structure before launching the SPI_SELECT > command. > > nsh> spi bus > BUS EXISTS? > Bus 0: NO > Bus 1: NO > Bus 2: YES > Bus 3: NO > nsh> spi exch -b2 -x4 aabbccdd > Sending:AA BB CC DD > seq -> dev: 0x17, mode: 3, nbits: 8, ntrans: 1, freq: 400 > Received:FF FF FF FF > > To avoid the dump error I modified the seq->dev from 0x17 to 0x0004... > It seems that the seq->dev value is not correct... > > Best regards > > Roberto > > On 3/6/22 13:47, Roberto Bucher wrote: > > Thanks Petro > > I've modified the nucleo-144/src/stm32_spi.c file by simply adding: > > struct spi_dev_s *g_spiX; > > and by adding > > spi_register(g_spiX, X); > > in the > > where X is the spi device number (in my example spi2) > > in the shell the /dev/spi2 is available. > > Best regards > > Roberto > > On 3/6/22 12:49, Petro Karashchenko wrote: > > Hello Roberto, > > I'm asking this because I examined nucleo-144 board source code and > currently I do not see a "spi_register" call in board init files. So I > assume that you have some modified code and it is very hard to make any > conclusions while not seeing the code. > > Best regards, > Petro > > нд, 6 бер. 2022 р. о 13:40 Petro Karashchenko < > petro.karashche...@gmail.com> пише: > >> Hello Roberto, >> >> It would be good if you can dump assembly that is generated. What I see >> is that "int spi_register(FAR struct spi_dev_s *spi, int bus)", so I'm >> assuming that R0 should be "spi" and R1 should be "bus", but in your dump >> "R0: 0001 R1: 2004e840" those seems to be inverted (0001 seems to >> be a "bus" and "2004e840" seems to be a "spi" pointer). The assembly code >> will show light on the dump that you provided. As an alternative you can >> provide the defconfig that you use if you are not using a custom board. >> >> Best regards, >> Petro >> >> >> нд, 6 бер. 2022 р. о 10:54 Roberto Bucher пише: >> >>> When I enable some dubug configs >>> >>> >>> >>> I get the following error by enter in the serial shell: >>> >>> sert: Assertion failed at file:spi/spi_driver.c line: 358 >>> arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800 R3: 20010684 >>> arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370 FP: 20010670 >>> arm_registerdump: R8: SB: SL: R11: >>> arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad PC: 0800648e >>> arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: 0004 >>> arm_registerdump: EXC_RETURN: ffe9 >>> arm_dump_stack: User Stack: >>> >>> On the line 358 of spi_driver.c there is this assertion: >>> >>> /* Sanity check */ >>> >>> DEBUGASSERT(spi != NULL && (unsigned)bus < 1000); >>> >>> Any Idea? >>> >>> Best regards >>> >>> Roberto >>> >>> >>> >>> > >
Re: SPI problem
Thanks Petro! This solve one part of the problem: I don't receive any crash now. There is another thinks tht is not clear to me: the macro SPIDEV_ID(spitool->devtype, spitool->csn) is defined as #define SPIDEV_ID(type,index) uint32_t)(type) & 0x) << 16) | \ ((uint32_t)(index) & 0x)) in the file include/nuttx/spi/spi.h. This should means that calling it with the parameters spitool->devtype=0x23 and spitool->csn=0 should give 0x23 as return value and not 0x17... Best regards Roberto On 3/7/22 16:22, Petro Karashchenko wrote: Hello Roberto, I think that the problem is in the line's: "stm32_gpiowrite(g_spigpio[devid], !selected);". Those should be "stm32_gpiowrite(g_spigpio[SPIDEVID_INDEX(devid)], !selected);". Please try to see if that helps. Best regards, Petro пн, 7 бер. 2022 р. о 12:46 Roberto Bucher пише: I reached to move a little forward by analyzing the SPI on the nucleo-144 STM32F7 board, and I found out that the problem is now in the calling of SPI_SELECT in the nuttx/drivers/spi/spi_transfer.c and the spi_transfer function. This are the values in the seq structure before launching the SPI_SELECT command. nsh> spi bus BUS EXISTS? Bus 0: NO Bus 1: NO Bus 2: YES Bus 3: NO nsh> spi exch -b2 -x4 aabbccdd Sending: AA BB CC DD seq -> dev: 0x17, mode: 3, nbits: 8, ntrans: 1, freq: 400 Received: FF FF FF FF To avoid the dump error I modified the seq->dev from 0x17 to 0x0004... It seems that the seq->dev value is not correct... Best regards Roberto On 3/6/22 13:47, Roberto Bucher wrote: Thanks Petro I've modified the nucleo-144/src/stm32_spi.c file by simply adding: struct spi_dev_s *g_spiX; and by adding spi_register(g_spiX, X); in the where X is the spi device number (in my example spi2) in the shell the /dev/spi2 is available. Best regards Roberto On 3/6/22 12:49, Petro Karashchenko wrote: Hello Roberto, I'm asking this because I examined nucleo-144 board source code and currently I do not see a "spi_register" call in board init files. So I assume that you have some modified code and it is very hard to make any conclusions while not seeing the code. Best regards, Petro нд, 6 бер. 2022 р. о 13:40 Petro Karashchenko пише: Hello Roberto, It would be good if you can dump assembly that is generated. What I see is that "intspi_register(FAR structspi_dev_s *spi, intbus)", so I'm assuming that R0 should be "spi" and R1 should be "bus", but in your dump "R0: 0001 R1: 2004e840" those seems to be inverted (0001 seems to be a "bus" and "2004e840" seems to be a "spi" pointer). The assembly code will show light on the dump that you provided. As an alternative you can provide the defconfig that you use if you are not using a custom board. Best regards, Petro нд, 6 бер. 2022 р. о 10:54 Roberto Bucher пише: When I enable some dubug configs I get the following error by enter in the serial shell: sert: Assertion failed at file:spi/spi_driver.c line: 358 arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800 R3: 20010684 arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370 FP: 20010670 arm_registerdump: R8: SB: SL: R11: arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad PC: 0800648e arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: 0004 arm_registerdump: EXC_RETURN: ffe9 arm_dump_stack: User Stack: On the line 358 of spi_driver.c there is this assertion: /* Sanity check */ DEBUGASSERT(spi != NULL && (unsigned)bus < 1000); Any Idea? Best regards Roberto
Re: SPI problem
Sorry! Forgot my previous error! devtype was 23 and not 0x23!!! My fault Best regards Roberto On 3/7/22 16:48, Roberto Bucher wrote: Thanks Petro! This solve one part of the problem: I don't receive any crash now. There is another thinks tht is not clear to me: the macro SPIDEV_ID(spitool->devtype, spitool->csn) is defined as #define SPIDEV_ID(type,index) uint32_t)(type) & 0x) << 16) | \ ((uint32_t)(index) & 0x)) in the file include/nuttx/spi/spi.h. This should means that calling it with the parameters spitool->devtype=0x23 and spitool->csn=0 should give 0x23 as return value and not 0x17... Best regards Roberto On 3/7/22 16:22, Petro Karashchenko wrote: Hello Roberto, I think that the problem is in the line's: "stm32_gpiowrite(g_spigpio[devid], !selected);". Those should be "stm32_gpiowrite(g_spigpio[SPIDEVID_INDEX(devid)], !selected);". Please try to see if that helps. Best regards, Petro пн, 7 бер. 2022 р. о 12:46 Roberto Bucher пише: I reached to move a little forward by analyzing the SPI on the nucleo-144 STM32F7 board, and I found out that the problem is now in the calling of SPI_SELECT in the nuttx/drivers/spi/spi_transfer.c and the spi_transfer function. This are the values in the seq structure before launching the SPI_SELECT command. nsh> spi bus BUS EXISTS? Bus 0: NO Bus 1: NO Bus 2: YES Bus 3: NO nsh> spi exch -b2 -x4 aabbccdd Sending: AA BB CC DD seq -> dev: 0x17, mode: 3, nbits: 8, ntrans: 1, freq: 400 Received: FF FF FF FF To avoid the dump error I modified the seq->dev from 0x17 to 0x0004... It seems that the seq->dev value is not correct... Best regards Roberto On 3/6/22 13:47, Roberto Bucher wrote: Thanks Petro I've modified the nucleo-144/src/stm32_spi.c file by simply adding: struct spi_dev_s *g_spiX; and by adding spi_register(g_spiX, X); in the where X is the spi device number (in my example spi2) in the shell the /dev/spi2 is available. Best regards Roberto On 3/6/22 12:49, Petro Karashchenko wrote: Hello Roberto, I'm asking this because I examined nucleo-144 board source code and currently I do not see a "spi_register" call in board init files. So I assume that you have some modified code and it is very hard to make any conclusions while not seeing the code. Best regards, Petro нд, 6 бер. 2022 р. о 13:40 Petro Karashchenko пише: Hello Roberto, It would be good if you can dump assembly that is generated. What I see is that "intspi_register(FAR structspi_dev_s *spi, intbus)", so I'm assuming that R0 should be "spi" and R1 should be "bus", but in your dump "R0: 0001 R1: 2004e840" those seems to be inverted (0001 seems to be a "bus" and "2004e840" seems to be a "spi" pointer). The assembly code will show light on the dump that you provided. As an alternative you can provide the defconfig that you use if you are not using a custom board. Best regards, Petro нд, 6 бер. 2022 р. о 10:54 Roberto Bucher пише: When I enable some dubug configs I get the following error by enter in the serial shell: sert: Assertion failed at file:spi/spi_driver.c line: 358 arm_registerdump: R0: 0001 R1: 2004e840 R2: 40004800 R3: 20010684 arm_registerdump: R4: 2004e7a0 R5: 0002 R6: 2004f370 FP: 20010670 arm_registerdump: R8: SB: SL: R11: arm_registerdump: IP: 0003 SP: 2004f370 LR: 08005fad PC: 0800648e arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: 0004 arm_registerdump: EXC_RETURN: ffe9 arm_dump_stack: User Stack: On the line 358 of spi_driver.c there is this assertion: /* Sanity check */ DEBUGASSERT(spi != NULL && (unsigned)bus < 1000); Any Idea? Best regards Roberto
RE: Serial RX DMA polling
Hi David, > https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 that´s exactly what I was looking for, thanks! Best regards, Michal Lenc -- Původní e-mail -- Od: David Sidrane Komu: dev@nuttx.apache.org Datum: 7. 3. 2022 15:20:08 Předmět: RE: Serial RX DMA polling "Hi Michal, > rather from board level section Yes Have a look at this example. https://github.com/PX4/PX4-Autopilot/blob/master/boards/px4/fmu-v5x/src/ init.cpp#L243-L247 -Original Message- From: Michal Lenc Sent: Sunday, March 6, 2022 2:38 PM To: dev@nuttx.apache.org Subject: Serial RX DMA polling Hi all, serial drivers use periodic polling for DMA receive callback to ensure the reception of bytes that were not taken by DMA interrupt. There are functions like stm32_serial_dma_poll(void) that should be periodically called from a timer for this purpose. However I haven´t been able to find any "example" usage in the NuttX mainline. My first thoughts were to implement the timer directly to the driver (like in ADC drivers) but stm32_serial_dma_poll(void) is not private so I guess it is not supposed to be called from stm32_serial.c but rather from board level section? Is there any consensus on how to use the periodic polling? Thanks. Best regards, Michal Lenc "
