i have an PIC32MX460L512 microcontroler( Cerebot MX4 board from Digilent) and after doing some projects, i can`t program it any more.
This happend after i tested the board multipliers and dividers to see how the board works using #pragma pll ....
i can not write a new hex or change the configuration bits, and i get the following errors
PIC32 Starter Kit hardware initialization failure. Error= -1004, Detail=0x80004005, (LID:29)
or a second error
Device reset failed/ make sure Configuration Bits are correct.
I think the board still works because windows can see it in the Devices and Printers.
what ca i do? can i reset the memory from some bits? i`m still a noob with microcontrollers.
Thanks in advance
the problem was the configuration bits that i wrote earlier. i googled a little more and found that there is a file -- sk_erase.exe -- that erases the configuration bits
Related
The program builds fine, but when I tried to flash code from snap debugger to PIC16F15313 in MPLAB its giving this error. Even though low voltage programming is enabled in code.
"MPLAB has detected that the low voltage configuration bit on the device is off. Because Snap can use only low voltage programming, this configuration bit must be turned on in order to use Snap. You will need to use a different, blank device, or use another debug tool to erase this device, before continuing with Snap.
Connection Failed."
I had same issue. My problem was in the wiring of debugger (one wire was not connected). I think that your problem may be similar. LVP should be set in new device by manufacturer.
Two issues:
Switch on low voltage programming:
#pragma LVP = ON
check the wiring:
Note: The MPLAB Snap In-Circuit Debugger is powered through its Micro-B USB connector. The target board must be powered from its own power supply. The debugger sense the target voltage.
I have just finished a project using an Arduino Micro dev board and want to move to a standalone ATmega32.
I need to run this at 3.3V and I dont want to go down the overclocking road so I have an 8MHz crystal to put on it.
I still want to be able to upload sketches via USB and the Arduino compiler so I gather I need to burn a different bootloader.
For this purpose I have purchased a USBASP programmer.
I am slightly unsure of what to do next - everything I can find on the topic either relates to the ATmega328 or to burning bootloaders using another Arduino.
I have worked out that I need to modify boards.txt to point to the correct bootloader....but which is the correct bootloader for ATmega32 at 8Mhz?
Also do I need to change any fuses?
Thanks
I think you're a bit out of luck.
The ATmega doesn't have hardware USB, so I assume the bootloader is using V-USB to implement USB. That stack, being a software implementation of USB's high-speed signalling, requires at least a 12 MHz clock (higher is better).
I don't think you can run V-USB using only the internal 8 MHz oscillator.
According to the OP comments the micro is indeed an Atmega32u4, not an Atmega32 (#OP: please fix the question to match this).
Since it has onboard USB, you can use a pre-existing bootloader like the sparkfun one:
https://www.sparkfun.com/products/12587
Here you have the link to one of their products, the Arduino pro micro 3.3V (which runs at 8MHz). You can add the sparkfun arduino boards repository to your IDE and then just use the board specification for their pro micro 3.3V do upload the correct bootloader and to program it through the USB just like the usual Arduino Micro.
I am new in this. Bought Atmega8a mcu to have some fun with it. But I am unable to program it using arduino uno rev-3. Haven't used any external parts to program it. Just connected the chip as below:
Arduino pin 10 to chip pin rst,
Pin 11 to MOSI,
Pin 12 to MISO,
Pin 13 to SCK,
Connected vcc and gnd to chip pin 7 & 8,
Also used an 10 uf cap, arduino rst to gnd.
Trying to upload the bootloader using arduino ide 1.6.9. It says:
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override this check
Am I missing something?
Most minimal AVR setups include a 10k pull-up resistor on the reset pin. Are you sure you don't need one?
Arduino target cpu (or variant) must be ATMega8A.
"Invalid signature" is not so verbose - it says nothing. Enable verbose log for avrdude in Arduino setting.
If signature is slightly different from actual one, it's selected variant problem.
If it's something like 0xFF or 0x00 it's usualy wiring, reset or missing xtal problem.
Bootloader needs correct xtal/resonator (AVR runs from internal 8MHz clock and it's divided by factor 8 by default, but after flashing bootloader it'll be set to crystal oscilator - depends on target/variant)
Remove cap from RST, it might be slowing down reset and cause invalid reading
Currently there's no arduino board with atmega8a as the main microcontroller.
You forgot about pins 20 and 22 -- you must connect them to VCC and GND even if you're not going to use ADC.
EDIT:
Ad. 1. It would be possible to add support for atmega8a to arduino ide, by modifying hardware/arduino/avr/boards.txt file and compiling a bootloader for atmega8a.
I'm having trouble with an industrial Linux computer I'm working with to achieve communication over an RS485 bus with multiple connected devices. What I've encountered is that the IO pins used by the RS485 USART driver are set to different levels at startup instead of going to the RS485 idle/tri-state. As a result, the other devices on the bus are blocked for more than 30 seconds while the device boots up, triggering all sorts of external problems. The course of events can be viewed in the attached image, where I've measured the output voltages with an oscilloscope during startup.
My guess is that the actual driver is not started until the voltage levels reach their tri-state levels (e.g. ~2.2V for this device). After that everything works as expected.
I've tried to find any config-files to set the default IO level of the pins at boot (thinking this may be set by the bootloader) to no avail.
Also, I've tried to apply a startup-script to run "early enough" to set DATA- high, but the device in question does not provide any interface to control these pins as regular GPIOs as far as I can tell.
Any help, tips or insights would be much appreciated!
EDIT: I am not an experienced Linux developer, so please highlight if I've left out any important details.
Some specs:
ARM920T rev 0 (v41) CPU
Proprietary distribution of Linux 2.6
Uses Busybox
Atmel USART drivers
Extract from boot log:
Linux version 2.6.28.10 (root#) (gcc version 4.1.2) #94 PREEMPT Tue Oct 29 10:22:19 CET 2013
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0003177
/...
.../
RS485 mode for port /dev/ttyS3 enabled
/...
... (I'm guessing the ~30 secs elapse here)
.../
atmel_usart.3: ttyS3 at MMIO 0xfffcc000 (irq = 9) is a ATMEL_SERIAL
atmel_serial.3: Putting the RS485 RTS pin down
/...
...
.../
Full boot log: https://drive.google.com/file/d/0B2XYl1mNCa8jNUZ5V0Nic1hkU0U/view
Similar issue:
Possibly a similar issue is discussed here: UART initialisation: Prevent UART to pull RTS high
But I'm not sure how to proceed with the suggested solution.
This is little more than wild speculation, but it might be worth adding a start-up script that echoes a NULL character to the device (e.g. /dev/ttyS1 or whatever) as early as possible during start-up. This might be enough to kick the driver into initialising the hardware.
You could also try to locate the driver in the Linux source to look at how it starts up.
Probably you have access to the source code, so you can investigate who and when mess with the that GPIO. Just grep the kernel source for the atmel gpio controller port addresses to figure out what happen. If you are lucky may be there will be kernel command line option that you can pass from the bootloader to set the line to what you need in advance.
this answer may work if you can find required things mentioned below
of your board!
Once I also had a same issue on PWM. There I found that my bootloader was responsible for the same, I changed in bootloader configuration and it started working fine.
Check your BSP provided by board vendor or third party (If you have the source), If your bootloader is U-boot you can find it inside U-boot-(source)/include/configs/(your-board).h there you can find configuration for RS484. As per your datasheet for the board you can check for other things which are muxed on the same pin and disable those if not required for boot time and enable RS485.
enabling/disabling can be done by changing the values 0, 1 or 2 as per your configuration and also you can simply disable anything just by commenting // out the line.
I am working with Sasebo GII board that has two FPGAs on it:
Xilinx Spartan and Xilinx Virtex5 (and the board has several separate JTAG interfaces for configuration of fpgas).
I am useing ISE 14.4 under Linux and I have some troubles to configure the Virtex 5 FPGA.
(no problems with Spartan).
I am using "Impact" to send the configuration files to FPGAs.
At the beginning Impact scans the board and finds Spartan FPGA without problems
and I can configure it, but when I plug the cable to the other interface and press scan on Impact it says:
"There are many unknown devices being detected. Press Yes to continue or press No to stop."
If I press the NO option, well, obviously nothing happens :-)
And if I click on YES it fails, I can manually add Virtex5 FPGA, but than it fails to upload the config file to it (and even fails when I try to detect the device ID).
I already tried all JTAG interfaces on the board, nothing.
Same operations work on the same board with SPARTAN FPGA, so I'm stuck. Any ideas ?
Well, I am not familiar with that particular board, but there are many things you can look into when it comes to your JTAG problem.
Check the voltage of your VCC, make sure it has a good value for the board
Make sure your ground connection is well connected and you don't have much impedance
between the connector's GND and the boards GND
Try other JTAG connectors and see if you see any difference in the detection of the
devices.
Try to run the IMPACT in debug mode. Capture the data and see if the patterns look OK
Also something that may not be JTAG related, is to make sure your V5 device has all the powers it needs, if there are any power problems, it may cause the JTAG interface to behave like you explained here.
Also, look on the board and see if there are any switches or jumpers to chose different way of configuring the V5 device. This can be a big issues with multi-FPGA board, maybe the V5 is configured to be programmed from a controller or other devices on the board and the JTAG chain is not set up for programming.
These are just different thoughts, they may help you toward the right direction.
Found this on their site:
User guide for the board
To reprogram the flash ROM (ST45DB16D, U11) for the control FPGA (Spartan-3A), attach the configuration
cable to CN7. For configuration, use the provided mcs file sasebo_gii_ctrl.mcs.
Reprogram the flash ROM (ST45DB16D, U4) for the cryptographic FPGA (Virtex-5 LX30) with the provided
mcs file sasebo_aes_comp_lx30.mcs as well. Connect the configuration cable to CN4.
To configure the FPGA immediately after reprog
ramming of the flash ROM, cycle the power.
Blockquote
This means you can't program the FPGA directly, you need to convert your bit file into MCS file and then load it into the FLASH memory on the board.