Is it possible to program multiple PIC microcontrollers using only 1 PICKit2 programmer? The microcontrollers is connected via daisy chain. With PGC, PGD and MCLR of the PIC to be programmed is connected to the GPIO of the programming PIC.
I may be wrong, but I do not think this will work well as MPLBX will want to read back the written data to verify the programming operation succeed.
Alternatively, have you considered using PICkit3's in their "independent of a computer" mode? The PICKit3's can be configured to burn a specific program into a target PIC independent of a computer. I am wondering if having an "army" of these might address your issues.
I don't believe so. Just for fun after finding this question I took two 12f508's that were known to be good.
To prove that they were good I used IPE to load a previously tested program onto two devices. The devices worked as expected. I then used IPEs "fill memory" tool to program both devices to all empty (every address has 0x00), less the oscillator calibration memory location (I've had trouble with this area in the pass, so I always disable reading and writing to that location).
I then connected both chips up to the programmer in parallel and tried to program them with the same program. This is where everything went horribly awry.
For some reason, the programmer got confused and wrote a value of 0xFF to all addresses, including the out of range addresses. I verified that this was what actually happened by disconnecting the chips from the circuit and reading them independently.
Luckily for me I ran into this problem repeatedly before, and so have built a programmer out of an arduino and some extra circuits, so that I can ignore the stupid "oscillator calibration data invalid" error and reprogram that location to the correct instruction. It takes a long time to read and write memory, but it saves otherwise bricked chips.
In shorter words: No, this does not work, and it may actually "brick" your chips.
Related
There’s been plenty of questions and answers here and elsewhere on the general bootup sequence and logical design. However I am having trouble understanding what actually happens at the very beginning on the fundamental level.
For example a common way of describing the first step is “Once the motherboard is powered up it initializes its own firmware - the chipset and other tidbits - and tries to get the CPU running.” from: https://manybutfinite.com/post/how-computers-boot-up/
The key question lies within that “it initializes”. The precise nature of the “it” and what “initializes” entails is not clear at all.
(I’m not quite sure either when the firmware can be considered to have ‘initiated’)
The first couple of nanoseconds I can understand for the “power switch” to open then another few nanoseconds to allow for power to cross the distance to wherever the “initializing” circuity is on the motherboard. And then presumably some sequence of electrical impulses starts, and then ??? and then machine code execution starts.
And that is about as far as I’ve figured out.
What then happens in the remaining time for the “initialization” to happen?
When the motherboard is powered on, not only CPU but all other chips and devices (memory, timer, controllers of interrupts, DMA, video, disks etc.) are put into well-defined state.
I guess this is the initialization of firmware which Gustavo Duarte talks about. Actually firmware is a program hardwired in ROM, it doesn't initialize. BIOS memory variables at lower addresses in RAM will be initialized later by CPU executing Power-On-Self-Test and other chores.
For more details see
Booting at Wikipedia,
How Does an Intel Processor Boot?,
Booting an Intel System Architecture.
I am using ESP32 module for BLE & WiFi functionality, I am writing data on EEPROM of ESP32 module after every 2 seconds.
How many read/write cycles are allowed as per standard features of ESP32 module? based on which I need to calculate EEPROM life time and number of readings (with frequency) I can store.
The ESP32 doesn’t have an actual EEPROM; instead it uses some of its flash storage to mimic an EEPROM. The specs will depend on the specific SPI flash chip, but they’re likely to be closer to 10,000 cycles than 100,000. Writing to it every couple of seconds will likely wear it out pretty quickly - it’s not a good design choice, especially if you keep rewriting the same location.
I'm very late here, but an SD card seems like the ideal option for you. If you want to save just a few bytes, you can use FeRAM (also called FRAM). It's a combination between RAM and ROM, it's vast, and the data stays on it after power off. It is pretty expensive, so you might want to go with the SD card or web server option. I just wanted to tell you that this existed, I also know this for like a few months.
At that write rate even automotive grade EEPROM like the 24LC001 which supports at least 1,000,000 writes will only last about 2 months!
I think microchip has EERAM which supports infinite writes and will not loose contents on power loss.
Check the microchips 47L series.
There is a question that can micro-controllers programmer damage micro-controllers in a way that they can't be programmed any more? (I have usb programmer)
This question came in my mind when i found out that my new-bought micro-controllers become unprogrammable after that i programmed them for some times, but except that they can't be programmed any more they work correctly in the way they have been programmed.
Thanks for reading.
If your AVR has power issues during programming, it is possible for its fuse bits to become messed up. You should make sure your batteries are fully charged (if applicable) and be careful not to disconnect power during programming.
If the AVR fuse bits that specify its clock source get corrupted and the AVR expects you to connect an external clock or crystal, but you do not have such a clock or crystal in your circuit, then the AVR will not have a clock signal and you be unable to program it.
Luckily, there is actually a way to revive such AVRs: you can get another microcontroller to generate a PWM signal and apply it to the XTAL2 or XTAL1 pin of your AVR as a low-speed clock signal (e.g. 100 kHz). Then use your programmer (configured to use a low enough ISP frequency like 2 kHz) to connect to the AVR and fix its fuse bits so it uses the correct clock source.
The Pololu USB AVR Programmer v2.1 has a feature to generate such clock signals. A procedure for reviving AVRs is documented in the "Using the clock output to revive AVRs" of that programmer's user's guide. There is at least one person who successfully revived an AVR using this principle. If you try it, please let me know whether it works for you!
In general, there are lots of other ways for microcontrollers to be damaged or destroyed depending on what you are doing, so you might consider posting the details of your setup to a more AVR-focused forum that allows free-form discussion instead of just a question/answer format.
Can anyone tell me how should I configure Xilinx ISE to get fastest FPGA programming speed ?
I have Spartan 3 Starter Board (FPGA chis is xc3s200). I'm not sure what's the name of programming cable, but I plug it in my computer to LPT1 (parallel port) and other side to JTAG header in the Spartan 3 board. Currently it takes over 1 minute to program it, and my project isn't that big (it's only beginner stuff).
Also, I've notices that now I need to turn on "Create ReadBack Data Files" and "Create Mask File" options. If they aren't checked, I can't program the FPGA.
Can anyone tell what are best Xilinx ISE options for FPGA programming ?
Thanks :)
P.S. I should tell you that I am running Xilinx ISE inside Windows XP virtual machine. Is maybe that what is causing the speed problem ? If it is, can you at least tell me how to get rid of that Mask file, because before I didn't create it and everything worked ...
The full-device bitstream (the "file" you load onto the FPGA) for every given device is always the same size; it does not depend on the functionality. An "empty" design's bitstream will be the same size as one that uses most of the FPGA's resources.
Configuration time depends on the configuration mode (serial, parallel 8/16/32 bits) and the configuration hardware (FPGA, PROM, Flash, programming cable capabilities, settings, and operating frequencies).
It sounds like you are using the very old parallel cable (PC-III?); try getting hold of the more recent USB ones and you should get faster programming times for JTAG (which is serial, btw).
1 minute is a looong time for a device that small.
Is that including a certain amount of compile time, or does impact take a long time to load on your system?
Anyway, speed improvements can come from:
Bitstream compression - you can turn this option on to produce a smaller bitstream, which loads faster
Faster configuration clock (change this in the configuration software, eg Impact) - no idea how fast the parallel cable will go, but I can do 12MHz with my USB cable on most boards I've tried and 6MHz on some of them which weren't quite so well-designed.
Try to see if bit-banging is possible. Haven't tried this myself but you might want to read this thread.
http://forums.xilinx.com/t5/Silicon-Devices-Others/FX2-Micrcontroller-JTAG-FPGA-configuration/td-p/41602
RRS
We have a small embedded system without any video or serial ports (i.e. we can't output text via printf).
We would like to track the progress of our code through the initialization sequence.
Is there some simple things we can do to help with this.
It is not running any OS, and the hardware platform is somewhat customizable.
The simplest most scalable solution are state LEDs. Toggle LEDs based on actions, either in binary form or when certain actions occur if you can narrow your focus.
The most powerful will be a hardware JTAG device. You don't even need to set breakpoints - simply being able to stop the application and inspect the state of memory may be enough. Note that some hardware platforms do not support "fancy" options such as memory watches or hardware breakpoints. The former is usually worked around with constantly stopping the processor and reading memory (turns your 10MHz system into a 1kHz system), while the latter is sometimes performed using code replacement (replace the targeted instruction with a different jump), which sometimes masks other problems. Be aware of these issues and which embedded processors they apply to.
There are a few strategies you can employ to help with debugging:
If you have Output Pins available, you can hook them up to LEDs (or an oscilloscope) and toggle the output pins high/low to indicate that certain points have been reached in the code.
For example, 1 blink might be program loaded, 2 blink is foozbar initialized, 3 blink is accepting inputs...
If you have multiple output lines available, you can use a 7 segment LED to convey more information (numbers/letters instead of blinks).
If you have the capabilities to read memory and have some RAM available, you can use the sprint function to do printf-like debugging, but instead of going to a screen/serial port, it is written in memory.
It depends on the type of debugging that you're trying to do - in particular if you're after a temporary method of tracing or if you are trying to provide a tool that can be used as an indication of status during the life of the project (or product).
For one off, in depth source tracing and debugging an in-circuit debugger (eg. jtag) can be very helpful. However, they are most helpful where your debugging requires setting breakpoints and investigating memory and registers - which makes it of little benefit where you are dealing time critical problems.
Where you need to determine program state without having a significant impact on the execution of your system the use of LEDs connected to spare I/O pins will be helpful. These can also be used as the input to a digital storage oscilloscope (DSO) or logic analyzer.
This technique can be made more powerful by selecting unique patterns of pulses that will be identifiable on the DSO.
For a more versatile debugging tool, though, a serial port is a good solution. To save cost and PCB real-estate you may find it useful to use an plug-in module that contains the RS232 converters.
If you are trying to provide a longer term indication of status as part of the normal operation of your product, LEDs are again a cheap an simple method. However in this situation it is best to choose patterns of pulses that are slow enough to be easily identified by visual inspection. This will all you over time you will learn a particular pattern that represents "normal" behavior.
You can easily emulate serial communications (UARTs) using bit-banging from the IO pins of the system. Hook it to one of the card's pins and attach to a RS232 converter there (TTL to RS232 converters are easy to either buy or build), which goes to your PC's serial port.
A JTAG debugger is also an option, though cumbersome to set up.
If you don't have JTAG, the LEDs suggested by the others are a great idea - although you do tend to end up in a test/rebuild cycle to try to track down the issue.
If you've got more time, and spare hardware pins, and memory to spare, you could always bit-bash a low speed serial interface. I've found that pretty useful in the past.
Others have suggested some pretty good ideas using output pins, so I won't suggest that, although it can be a very good solution, and is very cost effective. If your budget and target processor support it, a hardware trace system, (either an old fashioned emulator, or a fancy BDM with bus snooping trace support) can be great for this type of thing. It's very expensive though.
The idea of using a bit-banged software UART is nice, but there's some effort required in writing one and also you need some free timers and interrupts. If your hardware has any other unused serial interface (SPI, I2C, ..), using them would be easier. With a small microcontroller you could convert the interface to RS-232.
If you have to go for the bit-banging, making a synchronous serial might be a simpler alternative as it wouldn't be critical to timing.