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.
Related
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?
I'm trying to programm my PIC 16F628A with PICKIT3 in MPlabX, but I get the following error:
***************************************************** Connection Failed.
When I enable the "Power Target Circuit From Tool", I get another error:
The target circuit may require more power than the debug tool can provide. An external power supply might be necessary.
Connection Failed.
So a provided an external power supply of 5V and my PIC 16F628A is draining 10mA, despite nothing is connected, only the PICKIT3 to the MCLR, ICSPDATA and ICSPCLK pins of PIC.
I'm using Ubuntu 16.04, MPlabX IPE V4.05., and
PS: Yes, I know how to read a datasheet.
PS: Circuit and PICKIT3 works properlyt if I connect to PICKIT3 Programmer running on Windows 7.
The first issue can sometimes be resolved by shutting down MPLABX, disconnecting the PicKit from your computer and reconnecting everything. Seems the firmware and/or driver sometimes gets in a weird state and needs a good boot to get going again. I sometimes have to reboot my computer just to program my main board (Major PITA).
The second issue is not necessarily caused by an over current despite the message. I always got this error when my PicKit was plugged into an unpowered USB hub. It seems the lower USB bus voltage confuses the PicKit into thinking that the device is the cause for the voltage drop instead of the host simply not supplying the normal voltage. Try plugging it into a powered USB hub or directly into your computer.
I know this is an old topic but maybe this answer can help somebody else.
I use as well official PICKIT's as clones.
It could indeed be caused by a hardware issue.
E.g. short or already activated load like a bunch of LED's.
Disconnect all loads if possible.
When using an official PICKIT 3, this issue is often solved by setting the voltage your PICKIT should supply to a lower level e.g. 5 => 4.625.
In MPLAB go to the properties of your project.
Select PICKIT on the left.
Select Power from the selection dropdown at the top.
When you have a SURE electronics clone, this might do the trick. (Maybe this is also valid for other clones) The AMS1117 they used is the adjustable one.
They used a 680 and a 470 feedback resistor which gives a voltage of 3.09V ((680/470 +1))*1.25 + 50u * 680). If you swap the 680 Ohm resistor with a 750, the output will be closer to the probably desired 3.3V.
Source where I got the idea: https://jrainimo.com/build/2018/12/picfix/
Location FB resistor
Close MPlab, reconnect Pickkit, restart MPlab worked for me.
If you've just created a new project or created a new file, MPlab sometimes confuses some things.
I'm currently using IAR to debug an STM32f0 micro, and I've noticed some interesting effects on my device's functionality while attempting to debug when the unit is running.
It seems to me that the debugger is slowing down or inhibiting the application in some way, meaning some of the more time critical sections of the code are having trouble executing correctly.
What is the debugger doing to the code in order to allow me to look at the registers/variables/memory/position in source code, and how does this affect execution time?
Note: optimisations are already turned off, as they tend to stuff up IAR's ability to step through code correctly and cause it to sometimes miss breakpoints.
The ARM Cortex-M0 CoreSight on-chip debug unit used of the STM32F0xx is non-intrusive for normal execution. Hardware breakpoints matched instruction-fetch addresses in real-time. If your debugger supports update of memory content and variables while running (rather then at a breakpoint), that may conceivably have an effect, but on STM32F2xx with I have not seen any issues even with very time critical code with with microsecond scale deadlines (F2 is however Cortex-M3 not M0).
Applying conditional breakpoints will slow execution considerably, if the breakpoint location is executed frequently since the processor must be stopped and the condition tested by the host.
A common problem encountered when debugging that may catch the unwary is that when the processor stops on a break-point, the on-chop peripherals and timers continue to run, of then resulting in several interrupts pending when the processor is restarted often with undesirable effects depending on your applications ability to handle such abnormal timing gracefully. The DBGMCU peripheral supports the ability to selectively stop specific timers and peripherals, and to support low-power modes without disconnecting the debugger. You may need to use these features to improve your debug experience.
What is the debugger doing to the code in order to allow me to look at
the registers/variables/memory/position in source code, and how does
this affect execution time?
It depends on your debugger. In general, debuggers slow the application (application performance) whether it is run in emulator or on the device itself based on the level of intrusiveness.
The breakpoints, single stepping can have huge impact on the timing of execution of application as they are intrusive. Also note that the intrusiveness due to these features in turn depends on the offering by the vendor.
Normally, debuggers shall read the CPU registers and memory so that it can be displayed to the user, however this process shall consume memory/time in turn causing side effect.
Some debug techniques used by debuggers involve incorporation of additional information into the application code which in turn can increase the size of application which can effect the execution time. Such intrusive techniques can cause side effects due to this additional code.
PSoC Creator FreeRTOS PSoC 5 CY8C5868AXI-LP035 GLCD 128x64
Hi there,
I am facing weird problem with my Application on PSoC 5 based hardware. This application is based on FreeRTOS, and application contains 128×64 kind of monochromatic LCD (Graphical LCD), having controller like ks0107.
The problem is that if we run this program with the PIN used for CY8CKIT-050, it runs smoothly and complete every task as desired with no problem at all. But if we only change the MCU PINs as used in our Hardware and program the Hardware MCU with same program, application runs to certain point and then hang. We tried debug mode and found out that after running for some time application goes to :
CY_ISR(IntDefaultHandler)
{
while(1)
{
/***********************************************************************
* We must not get here. If we do, a serious problem occurs, so go
* into an infinite loop.
***********************************************************************/
}
}
which is in Cm3Start.c. And at this point application stays in hanged state.
Here please note that this only happens if we used the same program in our Hardware. But if we use it in Kit (CY8CKIT-050), it runs completely fine without any fault.
We would like to also share that we have used FreeRTOS prior to this application, and we have successfully built applications with FreeRTOS.
Attaching(as I don't know how to attach I am providing Google drive links):
Application program for CY8CKIT-050 here.
Application program for our Hardware here (Only with different PIN usage)
Call Stack window screen shot where problem occurs:
PS: This discussion is going on in parallel at
Cypress Community Forum
FreeRTOS Forum
Other Forum
I am using TIOMAP/AM3517 based custom board which has ARM7 core + Linux 2.6.32 running on it.
Recently, I started observing an issue in which all the interfaces serial console, RNDIS/USB, Network stops responding (my type on keyboard connected to serial port/console port doesn't go through + no device is detected upon removal/insertion of USB sticks/BT dongle + Ethernet/network activities are stopped (can't login over ssh or access webPage that the system has.
I checked the power to the CPU and other power rails using DMM and it looks fine.
There is no keyboard attached so MagicSysRq cannot be used while the issue happens.
I have watchdog on the system which rebooted the system, however to reproduce the issue and to get more information of the system's state, now i have disabled the watchdog.
Finally, my system/linux is configured to reboot upon detecting softlockup which is not happening either. Also, I have enabled verbose debug options under kernel hacking but nothing seems to give any more information.
How do I debug the issue to identify the rot cause of it?