## Summary
SPI Poll Send `bl602_spi_poll_send()` doesn't send any SPI Data because it doesn't enable SPI Master and it doesn't clear the SPI FIFO. Also it hangs because it loops forever waiting for the FIFO.
We fix this problem by moving the code that enables SPI Master and clears the FIFO, from SPI Poll Exchange `bl602_spi_poll_exchange()` to SPI Poll Send. (Note that SPI Poll Exchange calls SPI Poll Send)
[More Details Here](https://github.com/lupyuen/st7789-nuttx#fix-spi-send)
## Impact
This problem affects all NuttX Drivers that call `SPI_SEND()` on BL602, including the ST7789 Display Driver.
Previously `SPI_SEND()` didn't send any SPI Data and never returns, because it loops forever waiting to receive data.
Now `SPI_SEND()` sends data and returns correctly.
[More Details Here](https://github.com/lupyuen/st7789-nuttx#fix-spi-send)
## Testing
We tested the modified SPI Poll Send with NuttX ST7789 Driver and a Logic Analyser on PineCone BL602:
- [Testing with Logic Analyser](https://github.com/lupyuen/st7789-nuttx#fix-spi-send)
We also tested LVGL with ST7789 on PineCone BL602:
- [Testing with LVGL](https://github.com/lupyuen/st7789-nuttx#run-lvgl-demo)
As for the modified SPI Poll Exchange, we tested with Semtech SX1262 SPI Transceiver on PineCone BL602:
- [Testing SPI Poll Exchange](https://github.com/lupyuen/incubator-nuttx/releases/tag/release-2022-03-25)
-#9 0xf7abf899 in __asan::__asan_report_load2 (addr=4072681776) at ../../../../../src/libsanitizer/asan/asan_rtl.cc:117
-#10 0x5693f718 in inode_release (node=0xf2c03124) at inode/fs_inoderelease.c:69
-#11 0x568ea61b in file_close (filep=0xf55fedd0) at vfs/fs_close.c:79
-#12 0x568e7e56 in nx_close (fd=3) at inode/fs_files.c:528
-#13 0x568e7f0e in close (fd=3) at inode/fs_files.c:562
-#14 0x56e76c39 in epoll_close (epfd=3) at vfs/fs_epoll.c:252
-#15 0x56c33829 in sensor_service_delete (ctrl=0x578b8540 <control>) at src/common.c:439
-#16 0x56a0561e in sensor_middle_service_main (argc=1, argv=0xf55de820) at sensor_main.c:118
-#17 0x56878675 in nxtask_startup (entrypt=0x56a054cc <sensor_middle_service_main>, argc=1, argv=0xf55de820) at sched/task_startup.c:70
-#18 0x5684427a in nxtask_start () at task/task_start.c:133
-#19 0xdeadbeef in ?? ()
reason:
epoll_close -> close -> epoll_do_close (free inode)
-> inode_release (reuse inode, crash)
fix:
use the global inode to match the fd which will return to user.
like the g_sock_inode in fs/socket/socket.c
Signed-off-by: ligd <liguiding1@xiaomi.com>
Fix this compile-time warning:
rpmsg/rpmsg_sockif.c:381:24: warning: format '%d' expects argument of type 'int', but argument 3 has type 'ssize_t' {aka 'long int'} [-Wformat=]
381 | nerr("circbuf_write overflow, %d, %d\n", written, len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
| |
| ssize_t {aka long int}
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
Fix this compile-time warning:
rptun/rptun.c:956:22: warning: '%lx' directive output may be truncated writing between 1 and 16 bytes into a region of size 14 [-Wformat-truncation=]
956 | snprintf(arg1, 16, "0x%" PRIxPTR, (uintptr_t)priv);
| ^~~~~
rptun/rptun.c:956:25: note: format string is defined here
956 | snprintf(arg1, 16, "0x%" PRIxPTR, (uintptr_t)priv);
rptun/rptun.c:956:22: note: directive argument in the range [1, 18446744073709551615]
956 | snprintf(arg1, 16, "0x%" PRIxPTR, (uintptr_t)priv);
| ^~~~~
rptun/rptun.c:956:3: note: 'snprintf' output between 4 and 19 bytes into a destination of size 16
956 | snprintf(arg1, 16, "0x%" PRIxPTR, (uintptr_t)priv);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Eero Nurkkala <eero.nurkkala@offcode.fi>
