I am using LM Flash programmer to burn the .bin file into TM4C123GH6PZ micro controller. I am using CCS 6.0.1, and when I will download this code to uC then it will run successfully but when I use LM Flash programmer then It will generate error randomly e.g. if I download a bin file 10 times it will successful but at 11th it will generate an error like "ERROR**: Programming error 0x1." then even if I will not change hardware setting at the 12th attempt it will be successful so I am confuse where I am wrong?
I am using Tiva C Series LaunchPad device which is having ICDI interface, using this I can program my controller successfully but it generates error randomly as i mentioned in my previous post. e.g 10 times it won't give an error but at 11th attempt it generates an error ( i.e. ERROR**: Programming error 0x1) but without changing any connection if i click program button then it will be successful, but again at suppose 15th attempt it will generate an error, so my question is if I am doing something wrong e.g in connection or selecting speed or anything then why it will successfully program 10 times ? and after an error even if i am not changing anything it will successful again for few attempts. And I am not able to understand the root cause of this unpredictable behavior.
I don't have any free wire running and proper GND connection as well. I found one link where they said that these are occur because of OS problem e.g insufficient RAM etc. I am providing that link as follows
But they charge to solve the problem, Is there analysis is correct? Is this happening due due slow RAM. I checked it on two PCs one is fast windows 8.1 GB RAM 64 bit and another machine is windows xp Professional V2002 SP3 Celeron m CPU 440 freq - 1.86Ghz RAM 504MB. My requirement is that it should work on both so I can't ignore problem with slow one. So please suggest a proper solution.
You misunderstood me, of course I am using wired connection but i wanted to say that I am taking care to keep away any extra unnecessary wires as it may interfere in my operation. I am sending you my setup image so you will understand it how I am connecting my ICDI to Laptop. I am providing Power to micro controller via Power supply, USB cable from ICDI to Laptop and connect ICDI to micro controller board.
Is this problem really related to Windows OS and due to multiple operations running, less RAM etc...because I am facing more problem when I am using less configuration machine and when I close all background operations then chances of errors will become less. Kindly go through the following image of Setup for programming.
I tried by reducing JTAG Speed from default high value to even 1000 but it didn't solve my problem. when I do erase and Blank check option in Flash Utilities then while erasing flash and blank checking it never gives me an error, not even a single time but why it generates an error while programming ?
On the other threads of Ti i read the same problem discussion where I read that this problem is related to system clock so use UNLOCK option in Debug Port UNLOCK, but I am not able understand this process, means how to do UNLOCK?..And what UNLOCK will do actually?
I tried it by removing those line from code also I tied TCK and TMS pins to +3.3Volt through 10K Ohm Pull Up resistors, but still I am facing the same problem of Error 0x1. also I tried by reducing the speed upto 1000 but no effect.
PIN Number 5 is Ground PIN, and please try to reach to root cause of this issue as it is not possible for me to switch to another debugger. And I am curious to know why this is happening ? Kindly Reply
We note that you've (saved) the cost & effort of pulling-up "TDI." In light of your dedication to identifying causal nexus - can that (ever) be wise?
Petrei's (always reset) advice is "dead-on" - our firm uses (only) IAR & J-Link - never/ever encounter your issue! (J-Link insures reset)
Note that the "ICDI" capability is a "bonus" w/LPad - it was not intended as "bullet-proof, uber-pro" device. (surely you know that.)
No one has yet to mention the "solidness" of your "board to board" connections. Are all crimps correct - do the headers mate perfectly with wire receptacles or have all interconnect solder joints been exhaustively viewed & tested?
And - your code reviews a very mistaken (earlier) approach to JTAG. It is entirely possible that (other) programming "adventures" may have (somewhat) disturbed/impacted the ICDI MCU - rather than "pound" Amit (btw - he made no "demand" - he simply guided/suggested) use of a new/fresh LPad seems most reasonable...
Can you tell me the installation procedure of Uniflash? I tried to install but couldn't succeed. I tried to search the steps for Uniflash installation but didn't find. If you can then please explain in short or provide a link. Thanks in advance.
Thanks for Reply Petrei, No I don't need browser while flashing but this behavior I observed so I wanted to know whether there is any relation with it. Now I understood that the problem is mostly due to insufficient RAM of Computer. Thank you once again.
So i know this isn't something to do with the board but the debugger configuration in the ARM-DS Ver.2018 software as i implemented this code on Keil MicroVision and it worked properly.I imported the project from Keil and it is getting built properly however when i try executing a new debug hardware connection, it connects the target pro but while executing the flash multiple-load command it throws the following error:
Once this error comes in the command window ,in the progress tab the loading bar just gets stuck on initializing DTSL and does not exit until I pause the debugging.Please someone help me with this problem this occurs when i enable debug from symbol(main) but does not happen when i do it with debug from entry point.
But however when i select the second option after jumping through instructions in the startup file just before it enters main it get stuck on a particular instruction and the command line throws an error like:
This is a known issue with Arm Development Studio and a number of the Keil evaluation boards based on NXP SoCs. Essentially the device requires a checksum to be embedded into the vector table, which is done by the flash algorithms. However, the debugger fails to correctly validate the checksum when performing the 'Verify' step.
I am trying to use CodeWarrior (Version: 11.5.5) to burn my QSPI flash (MT25QU256ABA), and seems I am having some random timeout issue, the fl_erase works with small memory range fine, but it will fail if I tried to erase large chunk of flash memory, and the upper limit is random, sometimes I can erase up to 640KB, sometimes only up to 320KB, it depends on luck.
When I use fl_write to burn my image to flash, it never succeeds, always stuck for about 5 minutes and return with error (FP: wait for target callback not set or not working). I do verified that the first few hundreds of KB are written to flash successfully though, then written bytes stays after power cycling the target board.
I found the solution of this flash programmer freeze problem, it's caused by that the QSPI speed is too fast, incurs mis-sync at HW level, I fixed it by setting "Half Speed serial flash clock Enable" bit within QuadSPI_SMPR register (0x1550108h). You can do this within Target Initialization File:
In addition, when you click flash programing icon, CCS(CodeWarrior Connection Server) console will be popped up on the right bottom of the Windows task bar, please open it and type "log v", then click flash programming icon again, the low level CCS log will be printed out, would you please capture this CCS log to me to do more investigation?
Update, I found that the "ERROR(4): Cable disconnected (target power not detected)" was caused by our hardware watchdog, when flash programming progress stuck, the watchdog kickoff after two minutes, then the CW complaints that the target lost power.
After disabled the hardware watchdog, the "target power not detected" error is gone, but the flash programming process will stuck forever (if I erase/write more than 1M bytes), till I manually power off the target board.
I tried both USB ports (/dev/tty.usbserial & /dev/cu.usbserial) but the same error persist. The Arduino is connected to a Macbook Air via the USB cable, and the PWR LED indicator light on the Arduino is turned on and the L indicator LED blinks. There was no problem uploading to a Arduino Uno.
This error message basically shows up for any communication problem, so by itself, it is not all that instructive. The Arduino Nano is supposed to have auto-reset, but maybe your clone does not? In that case, you'd have to press the reset key on the board just before starting an upload.
Know this is old but I ran onto it during my search for Nano(V3)'s not uploading so thought might help someone else. Problem is the bootloader - Arduino IDE BUT I Found an easy solution (right under my nose).
I realized that my nano's had been uploading just fine then I had finally updated the Arduino AVR Boards from 1.6.20 to 1.6.21. I didn't think there was any problems because it still showed my Nano and ATmega328 etc in the board manager after the change.
But the new boards manager has a new ATmega328 processor choice for the Nano. I changed processor: In the Arduino IDE select TOOLS > PROCESSOR > pulldown menu from ATmega328P to "ATmega328P (Old Bootloader)".
I was having the same problem and got the same error message. Turns out these boards don't come with a bootloader preinstalled. If you have some jumper wires and another working arduino you can use this tutorial to install the bootloader and it should work great, mine did at least! :)
c80f0f1006