Article: NuttX Driver for BME280 Sensor (ported from Zephyr OS)
This article explains how I ported the BME280 I2C Driver (Temperature / Humidity / Pressure) from Zephyr OS to NuttX... https://lupyuen.github.io/articles/bme280 Lup
Re: SPI problem
Thanks again Petro! Your hint was perfect and now the SPI perct works on the nucleo-144 board! Best regards Roberto On 3/8/22 22:31, Petro Karashchenko wrote: Hello Roberto, I've created https://github.com/apache/incubator-nuttx/pull/5697 to fix the problem. Best regards, Petro пн, 7 бер. 2022 р. о 16:54 Roberto Bucher пише: 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 */
Re: SPI problem
Hello Roberto, I've created https://github.com/apache/incubator-nuttx/pull/5697 to fix the problem. Best regards, Petro пн, 7 бер. 2022 р. о 16:54 Roberto Bucher пише: > 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 < >> 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 >> >> > >
