I am working on a project based on qt 4.8.5 and C++, the system is ubuntu 1404 and the motherboard in the pc was a DL631-c226 (information on DFI.COM ).
In the specification there is a DIO digital input output port 8 bits.
I read and I see every where on the web the simplest command is;
echo 1 > /sys/class/gpio/export
And after that a directory has been created but on my system it is not. Nothing happen even if I send the command using sudo root or root or admin
I get an error message "permission denied".
There is nothing in the BIOS regarding the DIO or GPIO configuration, in the kernel the GPIO is set to YES
I need help to read the value as changed on the pin of the DIO of my motherboard.
The interface to the DIO port is over i2c. Consulting their manual you can see an example of how to talk to it. I suggest you investigate i2c under Linux to understand how to handle it. At the very least you will need to install i2c tools and ensure your kernel has i2c support in it.
Their example: http://www.manualslib.com/manual/725217/Dfi-Dl631-C226.html?page=75#manual
Related
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I bought a Variense VMU931 inertial measurement unit (IMU) for a robotics project at school, and I am struggling to get it to reliably communicate with my laptop in Ubuntu. I am using C++ with termios to connect to it using 8n1 no parity blah blah blah. I've tried EVERY permutation of settings I can think of, and I still cannot reliably send commands to the IMU.
I called Variense support and spoke to the engineer that wrote their software, and he said it is a known issue. Evidently it works perfectly in Windows (and the Windows demo software worked fine with my device), but neither of us is aware of a significant difference between the USB Serial emulation in Windows and in Linux.
The constructor at the top of this file shows how I am opening and configuring the port:
https://github.com/jsford/FFAST/blob/master/VMU931/src/vmu.cpp
Any help would be great. I've been tearing my hair out over this!
Thanks!
Use the cu utility for running tests with different parameters.
To debug the issue: run the USB packet capture with Wireshark on Linux directly and also on a Windows VM running in VirtualBox/VmWare. Compare the traffic.
Check which kernel module is chosen and loaded for that USB device. Use /sys/ filesystem for that: this virtual fs has information from kernel about what's used. Also, the lsmod-kind of commands show the kernel module usage. The driver choice for USB depends on something like <usb-manufacturer-id>:<usb-product-id>.
Put some printfs into the kernel module to see where is fails. Use the DKMS build system for rebuilding the kernel module. There is a config file somewhere in Linux to blacklist/whitelist the kernel modules - useful to make sure that the right one is loaded.
That's what I was doing to fix a driver of an USB-serial device.
The port option in Arduino Uno IDE is not accessible.
I have win7 32bit, I have tried the installation of driver file arduino.inf, but still it is not working
Probably because windows did not recognize any com ports. Go to device manager and look for COM ports. Check if it shows up there or not.
If not, then that means windows did not recognize it and there is a connection problem
I am attempting to use GDB to debug a remote target over a serial line on a windows box using MinGW. The target remote command GDB expects a path to a device driver (e.g. /dev/ttyS0) in order to connect to the remote target. There are 4 properly functioning serial ports on my machine, but they don't seem to be visible from MinGW. Is there a way to install them, or is this just not possible in the self proclaimed minimalist MinGW?
I did some searching on MinGW, Google, and here and wasn't able to find anything relevant.
Per #J.J Hakala com ports are just named com1, com2, etc in windows. They are in the root directory so ./com1 works as well. There is no need to install drivers.
I recently downloaded new linux kernel source code and compiled on ubuntu. After my system is not recognizing any usb devices. Is there any changes required to compiling procedure or make files in order to enable USB host?
Please help me to get out of this problem. Thanks.
It is possible for the USB support to be disabled though incorrect or incomplete configuration.
You didn't mention how you configured the kernel though.
A good point to start is the existing configuration for the default Ubuntu kernel. There should be a config file in boot, like /boot/config-3.1.0-1-amd64.
Copy that file to your kernel directory as .config, then use make oldconfig to update the configuration.
When installing the kernel take care to create the corresponding initrd as well.