I stumbled upon following problem:
I have a piece of software written in C++ and a device rk3399 (FriendlyELEC). The issue is performance of the code depends on whether or not display is attached to the device. If I ran my code via ssh (without display attached) I get 25% slower performance rather than if I ran code with display attached.
I figured it's a frequency scaling problem (device runs Lubuntu) I changed profile to performance (it was set to interactive initially), but that didn't help. I monitored voltage and cpu freq, all seems constant (1.2V, 1.12V) and (1.42 GHz, 1.8 GHz).
It's probably some control that tries to save battery and uses Display Port as decision flag. But I can't figure out what kind it is and where to find it.
Initially I was thinking I have problem with GCC flags (there could be some relevant info)
How to get the device to run with stable performance? What could be the problem?
Related
I'm currently working on an IoT project and I want to log the execution of my software and hardware.
I want to log them then send them to some DB in case I need to have a look at my device remotely.
The wip IoT device will have to be as minimal as possible so the act of having to write very often inside a flash memory module seems weird to me.
I know that it will run the RTOS OS Nucleus on an Cortex-M4 with some modules connected through SPI.
Can someone with more expertise enlighten me ?
Thanks.
You will have to estimate your hourly/daily/whatever data volume that needs to go into the log and extrapolate to the expected lifetime of your product. Microcontroller flash usually isn't made for logging and thus it features neither enduring flash cells (some 10K-100K write cycles usually compared to 1M or more for dedicated data chips - look it up in the uC spec sheet) nor wear leveling. Wear leveling is any method which prevents software from writing to the same physical cell too frequently (which would e.g. be the directory for a simple file system).
For your log you will have to create a quite clever or complex method to circumvent any flash lifetime problems.
But the problems don't stop there: usually the MCU isn't able to read from Flash memory when writing to it where "writing" means a prolonged (several microseconds up to milliseconds depending on the chip) sequence of instructions controlling the internal Flash statemachine (programming voltage, saturation times, etc.) until the new values have reliably settled in the memory. And, maybe you guessed it, "reading" in this context also means reading instructions, that is you have to make sure that whichever code and interrupts that may occur during the Flash write are only executing code in RAM, cache or other memories and not in the normal instruction memory. It is doable but the more complex the SW system that you are running above the HW layer, the less likely it will work reliably.
I have a problem with stability running TI AM5728 based custom board, similar to the Beaglebone X15. RTOS SW is running on one Cortex-A15 core MPU0 and sporadically (most often after several hours) freezes. When freezes it is impossible to connect to the MPU0 target by debugger, at the same time I can without any problems connect to the MPU1.
Debugger error:
CortexA15_0: Trouble Halting Target CPU: (Error -1323 # 0x1386AC)
Device failed to enter debug/halt mode because pipeline is stalled.
Power-cycle the board. If error persists, confirm configuration and/or
try more reliable JTAG settings (e.g. lower TCLK). (Emulation package
6.0.504.1)
For test purposes, I have started the simple program on the MPU1, and when MPU0 freezes MPU1 continue normal operation. WFE and WFI flag for MPU0 is inactive, moreover, I have made the additional test with trying to put MPU1 to the WFI/FORCED_OFF state. However, I still can connect with debugger and wakeup it from the FORCED_OFF state, as described in the technical manual.
I have dumped the registers by connection to the CS_DAP_DebugSS and have not found anything special. Register dump attached:
MPU_PRCM_PRM_C0_PM_CPU0_PWRSTCTRL
MPU_PRCM_DEVICE_PRM_RSTST
MPU_WUGEN_WKG_CONTROL_0
MPU_PRCM_CM_C0_CM_CPU0_CLKSTCTRL
What can be the potential stuck problem of just one core with failed attempts to connect with the debugger and second core running without problems?
Which hardware/software problem can potentially cause such behavior?
Thank you for any suggestions.
I just encounter the exact same problem.
Did you check your code at the address provided with the JTAG error (Error -1323 # 0x1386AC)? In my case it is an GPMC access, to a FPGA, which I can still access through CS_DAP_DebugSS.
I'm currently looking at errata i878, from revision L of the document. As it can take more than 48h to hang under stress test, I won't blindly apply the workaround. I'll modify my test, based on i878, trying to increase the failure rate, then I'll apply the workaround.
I have successfully tested basic DroneKit scripts on a companion computer (Raspberry Pi) to achieve autonomous flight on Pixhawk controlled 3DR ArduCopter. The RPi is also connected to various sensors, and crunches that data in real time in the same python script- to influence the flight.
Is it possible to pilot the drone manually with a Taranis as usual, while RPi (with DroneKit running) remains connected to Pixhawk and overrides the radio when needed? For example, a background prevention mechanism that takes control and moves the copter away if the pilot is about to crash into a wall (which is easily sensed using a LIDAR).
Thank you!
While your vehicle is in any mode other than GUIDED, your dronekit script will not be able to control behaviour. However, the script can change the mode of the copter to GUIDED, send some commands, and then set the mode back to the previous mode when it is done.
The example you gave of using lidar for obstacle avoidance is already a feature in progress, being built directly into normal flight modes. Perhaps it's not documented well enough yet, but maybe try digging into the code to see how it works.
I am trying to program a Cortex M4 that was placed on a custom board. The processor is the MK64FN1M0VLL12. I wrote the code using the FRDM-K64F dev board, which uses OpenSDA to load the bin via USB. The code was written in mbed, which as far as I know doesn’t have any support for loading the program to the processor. For the production board, I was planning on loading the program via a J-Link programmer, since I didn’t include the OpenSDA interface.
Using the J-Link Commander tool, I’ve found that I have to hold the reset button down on the board in order to get any sort of response. When I don’t hold down reset, I get the follow:
When I do hold down reset, I get:
When I try to load the bin, I get messages about the CPU not halting. I get this whether I’m still holding down reset or not:
The O.K. message is a little misleading. I tried uploading a program with just a blinking LED, but the LED isn’t blinking.
I’m not sure where to go from here. Several days of Googling hasn’t led me anywhere fruitful.
I have a question to exclusive compute mode with NVidia+OpenCL.
I can set up exclusive compute mode (page 74 from cuda programming guide 3.0) with nvidia-smi on a nvidia-gpu . that means, only one program can compute on gpu.
cuda runtime schedules than app automatically.
but I have a problem with opencl-programs in this case:
if one application runs on a gpu with setted exclusive compute mode and second opencl-program calls clGetDeviceInfo(..., CL_DEVICE_AVAILABLE, ...) with the same GPU is the result == CL_TRUE. After that if opencl-app tries to create a context on this device, than crashes the running app (both).
How can i find out an available GPU with OpenCL?
Thanks.
clGetDeviceIds returns the number of devices and their device Ids. Then you can check if each of the device is available or not. Iam not sure if it would resolve the crash though.
I've had a similar issue where I wanted to find the best OpenCL device in a list. I couldn't find a solution so I've wrote one myself. It will try to create a context on a device. If it can't, it will try the next one.
It also supports multiple OpenCL platforms. You can choose between nvidia (gpu only), amd (gpu & cpu), intel (cpu) and apple (gpu & cpu).
You can find it on github: https://github.com/nbigaouette/oclutils/
I'm still looking for a better locking mechanism though.