We have CI set up and very often our EVM boards (DSP boards) goes into a wrong state (reason unknown!!)and USB emulation was failing; to over come the issue we used to power reset the EVM board and everything used to work fine;
Now we have started using RPM (Remote Power Management) utility using which we can remotely reset the power on the device but unfortunately this doesnt seems to be working fine!!
We are able to reset the power on the EVM Board but we are unable to bring back the EVM board to working condition we are still getting USB emulation failure!!
Any thoughts on this; BTW we tried mulitple times resetting the power on EVM board using RPM but still same issue
Appreciate your help in this regard.
Raju
Related
We have an embedded board that has an iMX8M-Plus Processor and Linux v5.4.161. This board has one PCIe bus and that one is connected to an FPGA. When we power up the board, the FPGA is not yet configured, so it acts as if it was not on the PCIe bus.
Once the Linux is fully booted, we configure the FPGA and only after that it starts acting as a PCIe endpoint (device).
At this point, when I run lspci -> it returns nothing.
When I first execute echo "1" > /sys/bus/pci/rescan as suggested here and here and then lspci, I still get nothing.
But if I reboot the linux without reseting the FPGA, it starts being visible in the lspci list. Rebooting the linux is not an option for us. Somehow I need to tell the linux that whatever it's doing at the boot time, please do it again at runtime. But I couldn't find a solution for this so far.
According to the Texas Instrument support forum, they said if the PCIe link is not trained at the boot time, rescan command never works.
At the boot time, while linux loads a pci driver, it tries to establish a PCIe link, I can see that with an oscilloscope, PERST pin is asserted and PCIE_CLK generated for a while and then stops if it can not detect any device. But the rescan command never does that.
Also in the system there is no pcie device to executeecho 1 > $pcidevice/remove in order to make rescan functional. Or there is no device or bus to set power off and on back like echo 0 > /sys/bus/pci/slots/.../power
I also learned that there was a method in old linux times (v2.6) called adding a Fake PCIe Device which physically doesn't exist to solve this problem. For that I took the fakephp.c driver from an old linux repo and ported it to ours. After solving a couple of deprecated function problems, it is compiled for Linux Kernel v5.4. modprobe fakephp worked and driver loaded but somehow I didn't get this fake device in my device list. Here it is mentioned that the fakephp driver was removed from mainstream linux since PCI core has similar functionality, but he never mentioned how.
Short of the story is that, I am stuck here, I need my FPGA to be visible in the lspci list without restarting the linux.
I recommend configuring the FPGA in u-boot to get away from these kinds of problems. Connect up SPI pins to FPGA's config pins & run it in Slave configuration mode.
I've been using a STM32H753I-EVAL2 board for several months now.
Last week I was suddenly not able to connect to the board anymore (tried with several tools: GDB, STM32cubeProgrammer, always same message like "STLink error"). I of course checked the driver was correctly installed and was the right one, reinstalled it, changed USB cable and ports. Also tried to connect to a Nucleo which was fine.
I randomly tried to change the power supply of the board from PSU (ie. powering through external power supply) to STLink (powering through USB) and it solved the issue. I was happy as I thought it was just a hardware issue like a conflict between both power supplies.
But today the board was not connecting anymore again. So I switched back the alim to PSU and it worked !
Did someone experience the same issue ? Or does it trigger something for someone ?
I have a DJI S900 with A3 controller. I established the API connection between the Raspberry Pi and the drone. Until last week everything has been perfect, but now, I am taking the error shown below (I am running the telemetry example).
There is no problem related to the serial cable and Raspberry Pi. Also, SDK is enabled, and API settings are correct. I reset the controller and upgraded it. However, I have the same error. Also, I tried many times turning everything off and back on again before upgrading the controller.
A3 firmware = V1.7.7.0,
OSDK = 3.8.1,
Raspberry Pi operating system = Rasbian,
Lightbridge 2 = 1.1.40
Read App ID
User Configuration read successfully.
STATUS/1 # init, L55: Attempting to open device /dev/serial0 with
baudrate 230400...
STATUS/1 # init, L65: ...Serial started successfully.
ERRORLOG/1 # getDroneVersion, L1418: Drone version not obtained! Please
do not proceed.
Possible reasons:
Serial port connection:
* SDK is not enabled, please check DJI Assistant2 -> SDK ->
[v] Enable API Control.
* Baudrate is not correct, please double-check from DJI
Assistant2 -> SDK -> baudrate.
* TX and RX pins are inverted.
* Serial port is occupied by another program.
* Permission required. Please do 'sudo usermod -a -G dialout
$USER' (you do not need to replace $USER with your username). Then logout
and login again
ERRORLOG/1 # activate, L1302: Unable to initialize some vehicle
components!
STATUS/1 # getErrorCodeMessage, L656: initVehicle
STATUS/1 # getCommonErrorCodeMessage, L722: ACK_NO_RESPONSE_ERROR
Vehicle not initialized, exiting.
Information you have given is not enough, there could be many possibilities. Please go through with the following checklist (this is what first comes to my mind, if I remember sth new, I`ll add it in)
The list is meant for error such as Drone version not obtained or new device error or first success connection(get firmware) then failed activation for Both DJI OSDK and DJI OSDK-ROS
Does UART on RPI is enabled? if not, enable it. Are you using the correct serial ID as well? If not, set it right. Recommend using /dev/serial/by-id/usb-XXX method
Does Baud rate in DJI assisatnt2 is same as the one in the USERCONFIG file of OSDK? if not, make it same
Did u give permission to the serial device e.g sudo chmod a+rw or sudo usermod -a -G dialout $USER or set the udev rule . If not choose a way to get it right.
FTDI series problems
4.1 Did you use this FTDI cable successfully on other platform before?(to make sure tx rx is correct)
4.2 Is this FTDI 3.3V? If not, high chance your FCU board is already burned. Send it back for repair.
4.3 Measure the voltage on Tx and RX pin while everything is connected, is it being pulled up at 3.3V? if less than 3 then there is a serious communication issue.
4.4 Is there EMI generator around?( this one happen to me once, took me 2 weeks to isolate the issue, EMI cause unreliable connection)
4.5 As an additional test, prob the tx and tx by Y cable using real-term to see if you can see any proper communication happening.
Did u forget to turn on the RC ? If so turn it on while calling the sdk.launch
GO app side issue
6.1 Did u connect the Go app while running sdk.launch? If not connect by GO app, connect it as it will pop up sth.
6.2 Did you login to your account which creates the app id?If not, login to it.
6.3 And is your account being banned for flying in the non-authorized area before(e.g caught by DJI aeroscope/Flyhub) and police is actually going after you? If so, stop playing the drone and surrender urself in. Normally it should be max of one year Jail time, but if you resist, the punishment can be more deadly.
Did u give authority from GO app? click ok or confirm on the GO App once you run sdk.launch in the RPI. Once you launch the sdk, the Go app will pop up sth, Did u do/experience it? After changing the firmware, you should experience this again.
Did u tried the hardware with the 3.8 with a Normal X86/X64 Intel PC/notebook with Ubuntu 16/18 before? is it working? ( rule out hardware / connection issue ) If can work, then its RPI issue. If can not, high chance drone/RC side. I do have couple RPI burn down experience b4.
Did u have valid/correct app id and enc key? double check it. If not, enter is correct.
Is the voltage supplied to A3 stable and clean?
Have you tried this way of calling? /the_sample_u_wish_to_run UserConfig.txt /dev/ttyACM0 (this is what I gathered from other peoples experience)
Which version of RPI you are using, if you are using 2 series, the high chance you have to use https://github.com/dji-sdk/Onboard-SDK/tree/raspberrypi-support with older version firmware. I only tested with RPI 3B. Can not guarantee the function of other versions. That's why number 8 is important to isolate the issue.
Are you calling the sdk.launch from somewhere else? make sure you only call it once and prevent it from being calling again. Make sure the serial port is not occupied.
Make sure API is enabled in DJI assistant2. Close everything power on and connect to DJI assistant 2 again to verify this. If by any chance the board has an issue, the API enable you set in the previous run will get auto deselected. This is to rule out burned FCU board issue.
If by now it is still can not work, then you should try other 3.8 or 3.7 with firmware 1.7.7 and 1.7.5 or whatever firmware you can access. as far as I know, their delay+ wait for ACK always have all sorts of issues. Maybe adding more delay in the wait for serial ack will help you(solution from other github dji_osdk post)
In case of this particular A3 burned, swap another fresh open A3 and proven working FTDI cable(test with Arduino) to rule out the A3 problem
Edit
17. If you are using m210 v2, the activation pop up will not shown on pilot app. Run the dji assistant 2 first and then call the sdk.launch twice.
If still no luck, file a ticket to dev#dji.com + send a complaint to Samuel#DJI. Send them the long list of thing you tested, and if they say high chance it is a hardware issue. Do send it back for RMA. I do have experience of one Normal A3 and one M600 A3 has burned FCU board issue before.
After this, if you encounter can not fly GPS mission by OSDK or can not do local flight control. Just try different firmware version. DJI firmware release is usually very buggy for developer.
I am developing on an ARM Mbed board which connects to my Windows laptop over USB. I've just moved to a new Dell laptop running Win 10 [from a Dell laptop running Win 7] and I find that the laptop resets my development board every 15 minutes.
There are two things that will cause the ARM Mbed board to reset:
powering down/up the USB connection
sending "break" via the USB serial driver.
When the reset occurs there is nothing of note in the Windows event logs. I have all of the "allow Windows to power me down" boxes unticked on the USB hubs in System devices and in the Control Panel power management options.
Does anyone have any suggestions on how I (a) debug what's going on or (b) fix/workaround the problem? I've not yet tried connecting via a powered USB hub, will do that next...
I had the same issue using a FRDM-K64F running mBed and communicating over a USB COM port to a Windows 7 Dell machine. The communication would sometimes drop out. As #Rob suggested, uninstalling the Dell Support Assist Agent completely fixed the issue.
Just adding this answer as it was very difficult to find any information using google.
Another note in support of this solution for google...
I have a Dell 5480 running Windows 10, and started using from ST Nucleo boards on it. I've used the exact same boards at work, with no problems. Every 15minutes or so the board was reset.
I tried disabling the Dell Support Assist services but this did not seem to fix the problem.
Removing the programs did make the Nucleo work.
I bought my Arduino Uno R3 a few months ago. It's been working like a charm since then, but today, it stopped interfacing with my computer. Let me be more specific. I have a 2013 Macbook Pro Retina with OS X 10.9 (Mavericks). It has the latest Arduino IDE installed.
I was using it today and after uploading a simple sketch (it worked for a little while) my Mac stopped recognizing it, and since, I haven't been able to access it. The LED connected to Pin 13 stays on 100% of the time. The RX/TX LEDs don't flash, but the main functions of my sketch (other than the serial functions).
Have I screwed my Arduino's Serial chip? What can I do? I am only 15, so another $30 is a little bit too much to spend to get another one.... :)
Thanks!!
UPDATE: I forgot to mention that I have tried my other Windows computer, and another cable, just to rule out those possibilities.
That is a very common issue with Arduino. I used to face that problem all the time while using Arduino. Though I never really found a solution for this, the problem did go away after sometime. Did you try resetting the uC using the reset button on the board, or restarting the IDE or your system if neither worked?
Make sure you have chosen the right COM port. On a windows system you can do this by going to device manager and look for the ports tab under it.