I am trying to communicate to my embedded(set-top box) device through this(http://numato.com/8-channel-usb-gpio-module) GPIO. Previously, when i attached this device to my set top box, then in dmesg, it is showing only that new usb device has been attached and by some hook/crook method, i manually created a node with major minor number of recently attached usb device and through my cross compiled c program, i tried to send gpio commands, which throws me the errors of invalid commands. After some more research, i get to know that on my set top box kernel, ACM CDC support is disabled. so i compiled the kernel again with CDC ACM support enabled and USB serial convertor support enabled. after flashing the kernel on BOX, now when i attached the device, in dmesg, it is showing that device is attached, New ACM device detected on ttyACM0, but no node is created in /dev, instead i found the device info in /sys/class/tty/ttyACM0. from here, i get the major and minor number of my device and manually created a node. after that i tried to communicate again, but now, instead of saying invalid command, my program is stuck on the first GPIO command and it is not executing any GPIO commands, but giving me the output of all the printf statements at application layer. please help.
Thanks in advance
Related
Working with the STM32L062 Cortex-M0 and CubeMX the generated USB CDC-ACM code works fine in Windows. With loopback code running on the STM32 and TerraTerm running on Windows characters typed in the terminal window correctly echo back. However, when this same system is then plugged into a laptop running Ubuntu, the device fails to enumerate. Even worse, the system doesn't appear to respond to the connection whatsoever- no new messages appear via dmesg that even a failed enumeration is going on. Given that the code used is generated by CubeMX wizards it is difficult to know what to start to troubleshoot. Any suggestions?
As an aside, this isn't the first issue presented by CDC-ACM drivers. Implementing a USB CDC-ACM stack for a PIC32MM processor, data can be sent to the host but not received from the host, however, if the driver is switched to plain vanilla CDC then data can be sent both ways no problem. So it seems maybe Ubuntu has some issues with the default USB drivers, but either way, it's very odd that the ST driver gets zero response at all from the system.
I am trying to use .net nano on esp32 cam module. I am able to upload the firmware over serial. After that I can see .net nano boot messages over serial , device explorer also it detects. But no operation on device explorer works eg get device capabilities, erase etc not working.
i am getting ESP32_WROOM_32 # COM8 is not responding, please reboot the device.
Deployment of new application also fails with the same. Is it because wroom firmware not supported on this cam module ?
this is the firmware log
Connected to ESP32 ESP32D0WDQ6 (revision 1) with MAC address CC50E3B6A7AC
features WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Flash information: manufacturer 0x32 device 0x16406 size 4MB
Trying to find ESP32_WROOM_32 in developement repository...OK
Downloading firmware package...OK
Updating to 1.6.1-preview.24
Erasing flash...OK
Flashing firmware...OK
Make sure there is no other application "locking" that COM port. Usual suspects are Arduino VS extensions and other utilities that try to find Arduino devices when new COM ports are enumerated.
I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.
I'm working with a commercial device which uses a STM32F103RBT6 microcontroller. I need to replace the firmware to customize some functionalities, but before I would like to dump the current one to be able to restore it if it's needed.
I connected properly the board to my ST-Link v2 programmer, the device is powered by the programmer and in fact when I plug it on the USB the device starts correctly. The problem is that I don't manage to connect to the microcontroller using the ST-Link utility, I always get a "can't connect" error (error message), trying with different settings.
I need to reset the chip before? How?
Thanks!!
Please check you have connected the JTAG/SWD signals from ST-Link debugger to correct pins on the target.
Also ensure the board is power.
Then check settings in ST-Link utility, check JTAG/SWD connection, speed and connect under reset which assert the NRST pin on the target in order to allow connection on JTAG/SWD pins.
If this doesn't work then it can be also the case that the MCU is protected against reading by setting an option byte (look for RDP2 in reference manual). If this bit is set then you won't be able to connect.
I'm working on a Communications Device Class (CDC) driver for an embedded device, a Full Speed implementation of USB 2.0. The COM port settings are 115200, 8-bit, no parity, 1 stop bit, no flow control. Our PC application (32-bit, Windows 7, .NET 2.0) communicates with the target device through a virtual COM port, which on the target device can connect to either a FTDI (USB-to-SCI bridge) chip or the integrated USB peripheral in the microcontroller, depending on which port is selected by the application.
Both virtual COM ports work without any problems using Realterm. However, while our desktop application works using the virtual COM port connected via the FTDI chip, it hangs when attempting to use the virtual COM connected via the microcontroller's integrated USB peripheral.
When connected via the virtual COM port using the integrated USB, the application consistently hangs on the second call to SerialPort.Write(...). Using Serial Monitor from HHD Software I can see that the data is transmitted on the first call to SerialPort.Write(...). However, that data is never received by the target device.
It's odd because the only time I have seen similar problems on previous projects was when the flow control settings on each side of the bus were mismatched.
Additional info...
Here is the data captured from various port monitoring tools while running our PC application connected to the target device via its integrated USB peripheral. Any insight would be appreciated.
Sysinternals Portmon
Advanced USB Port Monitor
Device Monitoring Studio - Request View
Device Monitoring Studio - Packet View
For those that are interested, I am using CodeWarrior 10.2 with the MCF51JM128 from Freescale.
Any ideas or suggestions would be appreciated. Thanks.
It is clear from the logs that you are making the classic mistake of not taking care of the hardware handshaking signals. That only ever works by accident, a terminal emulator like Realterm will never make that mistake.
You must set the DtrEnable property to true. That turns on the Data Terminal Ready signal. It is important because RS-232 is an unterminated bus so is subject to electrical noise when the cable is disconnected or the power turned off. DTR convinces the device that it is in fact connected to a powered device. This is emulated of course in your case but the driver or firmware will still typically implement the RS-232 behavior.
And the RtsEnable property is important, used to handshake with the device and prevent the receive buffer from overflowing when the app isn't emptying the buffer in a timely matter. You really should set the Handshake property to Handshake.RequestToSend, the most common way a device implements it. Which then also takes care of turning RTS on. If you have to use Handshake.None for some reason then you have to turn it on yourself by setting RtsEnable to true.
This ought to take of the problem. If you still have trouble then use PortMon to spy on the way Realterm initializes the driver. Compare the commands you see against the commands that the SerialPort class sends. Make sure they are the same. In value, not in sequence.