I am new here but I hope you can help me to find a solution to my problem.
I have four PIGRRL Kit from Adafruit and I need to install in it Raspbian (Operating System), the PiTFT and the gamepad as shown here (https://learn.adafruit.com/pigrrl-2/software).
But, when I try to install the gamepad, the OS goes in loop and the only way to exit it is to restart everything. I have checked if there were some problems with the soldering, but the voltage machine is not showing me any problem of the kind. The problem is just on the gamepad, because at the PITFT installation step everything goes fine and works.
But when I install the gamepad it goes in loop.
I used these commands:
cd
curl -O https://raw.githubusercontent.com/adafruit/Raspberry-Pi-Installer-Scripts/master/retrogame.sh
sudo bash retrogame.sh
And then I follow the instructions for PIGRRL 2.0. But when I reboot, the OS loops.
Any idea or suggestion?
Thanks anyway!
I didn't tried retrogame, but I'm trying to use PiTFT 28 capacitive.
What I can say is that have some troubles with the display :).
In the first time I follow exactly they procedure and made my software work perfectly. But at some point in time it started to reboot after starting the software.
So I tried to start all over again, but this time I used Diet Pi and follow an alternative solution. I follow the procedure on this page: http://www.0xf8.org/2016/01/complete-rotation-support-for-the-adafruit-pitft-2-8-capacitive-touchscreen-display/
The display works, but:
1. If I use other console font, it starting immediately the font is going active.
2. The mouse don't work so well, it seems to start all the time in the left corner. So I didn't manage this part. :).
Maybe my answer can be useful in the combination of your experience.
Bafta
I found a solution. The problem for me was solved by charging the batteries. Basically, when it first reboots the OS needs more energy and with no charged batteries it went in loop.
All the best!
Related
I since a few months, I have been using a Hyperpixel 4.0 Touchscreen with my Raspberry 3B+ without any problems. Since a few weeks i use my touchscreen with the Raspberry Pi 4 Compute module and mounted both on my own designed PCB. Unfortunately, I’m facing some difficulties with the Touch function of my Hyperpixel 4.0. I have no clue how to solve these problems because the circumstances, which cause the fault don’t make sense to me.
Which System do I use?
Hyperpixel 4.0 in combination with Raspberry ComputeModule 4 with 2GB RAM and 8GB onBoard eMMC. Both is mounted on my custom PCB, which is supplied with 24V, stepped down by an «APP63300WU-7» Step down converter, which provides 3A # 5.1V continuous output. The measured Voltage over 2 Days of measurement is a maximum of 5.2V and a minimum of 5.05V. The software ist the latest Raspbian.
What error is caused?
I have been running a GUI on my Raspberry Pi. I have one Page on which i have three sliders for changing brightness of my room light, colortemperature and one slide is to regulate the speed of some fans. Everything works fine in darkmode, but if I change to lightmode and touch the screen for about 1.5 seconds, the touch- function hangs up. My GUI doesn’t move anymore and I have a still image. I know that it’s only the touch function beacause if I plug in a keyboard and mouse, I can open for example chromium or other stuff without problems. With «i2cdetect »-command I can detect the Goodix GT911 driver on Address 0x14. Even if the touch has hung up, i can detect the Goodix GT911. I know that the address should probably be 0x5D but I thought it isn’t necessary to care about this problem as long as it works. After a reboot, the touchscreen works fine again until i use the lightmode of my GUI. Interesting to mention is, that i can click a thousand times for around 0,25seconds and no problems occur. But if I touch the screen permanently for around 1,5seconds, I instantly get my above described problems. Generally considered, this problems seems very strange to me and it doesn’t behave like any physical law i know…
On the first view, the error seems like a software issue ? Hear this!
If i use the official «Compute Module 4 IO-Board » to mount my Compute Module and Touchscreen, I don’t get the issue at all… My actual designed PCB ist the 2nd version. On the 1st version It also worked fine without any problems. The only differnce between version 1 and 2 is the wiring, which I tried to improve on the 2nd version and viewer parts which I only put on my 1st version to evaluate some functionalities like ethernet or 2nd I2C-Bus, which I’m not using on my 2nd version. The wiring did not change between these two versions, i only tried to increase the distance between the GPIO-traces to improve signal integrity.
So it seems like a hardware problem? But why does the GUI work fine in darkmode? I don’t have any explanation to that.
What did I do to narrow down the error?
I flashed a new image on my Compute Module and also used another Compute Module, Custom PCB and touchscreen as well, but without any success. As far as I experienced, the issue is only caused on my GUI and not on any other websites or images, etc. An interesting thing was the interrupt line, which is typically only drawn to 0Volts if the touchscreen gets touched. After the touchscreen hung up, I measured 0,084V on that line and as long as I touched the screen, this voltage rised to about 0,2V, which for me seems also like a strange behaviour. I also checked the «dmseg» file and got some entries for failed i2c tests of the GoodixGT911. I also tried the github fix for the swapped i2c address, but without success. I used the command «git clone GitHub - pimoroni/hyperpixel4: Driver for the Pimoroni HyperPixel 4.0" Touchscreen Display -b pi4-i2c-fix » for that.
What do I try next?
I dont have any clue what to do next. My only solution in mind, is to undo the «improved» wiring of my 2nd PCB to get as close as possible my first PCB version.
Conclusion :
I really need help and hope, someone can do me this favour. I’ve never found my described error behaviour in any forum. Are there any other usable forums for problems with the Hyperpixel 4.0? Let me please know.
Update:
I tried to reproduce the errors and specify the error source. As above mentioned, the touchdriver hangs up on lightmode (nearly every pixel on rgb(255,255,255)). If i change the color in lightmode to around rgb(245,245,245) the error does not occur. I also noticed that there are two flatband cables on the Hyperpixel 4.0: One for displaying the image and another for the whole I2C-Communication to the touch driver. I plugged out the one for displaying the image and got no problems at all. Even if was theoretically in lightmode(if display would have been on). The touchscreen worked fine and transmitted everyting flawless:
Conclusion on my Update: It seems as the rgb(666) datalines for displaying the image on the screen cause some problems on the I2C bus. I also checked the bus and the power supply with an oscilloscope but I haven't seen any unusual behaviour in any case. Voltage ripple was around 200mV Peak to Peak and the I2C-Datalines rised and fell really sharp
I still need help from you!
Thanks, Manuel
I'm running Quartus Prime Lite 16.1 on Ubuntu 16.04 and I want to start using Models-Altera, but when I click on "Tools"->"Run simulation tool"->"RTL simulation" it shows me a pop up window saying that I need to point to my license (please see the picture attached), but before running the Quartus setup installation I specifically selected the Models free version.
I had a similar problem with Signal Tap Analyzer, also requesting pointing to a licence or some similar wording. Maybe the solution applies also for the RTL simulation.
The solution that worked for me was to go to the Tools->Options->internet connectivity and enable “talkback options”.
I had found the solution here: https://mil.ufl.edu/4712/docs/SignalTap_Tutorial.pdf
I recently had a frustrating problem:
Modbus-connection throws in bError 4 as soon as bExecute is turned on. No variables could be read, and error persisted until reboot.
Previously working project stopped working over the weekend.
I might have fiddled around inside PLC, uninstalling couple libraries mainly, but logically thinking nothing should be wrong and I didnt do much at all. Its still possible I done goofed on friday, and didnt notice until after weekend.
On to the troubleshooting:
Reboot both machines
State machine is fine. Even made stripped-down project with one input and output and previously working minimalist state machine.
Reinstalled Modbus library in PC and PLC
Git revert the code couple weeks to a time when I 100% knew it worked.
PLC can ping PC in 1ms
Had an old project zipped in store, including "original" libraries
Reboot again
I still could wipe out PLC OS and start anew, but lets save that off for now.
"Thats all a mere mortal can do." I thought, and shot off a mail to Beckhoff.
Lets shoot off a mail to Beckhoff support.
Troubleshooting ensues:
Strip down the program even further, so only FB_MBReadInputs stays and bExecute can be flipped on or off manually.
Running only MBReadInputs, only MBWriteCoils, both at the same time
bError 4 problem persists no matter how much is stripped or ran.
Running the same project Locally on PC works just fine. Inputs can be read and output bits can be written.
In the end, flashing new image ended up being the solution.
Still in process of fiddling that out, so the actual problem isnt yet solved.
Update: Stuff works as it should. Some cosmic ray must have hit SD-card just right so during the weekend things got awry and problems surfaced.
Beckhoff image repo in my case: https://download.beckhoff.com/download/software/embPC-Control/CX90xx/CX9020/CE/TC3
Thats it, in the end wiping out SD-card is pretty basic thing to do when facing larger problems, but I just wanted to go through all the troubleshooting steps and end results for anyone struggling with Modbus and Twincat as much as I have.
I just reached out the same problem on CX8180. In my case there was some program uploaded before mine. I've activate my configuration and run PLC - get bError 4. TwinCAT errors code list says that is something with ADS mailbox and too much ADS calls. My program works fine on the same hardware elsewhere. Restart origin and activate configuration doesn't work.
I need to login with CeRHost and make a reboot of PLC. After that move communication works like a charm. The problem was the previous modbus communication.
I seem to have a problem for one the servers that i am handling, i have reinstalled CentOS for nth times, and formated everything, edited the grub.conf time out = 0, but all still the same, the grub timer wont move, always stuck.
Did you end up finding a solution to this? I just had a server with this exact issue right after a fresh install of CentOS 6.x. Even though the system seemed to be keeping correct time, replacing the CMOS battery resolved the issue for me. This was either due to a faulty battery, or the CMOS settings getting reset when I replaced the battery.
Here are the sites that led me to that solution:
https://serverfault.com/questions/42877/grub-hangs-after-x-2-seconds
http://www.tomshardware.com/answers/id-1809044/centos-grub-countdown-stops.html
A user on one of those sites said that clearing the "System Event Log" fixed the issue for them. Here are some guides on accessing and clearing the SEL/BMC log:
http://download.intel.com/support/motherboards/server/s7000fc4ur/sb/sel_viewer_ug_e1246101.pdf
http://www-947.ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-59226
The issue could also be related to Grub's recordfail logic. More info here:
https://askubuntu.com/questions/202309/cannot-get-grub-menu-to-timeout-or-go-away?newreg=dc178d813fbb4f0d803644799bb89c5e
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/872244
Try adding this to /etc/default/grub
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=$GRUB_TIMEOUT
Then run sudo update-grub
Support for GRUB_RECORDFAIL_TIMEOUT was added in the middle of the 12.04 cycle, starting from version 1.99-21ubuntu3.3
Check the date/time setup of your server. After I changed the CMOS battery, server's (HP Proliant) clock was 4 days behind and had same issue, the problem was fixed after setting it up correctly.
I am having some trouble uploading code to my Seeeduino ADK (essentially a Arduino Mega 2560) using Eclipse. Basically, this thread explains my problem. Sometimes I get a series of timeouts using the Arduino IDE upload, which is usually fixed by removing and re-inserting the USB. Unfortunately enough, this does not help fix the problem in Eclipse.
I have been trying to do the upload using AVRdude via the command line (I even tried the "hacky" solution in the last comment of the above thread), but to no avail. This is the line I am using for this:
"%AVR_DUDE%" -pm2560 -cstk500v2 -P\\.\%COMM_PORT% -b115200 -F -V -D - Uflash:w:"%HEX_FILE%":a -C"%AVR_DUDE_CONF%"
Which gives me:
avrdude.exe: stk500v2_ReceiveMessage(): timeout
I know the above batch variables are OK, because AVRdude runs correctly (but then it times out). If anyone has any ideas or tips that could help me with my uploading I would greatly appreciate it. Thanks beforehand.
EDIT: As it turns out, the reason for this may be that the Arduino IDE sends a reset to the board before uploading, something which the Eclipse AVR plugin does not do. I will test this and write a uploading perl script, but I am fairly certain this is the problem.
Your suspicion is correct. The Arduino IDE uses a patched version of AVRDude to pulse the DTR line and reset the board before each upload. For some reason, some people have had difficulty getting the right command line parameters to replicate this on the Mega2560. I've had the same problem myself - ATMega328's work with no problem, but the 2560 needs to be reset manually.
There's some further explanation and tips for possibly getting it working here (check the comments too): http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
Check out the detail here... http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
If using avrdude > version 5.1 change the programmer to -cwiring
This will reset the chip first