I have just started to work in a project where the product uses a imx8m mini module together with Yocto Linux (Zeus).
Currently we have a problem related to the shutdown behavior of the product, and we need to modify what happens during a shutdown.
As today when we shutdown or a thermal emergency happens, the PMIC_ON_REQ(That controls the external power regulator) goes low, but we need to change this behavior that it keeps the current value on PMIC_ON_REQ, as we have other diagnostic devices that needs to talk to the PMIC after that the imx8mm has turned off. In other words: I want to keep the value of the gpio as long as possible, until the control is out of reach.
But my current problem is that I don't know where to start, or what kernel module I shall look into.
Does any one have any clue where I shall start to look to be able to find the code for patching?
I have tried commands in devtool like "devtool modify power/thermal/soc" but without finding the needed code..
Please observe that this is my first Yocto project ever, so if I write something strange, bare with me
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 have encountered a critical issue that Unity Editor freezes. I've spent many hours debugging step by step of my codes but still can't find where the problem is. So I think maybe I should try thinking from another angle, generally speaking what reasons would cause Unity Editor freezes and not responding?
I can't find a general case discussion about this topic.
From my experience, infinite loop is one reason for sure. Deadlock is critical issue, but not sure if it causes Unity Editor freezes. Unity Editor bug that I encountered only makes the whole editor crashes, instead of freezing. Any other experiences are welcomed. Thank you!
In such case, what kind of tools or methods could I use to debug it? Right now since the editor freezes I can't use "print" to find out what happens after it freezes. So I use Visual studio to debug the Editor thread, in this way I can see all the prints that I wrote. It appears the game is still running, only the editor not responding. And I can use VS click "attach to Unity and play" and put some debugging points, then debug step by step.
The first thing that I would check out is for an infinite loop. At the hang/freeze moment, you can attatch the debugger of your choice and pause the execution. In the case that it is an infinite loop that it is executing, at the exec time pause you might find the execution in a forever running while (true) {...}
Other thing that I would check is the plugins in use. Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang. Source
To check that you can check the active threads in the visual studio command window af the freeze is reproduced:
View->OtherWindows->CommandWindow and type in this command:
Debug.ListCallStack /AllThreads /ShowExternalCode
In the stack you can check if some thread is there with no need, or if its related with the plugins mentioned above.
Also an interesting point is to check in the windows task manager (in the case that you are using windows) if the CPU usage is to 0%. It can lead you to the type of hang that is taking place.
Good luck.
Edit: I forgot to mention, you need to check also the unity logfiles
I notice this all the time, and its super frustrating.
Unfortunately, this could be any number of issues. I notice this issue most often when working in projects that are made for the Universal Windows Platform.
Try using the Task manager to monitor specific processes / threads running.
Some follow up questions:
What platform is your project currently targeting?
What version of Unity are you running? Have you tried other versions?
What are your computers specs? Is the OS up to date? Graphics Drivers?
Does it happen (or happen more often) when an external code editor is open? Perhaps try going to Preferences>External Editor > Regenerate Project files.
Are you using Unity Collab by chance? I've had issues where collab is stuck trying to communicate with Unity Servers / looking for changes. Try logging out of your Unity account through the editor, and log back in.
Have you tried looking for a Unity editor crash dump, or error log files? I think they can be found here C:\Users\username\AppData\LocalLow\Unity by default. Those files may give you more specific data concerning your problem.
Unity's new versions are getting more slower and slower. From my experience 2019 versions are the best and more stable.
I solved my issue. It's fundamentally an infinite loop.
It's not a simple case such as "while(true)". I'll try to explain.
My game was a PvP game, and I'm making a local AI. Usually my design pattern works fine, however I just turned off the simulation of "AI thinking time", and since the AI codes and server codes all run in local mode, the transmitting of data between server and client are replaced by local method call(meaning instantly executed before everything else).
There is a loophole in my server code. I use "Update" and a flag on server to change a specific game state, however in this particular case, it got into an infinite loop because the local method call is executed before the "Update". And because my AI now doesn't need real time to "think", it "acts" and transmits the event data to server right away. And since the transmitting doesn't need time any more, it calls the server method instantly, hence forming the infinite loop.
I'am currently developing an application for an embedded system (RTEMS for RPI2). As you may know developing proccess on embedded systems imply:
Modifing the program
Compile it and load it into de SD card
Insert the SD card on the board
It is a tedious process, and you can even break the SD slot for the constant usage. This is the reson why i'am trying to set up a comfortable enviroment for developing and deploying the application on the RPI. My idea is to use Eclipse as IDE for all the proccess (edit, compile and execute). So far these are my ideas for solving the different problems:
Usage of U-boot for loading the application images from TFTP. [That solves the problem of plug & unplug the SD card]
Use CTD eclipse pulgin [That solves the problem of compiling]
Use of Terminal View eclipse plugin instead of putty [That solves the problem of viewing the application console prints]
As you may notice the only problem i have unsolved is the one of executing. The idea is that whenever you compile the compiled file is located at the TFTP server directory, so it is accesible for u-boot client to load. The thing i don´t know how to do is how to tell remotely u-boot to reaload the image (the image would always have the same name). I know i can just simply reset the RPI but i don´t know if that can damage something, and also i'am curious to know if there is a more elegant way to do it.
Another thing i would like to do is to somehow specify if you want to run the application on the target or on a simulator like QEMU.
Thanks in advance
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
Bounty Update
I am leaving the question essentially the same, but I just want to point out at the beginning here that I'm most interested in help trying to get the socket between flash (Adobe Animate) and the native debugger working again, as I believe that is the issue I'm having. Or is it a socket between flash and Windows?
Original Question
I've apparently turned something off? Even when I write really bad code (like trying to call a function that isn't there or divide an integer into a fraction), the flash player boots, shows a background color and stops there. No messages in the output window or compiler errors window. If I fix my code, it all runs fine, but for about 30 minutes (ever since I started trying to work with bitmaps for a sprite sheet) I get no runtime errors no matter what kind of mistake I type in my code. Anyone know how to turn it back on?
I've checked my actionscript settings and I have both warning mode and strict mode checked on.
Could it be a socket issue? I admit I have little to no experience working with sockets and only a surface understanding of what that even means. I've added the socket tag. If someone can see that this is clearly nothing to do with sockets, by all means, I'll remove the tag.
UPDATE: 6/22/16
I just reinstalled Adobe Animate CC 2015.2 and no change. I'll try compiling it in flash builder when I get a chance to help pigeon hole the problem. (Edit 6/24: flash builder worked! But my trial version expired the next day so is no longer a viable option).
And I just tried something in the command prompt in Windows 10 as an administrator:
netsh winsock reset catalog
netsh int ip reset reset.log hit
which I found another user on flashdevelop.org used to fix a similar issue, but no change.
And I just tried debugging in Flash Builder. It worked fine (debugger caught bugs) but my trial version expired the next day.
update 6/24
I've tried launching debugger for AIR from within the Adobe Animate CC IDE and it works fine if there are no bugs; it fails to do anything visible (no Iphone emulator, no swf window) if I put a typo or error in the code.
I also just deleted winsock and winsock2, rebooted Windows, then reinstalled winsock and winsock2. No change.
update 6/25
Just tried a system restore in Windows to set all my files and settings and drivers etc. to the way it was a week and a half ago... Also completely uninstalled all Adobe products and reinstalled. No change. I can only imagine that wiping my hard drive and reinstalling Windows would do the trick, but come on, it hasn't come to that has it?
As VC.One suggested, I checked the compile error window (cannot believe I didn't check before! Maybe when I checked before there were no compile errors... Only runtime errors?) and the errors are showing up there. Does this mean that it's catching compile errors but just not runtime errors?
When you force/test a runtime error... make sure you check
Compiler Errors (ALT+F2) and also Output (F2). By Output I mean the window that shows traces (and runtime issues). One of those two should have some feedback for you.
A possible solution is to save a new Workspace. So with those windows for Compiler Errors and Output both open (or tabbed, I tab them next to my Timeline) go to Window (in top options like File/Edit/Debug etc) and choose Workspace, then into that you choose New Workspace. Give it a name in the pop-up and okay everything.
Flash should always load that current workspace (next time, go to Workspace option again, check that your specified workspace [by name] has a tick next to it...).
Possible pitfalls:
1 - Use the debug player
2 - Make sure there isn't somewhere a try/catch enclosing the portion of code that triggers the event that may lead to an error
3 - Socket issue: may be exported in debug mode but swf cannot connect to debugger (it waits in a blank state for 60 seconds I guess)
4 - Does it compile ok? If there are compilation errors you may get an SWF anyway but then it will not start
...