You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Roberto Bucher <ro...@supsi.ch> on 2022/03/06 08:54:04 UTC
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: 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
Re: SPI problem
Posted by Tim Hardisty <Ti...@JTi.uk.com.INVALID>.
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 <ro...@supsi.ch>
Reply to: <de...@nuttx.apache.org>
Date: Sunday, 6 March 2022 at 08:54
To: <de...@nuttx.apache.org>
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: 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
Re: SPI problem
Posted by Roberto Bucher <ro...@supsi.ch>.
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 <ro...@supsi.ch> пише:
>
> 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) & 0xffff) <<
>> 16) | \
>> ((uint32_t)(index) & 0xffff))
>>
>> 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 0x230000 as
>> return value and not 0x170000...
>>
>> 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
>>> <ro...@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
>>>>> <pe...@gmail.com> пише:
>>>>>
>>>>> 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: 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
>>>>> <ro...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: SPI problem
Posted by Petro Karashchenko <pe...@gmail.com>.
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 <ro...@supsi.ch> пише:
> 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) & 0xffff) << 16) | \
> ((uint32_t)(index) & 0xffff))
>
> 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 0x230000 as return
> value and not 0x170000...
>
> 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 <ro...@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.karashchenko@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 <ro...@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
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
Re: SPI problem
Posted by Roberto Bucher <ro...@supsi.ch>.
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) & 0xffff) << 16) | \
> ((uint32_t)(index) & 0xffff))
>
> 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 0x230000 as
> return value and not 0x170000...
>
> 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 <ro...@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
>>>> <pe...@gmail.com> пише:
>>>>
>>>> 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: 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
>>>> <ro...@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: SPI problem
Posted by Roberto Bucher <ro...@supsi.ch>.
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) & 0xffff) << 16) | \
((uint32_t)(index) & 0xffff))
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 0x230000 as return
value and not 0x170000...
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 <ro...@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
>>> <pe...@gmail.com> пише:
>>>
>>> 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: 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
>>> <ro...@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
>>>
>>>
>>>
>>
>
Re: SPI problem
Posted by Petro Karashchenko <pe...@gmail.com>.
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 <ro...@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.karashchenko@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 <ro...@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
>>>
>>>
>>>
>>>
>
>
Re: SPI problem
Posted by Roberto Bucher <ro...@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
>> <pe...@gmail.com> пише:
>>
>> 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: 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
>> <ro...@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
>>
>>
>>
>
Re: SPI problem
Posted by Roberto Bucher <ro...@supsi.ch>.
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
> <pe...@gmail.com> пише:
>
> 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: 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
> <ro...@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
>
>
>
Re: SPI problem
Posted by Petro Karashchenko <pe...@gmail.com>.
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 <pe...@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 <ro...@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
>>
>>
>>
>>
Re: SPI problem
Posted by Petro Karashchenko <pe...@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 <ro...@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
>
>
>
>