Unlike Delphi or say the 9S12 or PIC debugger the Lazarus shows the source but doesn't seem to have a step ability in machine language. So I can see what it's doing and even the registers but nothing more. Given that the C code works perfectly and the Pascal stuff sends the same information I suspect the problem isn't with the OS but perhaps pointer formatting or something like that. Still working on it. Without these kinds of problems I never really learn how things are put together. So it's not a bad thing. Just annoying. The system can send ioctl messages directly as shown in the log. But when using the transfer function it dies. So something between 2017 when this code was released and now there is something slightly different. John From: 'Mark Lazarewicz' via BeagleBoard [mailto:beagleboard@googlegroups.com] Sent: May-19-21 10:43 PM To: beagleboard@googlegroups.com Subject: RE: [beagleboard] ioctl messages to Beagle SPI port. # I can't step the machine code past the ioctl system call Hi John What are using to step? It's been a long time but I remember being able to go as deep as I wanted into the linux OS. The hard part was getting kernel source code setup but i had that working requires debugging from linux build machine but you don't seem adverse to assembly language. Probally unrelated but each high level language passes it's function parameters to the registers in a certain order. I know because we switched from PLM 86 to C one was right to left the other was reversed I wrote an assembler library to fix this in the 80s. You should be able to step into into anything in mixed c and assembler mode. Sorry if I'm not totally understanding but it sounds like you could get insight if you could step into the ioctl if its a function you should be able to . C Macros you can't but it doesn't look like what that is. Mark Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> On Wed, May 19, 2021 at 11:10 PM, John Dammeyer <jo...@autoartisans.com> wrote: So to add this so the research I did isn't repeated. The control message breaks down as follows: Top two bits are the direction. The 'k' (0x6B) identifies the SPI type. The number of bytes is placed into the 32 bit word with the _IOC_NRSHIFT which in itself is also a macro all defined in the asm generic ioctl.h file. ret = ioctl(fd, _IOC(_IOC_WRITE,('k'),(1),(8), &mode); #define _IOC(dir,type,nr,size) \ (((dir) << _IOC_DIRSHIFT) | \ ((type) << _IOC_TYPESHIFT) | \ ((nr) << _IOC_NRSHIFT) | \ ((size) << _IOC_SIZESHIFT)) The shifts are defined to create this and it's quite convoluted to get there. SPI_IOC_MESSAGE(1) = 40206B00 define _IOC_NRBITS 8 #define _IOC_TYPEBITS 8 /* * Let any architecture override either of the following before * including this file. */ #ifndef _IOC_SIZEBITS # define _IOC_SIZEBITS 14 #endif #ifndef _IOC_DIRBITS # define _IOC_DIRBITS 2 #endif #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1) #define _IOC_TYPEMASK ((1 << _IOC_TYPEBITS)-1) #define _IOC_SIZEMASK ((1 << _IOC_SIZEBITS)-1) #define _IOC_DIRMASK ((1 << _IOC_DIRBITS)-1) #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) #define _IOC_NRSHIFT 0 #define _IOC_TYPESHIFT (_IOC_NRSHIFT+_IOC_NRBITS) #define _IOC_SIZESHIFT (_IOC_TYPESHIFT+_IOC_TYPEBITS) #define _IOC_DIRSHIFT (_IOC_SIZESHIFT+_IOC_SIZEBITS) From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of John Dammeyer Sent: May-19-21 8:44 PM To: beagleboard@googlegroups.com Subject: [beagleboard] ioctl messages to Beagle SPI port. The spidev_test.c program from the Exploring BeagleBone by Derek Molloy (chp08) tests the SPI port by setting the SPI parameters and then writing out a test block. The text diagnostics I've added show what the macro was that is sent as part of the ioctl call. Trying to break down the macro through multiple files turned into a dead end and I'm not exactly sure what the 32 bit word means other than byte count and I believe message type. The program starts out by sending 6 ioctl messages that configure mode, size and speed. Here's the call that returns the 0x4006B00 and below the result of the message. ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr); debian@ebb:~/exploringBB/chp08/spi/spidev_test$ ./spidev_test SPI_IOC_WR_MODE = 40016B01 SPI_IOC_RD_MODE = 80016B01 SPI_IOC_WR_BITS_PER_WORD = 40016B03 SPI_IOC_RD_BITS_PER_WORD = 80016B03 SPI_IOC_WR_MAX_SPEED_HZ = 40046B04 SPI_IOC_RD_MAX_SPEED_HZ = 80046B04 spi mode: 0 bits per word: 8 max speed: 500000 Hz (500 KHz) SPI_IOC_MESSAGE(1) = 40206B00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Now. Switch over to a part of the DisplaySPI program in the Lazarus Free Pascal pxl library the function call looks the same as do the SPI initialization calls to fpioctl. They are in a different order from the C program. Res := fpioctl(FHandle, SPI_IOC_MESSAGE(1), @Data); Six of the ioctl function calls do not return an error. The main one to send data has the correct SPI_IOC_MESSAGE(1) value yet it fails. debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/DisplaySPI$ ./DisplaySPI UpdateFrequency -- SPI_IOC_WR_MAX_SPEED_HZ is 40046B04 UpdateFrequency -- SPI_IOC_RD_MAX_SPEED_HZ is 80046B04 UpdateBitsPerWord -- SPI_IOC_WR_BITS_PER_WORD is 40016B03 UpdateBitsPerWord -- SPI_IOC_RD_BITS_PER_WORD is 80016B03 UpdateRWMode -- SPI_IOC_WR_MODE is 40016B01 UpdateRWMode -- SPI_IOC_RD_MODE is 80016B01 SPI_IOC_MESSAGE(1) is 40206B00 An unhandled exception occurred at $000330A8: ESysfsSPITransfer: Cannot transfer <1> data byte(s) through SPI bus. $000330A8 TSYSFSSPI__TRANSFER, line 263 of /home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas $00032F54 TSYSFSSPI__WRITE, line 241 of /home/debian/lazarus/pxl/Source/PXL.Sysfs.SPI.pas Is there some documentation out there on the ioctl call and what the actual parameter means in detail with respect to the BeagleBone processor? The man page states that command is specific to the device. https://man7.org/linux/man-pages/man2/ioctl.2.html I'm having trouble figuring out why it fails or more specifically where to look next. I can't step the machine code past the ioctl system call so I'd like to know what is actually going on inside the OS with this call inside the Beagle. Thanks John "ELS! Nothing else works as well for your Lathe" Automation Artisans Inc. www dot autoartisans dot com -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02a901d74d2a%246b84f600%24428ee200%24%40autoartisans.com <https://groups.google.com/d/msgid/beagleboard/02a901d74d2a%246b84f600%24428ee200%24%40autoartisans.com?utm_medium=email&utm_source=footer> . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02b401d74d2d%2403af82e0%240b0e88a0%24%40autoartisans.com <https://groups.google.com/d/msgid/beagleboard/02b401d74d2d%2403af82e0%240b0e88a0%24%40autoartisans.com?utm_medium=email&utm_source=footer> . -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1121873347.1447636.1621489360355%40mail.yahoo.com <https://groups.google.com/d/msgid/beagleboard/1121873347.1447636.1621489360355%40mail.yahoo.com?utm_medium=email&utm_source=footer> .
-- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02e301d74d44%2479020790%246b0616b0%24%40autoartisans.com.
