Re: SPI Example
I followed a bit the problem with the SPI bus and I reached to find where I have the first problem: 1) In the shell: spi bus gives me that the BUS 2 is available 2) I launch "spi -b2 -x4 aabbccdd" and I pass through the following files: apps/system/spi/spi_exch.c -> apps/system/spi/spi_devif.c -> nuttx/drivers/spi/spi_driver.c -> /nuttx/drivers/spi/spi_transfer.c which sould be ok. 3) In spi_transfer.c , the line "SPI_LOCK(spi, true)" causes the dump! When I try to set the DEBUG ASSERTION in "make menuconfig", this causes a dump directly when I enter the nuttx shell in my nucleo-144 board... It is quite difficult to find out an idea to follow the problem yet... Best regards Roberto On 3/4/22 13:34, Alan Carvalho de Assis wrote: Hi Roberto, Enable the DEBUG ASSERTION to see where the crash is happening? What you get when you run: nsh> spi bus Maybe you passing an invalid bus number. BR, Alan On 3/4/22, Roberto Bucher wrote: Thanks Alan, but the main problem is that this test gives me an error by the execution on my STM32F7 nucleo-144 board... nsh> spi exch -b 2 -x 4 aabbccdd Seup_assert: Assertion failed at file:armv7-m/arm_hardfault.c line: 174 arm_registerdump: R0: R1: 2001a334 R2: 0001 R3: 2201 arm_registerdump: R4: R5: 2201 R6: 2004f774 FP: 2004f770 arm_registerdump: R8: 2001a380 SB: 0005 SL: 2001a358 R11: 2001a35c arm_registerdump: IP: 0018 SP: 2001a2b0 LR: 08016f63 PC: 0801700c arm_registerdump: xPSR: 6100 PRIMASK: CONTROL: arm_registerdump: EXC_RETURN: ffe9 arm_dump_stack: User Stack: arm_dump_stack: sp: 2001a170 arm_dump_stack: base: 20019c70 arm_dump_stack: size: 07c8 arm_stackdump: 2001a160: 20019c70 2001a170 20011d50 0801b447 0801700c arm_stackdump: 2001a180: 08021224 0801700a 080236b8 2004f774 2004f770 2 BR Roberto On 3/4/22 12:29, Alan Carvalho de Assis wrote: Hi Roberto, We have the SPI Tool that does exactly what you want: Application Configuration ---> System Libraries and NSH Add-Ons ---> [*] SPI tool ---> BR, Alan On 3/4/22, Roberto Bucher wrote: Hi where can I found a simple example that send n bytes to the SPI and receive m bytes? I can now see the /dev/spi but using simple methods like open and write doesn't give me any signal on the bus... Thanks in advance Roberto
SPI problem
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
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
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 "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
>From my own struggles to get a board (custom board as it happens, but like >others that were there) I found: Board support was often incomplete. Look at other boards to see where and how SPI is initialised and registered. You may find something basic is missing. Stack size. Random errors occur if there’s insufficient stack Just because a board is there, neither assume the support is complete nor correct! For example, for my SAMA5D27-based boards I found: Errors in PIO mapping (from memory, PIO C and D had incorrect addresses. PIOD was missing from Kconfig) CAN support had compile errors. It shouldn’t actually have used CAN as that A5D2 processor uses “mcan” needing a different set of drivers to the A5D3 or D4 processors in that family Other peripherals had no support at all – Flexcom and ClassD Audio, for example. I suppose that if a particular eval board has a set of specific peripherals actually used, then support has probably been tried – but if the eval board for yours doesn’t have anything connected to SPI then whoever ported the board would have nothing there to test it with. Bottom line – ASSUME NOTHING!! From: Roberto Bucher Reply to: Date: Sunday, 6 March 2022 at 08:54 To: Subject: SPI problem 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 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
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
