Symptom: When I select "program flash" menu from the IDE, it starts working, but fails on a random point. Sometimes it erases flash successfully, sometimes fails earlier (see logs below).
History: It was working for weeks. When I uploaded my program, it was running, printing stuff to the UART port. Then, a nice day, flashing has stopped. I've tried, but it printed various errors. Next day it was working again (without any fix), but only for 2-3 days, then stopped working forever.
Diagnosis: In Vivado, I can see the device, it looks healthy. I checked .bat scripts, they set the environment and finally calls rdi_zynq_flash.exe, which is responsible for the whole flashing process (using server on localhost). From this point, I have no chance to know what is really happening under the hood. I was playing around with the XSCT tool, but I have no idea what should I check.
Configuration:
Board: Xilinx Zynq 7000, ZC702
IDE: Vivaldo 2020.1, on Windows 10
program type: standalone (not Linux), only ARM code, no FPGA used
programming mode: QSPI (switch 4 is on, others are off)
The errors are:
unrecognized JEDEC id bytes: 10, 01, 00
unrecognized JEDEC id bytes: 68, 03, 00
Failed to read boot mode register
ERROR: Flash Operation Failed
zynq_qspi_irq_poll: Timeout
See full logs for more details.
Solved automatically. I don't know why, I moved some cables, turned switches on and off. Maybe, it was a hardware issue.
If you have better answer, please, leave here.
Related
I have an Atmel SAM4S Xplained Pro, which I program and debug via a USB cable and Atmel's on-board EDBG chip (in other words, the way God intended). At the moment, if I "Stop Debugging" through Atmel Studio (v7.0), the code seemingly continues running (because I continue to get output in the terminal, which is application specific output).
Does anyone know how to stop this from happening, i.e., how to make "Stop" mean "Stop"? It's doing my head in!
Having contacted Atmel, the answer is that the debugger does not hold the MCU reset after debugging is stopped, so the code will continue to run. This is a known issue and is on their backlog to resolve.
So we have Crystal Reports running on a server in a multi user environment. Crystal is used to send documents directly to printers on the local network. Today we noticed the server running at full load and multiple instances of rundll32 hogging all the CPU cycles.
On further investigation it seems that the rundll32 instances are Crystal Print jobs which have hung or otherwise not finished.
I have not been able to reproduce the error yet but does anyone have any suggestions as to what could be causing the rundll32 process to hang like that, and how to avoid it?
Killing the processes manually is not ideal but it's the only way to get the users back going again.
Turns out this was a bug in the printer driver when the 'Printer Notifications' options was enabled. The printer was low on toner, and was issuing a message to the server, which was then using 100% of the cpu.
I disabled the option in the driver and haven't had that issue since.
We have a Delphi 7 application running on numerous client machines. Recently, some of the client machines started using Microsoft Security Essentials. It started identifying our executable as malware and promptly shut it down. The message displayed by MS Security essentials is:
"Security Essentials detected items on your PC that it doesn't recognize......"
Odd thing is it does not always occur at the same option in the application. You can do the very same operation on subsequent logins and sometimes it works and other times security essentials closes it down. This makes it extremely hard to narrow down to a specific cause in our application.
I tried running the application with elevated account privileges and was still able to get it to fail. I was unable to duplicate the issue when running a Delphi XE2 compile of the same application.
Any ideas about what to look for? We are really trying to avoid adding our application to the Security Essentials exclusion list. Our application has never been identified as a problem with varying security programs (norton, mcaffee, etc.).
I once had a similar issue with an executable built using Delphi(7), though it had nothing to do with Delphi-7. It just so happens that some part of the executable matches some virus signature or the AV heuristic scan suspects that something is wrong with the executable. One thing you can try is to change some of the compiler settings such as Debug options. Changing Debug Information or using debug DCUs might result in a slightly different byte sequences in the final executable.
I got the SainSmart Mega2560 LCD Keypad Shield Sarter Kit and want to upload the demo program for this LCD keypad. The IDE runs under Win7 x64 and the driver is correctly installed, I think.
I only get error messages
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude: stk500v2_command(): failed miserably to execute command 0x10
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
How can I check, if the connection really exists? Are there any know issues?
It seems, that many users have the same problem. My solution was now, that I removed the LCD Panel and the upload worked.
It is very strange problem, I encountered this problem when I attempted to connect IO expansion shield with Arduino 2560. I have tried many things but it didn't work. After many attempts I removed IO expansion shield from Arduino and then upload, It was worked. There is no clue why it can't upload when IO expansion shield is plugged. So this is a workaround solution but it is working. It is enough for me now.
--- FIXED ---
The problem has been fixed by checking all wiring on RS-485 network. GND and Termination wiring was missing after set these wiring properly the problem was fixed automatically. If you have this problem, I suggest that checking wiring once again.
We've got an application written in Delphi that uses Delphi On Rails and acts as a server and communicates with clients using HTTP, JSON and websockets. We ran into some issues lately and it's hard to debug them and find the problem's source.
Using Wireshark for traffic analysis, we could see the following behaviour: There's a request from a client (HTTP GET for a file). Usually, we process that request and send a HTTP status code, the file (if not cached) etc. However, we have a reproducable problem where there's only
the request from the client, a TCP SYN from the server, but after that, the server sends a RST packet and the TCP communication stops.
The strange thing is, we can reproduce the problem quite well (although the files where the RST packet disrupts the communication differ) and it mysteriously vanishes in one of the following cases:
In debug environment (Delphi IDE), disabling madExcept
In release environment, not patching the executable with madExceptPatch
Give focus to a different window than the main application window.
As we had some problems with Delphi On Rails and had to do minor modifications to it to avoid access violations and debug exceptions, I suspect DOR to be the culprit and some strange memory corruption or uncatched exception to be the bug, but it's still confusing, especially the fact that the problem vanishes if we change focus.
My main question is not how to solve this problem, but how to debug it and where to look for problems. The source of the TCP reset also puzzles me, as we don't run into the usual procedures that process requests in that case and it seems like either DOR or something else (the application, Winsock, OS) resets the connection by mistake.
For completeness, as it might be related, here are issues that I reported at the Delphi On Rails project and a forum thread where I asked the madExcept author about the problem: Issue #6, Issue #7, Issue #8, forum entry.
As a test, we checked out some older DOR sources from version control where no connection issues were known, and it works without showing any of the above problems.
So we decided to solve the problem the other way round: Rolling back the DOR specific source code (about 20 files) to the last stable version and "re-updating" it piece by piece until the error will occur again. If this happens, we can
Go back to the latest working version quickly
Hopefully be quite close to the original DOR sources so we can react on updates on the library.
Analyse the occuring error and report an detailed issue (and perhaps even a solution) to the DOR project.
EDIT: We could now update all but one file back to the old state without getting connection issues. The file that creates problems is dorSynchronizer.pas, more exact it's r179 of this file that caused the issues - threads were changed from Windows API to Delphi TThread there. We'll investigate this further and might add an issue to the DOR project in the next days.
EDIT2: It turned out that DOR uses the deprecated procedures TThread.Suspend and TThread.Resume that can cause undefined behaviour. I reported an issue to the DOR project.