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 <roberto.buc...@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
<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 "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
<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
