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 <roberto.buc...@supsi.ch> пише: > 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: 0x170000, mode: 3, nbits: 8, ntrans: 1, freq: 4000000 > Received: FF FF FF FF > > To avoid the dump error I modified the seq->dev from 0x170000 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: 00000001 R1: 2004e840" those seems to be inverted (00000001 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 <roberto.buc...@supsi.ch> пише: >> >>> 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: 00000001 R1: 2004e840 R2: 40004800 R3: 20010684 >>> arm_registerdump: R4: 2004e7a0 R5: 00000002 R6: 2004f370 FP: 20010670 >>> arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000 >>> arm_registerdump: IP: 00000003 SP: 2004f370 LR: 08005fad PC: 0800648e >>> arm_registerdump: xPSR: 61000000 PRIMASK: 00000000 CONTROL: 00000004 >>> arm_registerdump: EXC_RETURN: ffffffe9 >>> 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 >>> >>> >>> >>> > >
