I am trying to program arduino pro mini (3.3v version) via hc-05 bluetooth module. I was getting "avrdude: stk500_getsync(): not in sync: resp=0x00 arduino" error. There are plenty of questions/answers for this error which if I am not mistaken is caused by the lack of connection between the programmer and arduino board.
Since then I made some changes, both hardware and software and am getting serial messages printed on arduino serial console meaning there is a connection and the error has changed to something that has barely a few mentions searching on google.
avrdude: stk500_getsync(): not in sync: resp=0x4c
What is this error exactly? Is there a list of possible errors thrown by avrdude anywhere?
I might be mistaken about the precise error, but recently I had a problem like that caused by enabling the watchdog timer - what wasn't being correctly handled by my bootloader - and it gave me a similar error message. On my case it caused my code to get stuck in some point making impossible to upload new code; in other cases - usually when the watchdog timer is configured to less than 2 seconds - it may cause the board to restart fast enough to do not allow the bootloader to fully initialize.
To solve that I've found two possible approaches:
Upload the bootloader again - I couldn't make it work, but some people do. I'm almost sure that I did something wrong.
Wire the Reset port to GND, upload a new code and as soon as it goes from compiling to uploading you take the wire off. This worked for me on an Arduino Mega 2560.
Related
I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++
What I am looking for: I need help debugging consistently happening system crashes on my Jetson TK1.
System: I am using a Jetson TK1 board from NVIDIA. Updated to 21.3.4 Grinch Kernel. All drivers installed, libopencv4tegra installed alongside ROS (using hacked deb packages to not overwrite openCV). Everything used to work perfectly in this exact setup.
When the crashes happen: I am running a VSLAM program, which uses a camera connected on the USB port. The program is making heavy use of OpenCV. The program used to run for over 1 month without problems in the current setup. Now, I am getting consistent system crashes which result in a total system freeze. When I am connected over ssh, I loose connection. When I connect a monitor to see what happens on the system while it crashes, I can see everything freeze. The USB port also seems to turn off, since not even USB mouse and keyboard work anymore post-crash. The Jetson stays on though.
Crash Logs: I have tried looking into the /var/log/ logs, but none of them show any messages for when the crash happens.
I have run memtester before. It didn't return any bad memory. While running and crashing, the memory onboard is used at about 60-75% (as shown by "top"). CPU usage is around 60%.
The weird thing is that this exact setup has been running just like this for over a month now.
I need to know: are there any other logs I could find information about the crash in? How could I find out if this is related to a hardware failure or whether there's a software issue?
Thanks
-Marc
I'm trying to get the node-hid (https://github.com/node-hid/node-hid) module working on Windows 7. I can open a device and write to it, but no data ever arrives.
I've verified the device is sending data. I've dug through the node-hid code (HID.cc) and tried several things to get it working:
Modified the HID::recvAsync function to use an hid_read_timeout in a loop to see if that would return anything.
Set both blocking and non-blocking.
Changed buffer sizes to exactly fit what the device sends.
On Windows 8, with the hid_read_timeout call change, this all works fine. I'm not sure what may have changed between the two systems, but I plan on using this on windows XP as well, so I can't just call it good.
I'm struggling to come up with more ideas as to how to debug this issue. Has anyone successfully done this before? Is there a better option to use Node.js with an HID device?
After some serious debugging, I found that for some reason I have as of yet not been able to determine, the source file, HID.cc for the node module node-hid needed a call to hid_init() within the constructor before the hid_open call. I'm assuming that somehow this is getting hit with multiple threads, making the safety of calling hid_init before hid_open necessary.
I now have this working on both windows 7 and windows 8.
Summary of changes I had to make:
Add hid_init before the hid_open call I'm using.
Change hid_read to hid_read_timeout in a loop. (Since reads won't return on windows XP when shutting down otherwise.)
Once I've cleaned it up, I'll send the author my changes.
I'm trying to setup simple kernel debugging, I have a 3.2.6 kernel on VM (ESXi), which I declared a serial port (I manage to connect to the serial )
Debugger:
Debuggee:
I followed this tutorial on how to setup gdb, and I seem to be getting replies (the serial port seems to be fine) when I start debugging, however gdb is getting junk and doesn't manage to debug anything,
I encountered a thread on lkml from 2k10 which stated a similar problem on 2.6.35 kernel, however a patch has been committed (I guess went into mainstream) and I'm trying to debug 3.2.6
This is what I'm getting from gdb :
and here's a the output from the vm:
Can anyone hint me on how to solve it ?
(If any mod could edit my message and transform all images to real images and links to real links that would be awesome too, the system didn't allow that and I have to edit my post 4-5 times before posting :/ )
The situation is this: I have a USB device (a custom device I'm trying to talk to) with two endpoints, one writing to the device, one reading from the device. Both are bulk transfers. Every communication transaction takes the form of (1) Write a command to the device (2) Read the response. I'm using libusb (version 0.1 rather than the 1.0 beta) to actually perform the communications.
On Windows, all is well. I can connect the device, claim the interface and communicate happily. However, in Ubuntu (a standard Hardy desktop install), whilst I can connect to the device and write to it, all read operations fail with the error "error submitting URB: Invalid argument" reported from libusb (error code -22).
If I check /var/log/messages I see a warning message logged for the same time as the read was attempted: "sysfs: duplicate filename 'usbdev4.3_ep81' can not be created" - which tallies with the device (it is indeed on that bus and it's endpoint 81 I'm trying to read from).
So... anyone seen a similar problem using libusb, or have any idea how to fix it?
Turns out it was a misconfiguration in the descriptors on the device itself. lsusb -v showed an extra interface which was never used, which had a single isochronous endpoint 0x81. Since this was never used (and had never been tested as far as I could see, so quite possibly not even defined correctly) I removed it from the device descriptors completely (in the firmware).
And now I have a fully working device. Why linux refused to read from the device but Windows worked fine I don't know, but it definitely sent me on a wild goose chase.
I haven't used libusb in quite some time -- but the sysfs error indicates that this is likely to be a kernel problem rather than a libusb one, so I'd start by trying to track that one down. (Not much point in trying to work with libusb until you're sure your kernel is talking to the device correctly).
Does the patch at http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/17/345922 apply to your kernel? (If so, does it fix the issue?)
I had to do some hacking to udev rules to get the device created with the right permissions for libusb to work. Like so:
SUBSYSTEM=="usb" ATTRS{idVendor}=="0a81", ATTRS{idProduct}=="0701", \
MODE="0666" SYMLINK+="missile_launcher"
(This was an usb missile launcher I was writing a driver for.
Also this snippet was required to not clash with the kernel.
if(LIBUSB_HAS_DETACH_KERNEL_DRIVER_NP)
{
// Detach kernel driver (usbhid) from device interface. (Linux hack)
usb_detach_kernel_driver_np(launcher, 0);
usb_detach_kernel_driver_np(launcher, 1);
}
I'm not sure how this relates to your problem, but atleast there are two possible points of failure that might be involved.
You can try WinDriver it's a commercial tool but have free full function evaluation (somehow time limited). You can check with WinDriver and if problem is reproducible it's might be device or your protocol fault. You did not give enough information to determine or analyze.