>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 <roberto.buc...@supsi.ch> Reply to: <dev@nuttx.apache.org> Date: Sunday, 6 March 2022 at 08:54 To: <dev@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
