I would like to program my Xilinx Spartan-3AN using ISE but for the last step (using ISE iMPACT), the program is failing.
In fact I've put a ".bit" file into the first chip but I don't have any ".mcs" file to put into the second chip so I tried to bypass it.
Unfortunately, when I launch the program, it stays at 0% and after a few seconds a "Program Failed" appears on the screen.
I made a PrintScreen to help you to understand :
(clickable)
Ok, my PROB_B pin was puled down to ground !
Related
I need to include hardware WDTs on both ESP32 and rp Pico based systems running micropython. I am using the Thonny IDE and with an 8s timeout on the Pico I can interrupt (Cntrl-C) the system and quickly delete the main from the board. This then allows me to continue development of the code. This approach works with an 8s timeout but if I was working with much shorter delays I am not so sure that it would. My concern is getting stuck with a main.py I can't change? Is there a better way anyone can recommend to handle this.
Harry
PS: Relative beginner with Python. The more I know, the more I know I don't!
What works for me: add time.sleep() for 5 seconds in the beginning of your code where you can kill script from Thonny using CTRL+C before WDT has been initiated. This way you dont need to delete file manually from board, you just stop it's execution before WDT
I have developed firmware on STM32F413 with STM32CubeMX using FreeRTOS. I have several tasks and PPP connection over Serial (PPPoS). I am using KEIL IDE for debug and everything is OK in debug mode and after debug without resetting MCU. But when I powered off it and then power on again, operations were 8X slower (sending data over UDP on PPPoS can be slow!). There is no error in data transferring, only the unexpected slowdown.
I have tested it with STM32CubeProgrammer too by flashing .hex file and running it with STM32CubeProgrammer, and everything is OK! After I power down and on again, the problem recurs.
I notice that in debug, KEIL uses object files. But I cannot understand what is different between the power-on MCU situation (booting time) vs. debug time.
How I can fix this problem?
Can anyone help?
I rechecked reset scenario and find that with longer reset signal everything be OK!
I increased nRST pin capacitor value and problem have been resolved.
STM32F413 datasheet recommends 100nF value for capacitor but it is not good in my case.
The only thing that I don't understand yet is that why with other codes I haven't this problem? and why in this case it works slowly (instead not completely wrong)?
I was trying to use OMNeT++ earlier today but I was unable to get any simulation to run. I tried numerous model simulations but they began hanging at the same place during initialization. I deleted and re-installed OMNeT++, but the problem persists. So even after a fresh install of OMNeT++ v5.5.1 on a Windows 10 v1903 machine, I am unable to run any simulation. This is what I saw when I ran the Aloha sample simulation executable directly after following all the OMNeT++ installation steps:
The Qtenv simulation window starts up but it's completely blank, and I can't actually focus on it, which leads me to believe there's something up with Qt. The program hangs indefinitely at this point. OMNeT++ was configured using the default values found in configure.user.
Any suggestions?
EDIT:
This is the last console output I receive after running QT_LOGGING_RULES="*.debug=true" ./aloha.
This is the last console output I receive after running QT_DEBUG_PLUGINS=1 ./aloha.
Did you connect additional monitor to your computer? Sometimes Windows remember position of an application on non-existed screen. Try to change your screen properties or connect second screen and look for Qtenv window of Aloha simulation.
Besides the above, delete .qtenvrc from samples/aloha.
So I bought a cheap USBasp programmer off ebay and tried to program an attiny2313. Avrdude said the flash was uploaded and verified, but the led did not blink. I checked the output of the pins with my voltmeter, got nothing. I tried a few other versions of the blink program for attiny2313 and got the same results. Then I made the mistake of trying to reset the fuses and immediately bricked the chip.
I tried the process again, being more careful about the fuses and got the same results. Checked my wiring multiple times the leds themselves etc. no blink. Then I tried programming an atmega8 and I could not get any response whatsoever. The programmer didn't recognize the chip.
I tried resetting the clock on both chips. I kept getting a 'could not set sck' clock speed error, but at the same time avrdude said that it successfully reset the clock speed. I tried resetting the clock related fuses on the second attiny2313 and bricked another chip.
Is there any possible way my programmer could be able to reset the fuses, but not program the chip? Because I know the fuses were reset, I could no longer recognize or program the chips right after the commands went through. But my programs just aren't producing any outputs.
At this point I'm totally lost.
Tried a couple of other programs and got one uploaded and confirmed by avrdude, but the leds still don't flash. I've tried swapping them and the resistors and checked my wiring multiple times.
Do not be miss-led by the "could not set sck" message. This can typically be safely ignored. If AVRDUDE said the the flash was verified, then it is very likely that the specified hexfile was successfully loaded into flash memory on the chip.
You should not need to change any of the fuses from their factory defaults to get your LED blinker to work. While I do not think it is possible to "brick" an ATTINY2313, you can put the chip into a a state where you would need more than your USBasp to reprogram it back to factory default.
More likely something mundane is happening like the program you are loading is not actually blinking the LED pin (code is wrong, or programming the wrong file) as expected or the LED is not connected correctly.
I'm just getting started learning FreeScale DSCs (MC56F800x series). I've done some work with AVRs using both AVR Studio on Windows and Eclipse and avr-gcc on Linux. CodeWarrior is just not as intuitive.
Right now I'm stuck trying to debug a simple program. I start the debugger using the built-in simulator, but it never reaches the first line of main(). Instead it seems to get stuck in some initialization code (MC56F8006_init.asm), specifically this line:
;; Loop until OCCS_STAT[LCK0] = 1
wait_for_lock:
brclr #OCCS_STAT_LCK0,x:>OCCS_STAT,wait_for_lock
I've let it run for quite a while and it never gets past this. It's obviously waiting for something, but what? You would think the simulator would just work... argh. Maybe there's some options I can change to make it pass this step?
I'm going to keep digging and will post an answer here if I find it first.
Updates:
Here's what I've found:
OCCS
On Chip Clock Synthesis
brclr
Branch if Bits Clear
The instruction loops until OCCS_STAT LCK0 is set. This register means the on-chip oscillator's PLL has locked (waits for clock stabilization).
I'm still not sure why the simulator spins forever on this line, and how I can solve this without resorting to hacking up the init code (which is part of the code library and not within my project).
I am not familiar with the part or the simulator, but it seems likely that the simulator is instruction-set-only and does not simulate the PLL hardware.
In most embedded development systems, the run-time startup code is provided as source and you could modify it (or rather make a local copy in your project and assemble and link that to override the default start-up). Alternately you could simply place a breakpoint in this loop, and advance the program-counter register to get it out of the loop. In many debuggers it is possible to attach a script to a breakpoint to do this automatically.