Bricked my Opensprinkler trying to roll my own code...help pls.

[got1]

Looks like I bricked my opensprinkler :(

I was planning to do a recompile of the code to start of sending http GET's, but I could not load my recompiled code and now i get the following error when I try and load Ray's compiled code! The LCD on the unit is permanently on (ie. all blocks on the LCD are solid on). The USBtiny is recognised by the os, both windows and linux.

C:\Downloads>avrdude -c usbtiny -p m328p -F -U flash:w:firmware1.8.1.hex

avrdude: initialization failed, rc=-1

avrdude: AVR device initialized and ready to accept instructions

avrdude: Device signature = 0x000000

avrdude: Yikes!  Invalid device signature.

avrdude: Expected signature for ATMEGA328P is 1E 95 0F

avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed

         To disable this feature, specify the -D option.

avrdude done.  Thank you.

The above error is the same in Windows (which I previously used to flash to the new ray's precompiled firmware from 1.8 to 1.8.1).

So here is what I did and hopefully someone can help. It follows the instructions on Ray's website.

I installed a fresh copy of Ubuntu 12.04

installed arduino IDE 23 and precursor modules avr-gcc etc

I also installed avrdude...which perhaps I should not have?

modified the config. files as per instructions.

loaded ray's sketch and confirmed it compiled then clicked upload.

I noted the sketch size was about 100 bytes less than the maximum

It seemed to give some java messages in the IDE status window and freeze

I think I then restarted the IDE and can not recall exactly what I clicked on next...but I kept getting error messages rc=-1 and somewhere there I noticed the opensprinkler was showing the LCD with all segments on.

I then tried to restore the original firmware both under Linux and Windows...but I het the above message.

I fear I have I somehow overwritten the bootloader?

If so, how to I reinstall it?

any suggestions?

.

[Ray]

Which hardware version do you have? I feel like I have seen this in a previous post but I can't find it right now. The only thing I could think of is if you've accidentally changed the fuse bits which causes the clock source to be wrong. Anyways, I need to know your hardware version to begin with.

[got1]

Sorry, should have said.

It's the new version, v1.4

I only got it from you a week or so ago as a complete/assembled unit ;(. Was working perfectly both with 1.8 and also after flashing to 1.8.1.  

But I seem to have stuffed it.

[got1]

To re-install the boot loader with the IDE (assuming that is part of the issue)...should I do the following?

• Download https://github.com/rayshobby/opensprinkler/blob/master/OpenSprinkler%20Controller/software/optiboot_8MHz_working.zip

• Replace the file in “/hardware/arduino/bootloaders/optiboot/optiboot_atmega328.hex” with the downloaded file.
  

• Select “Tools > Board > Arduino UNO”.

• Select “Tools > Burn Bootloader > w/ USBTiny”
  

• Wait for bootloader to be uploaded.

Is that correct?

If so I will try that when I get home.

[Ray]

No, that's incorrect. Look, if you follow the instructions:

http://rayshobby.net/?page_id=732#compile

I have not mentioned 'upload bootloader' anywhere. Bootloader was only used on OpenSprinkler v1.0/1.1 which do not have a built-in USBtiny programmer and had to rely on an external serial programmer.

Now I understand the problem: when you burned a bootloader, it must have changed the fuse bits to use external crystal. But OpenSprinkler v1.4s is supposed to run on its internal clock, so there is no external crystal installed on the board. As a result, the microcontroller cannot start because there is no crystal. This is a common issue with avr microcontrollers, that is, if you happen to change the fuse bits the wrong way, you will end up bricking the microcontroller.

But you don't need to panic, the clock issue is easy to solve. All you need is to connect a crystal of 8MHz (or 16Mhz, or any frequency that's at least 4MHz) to the crystal pin pads, and run the following command to change the fuse bits back:

avrdude -c usbtiny -p m328p -B 250 -F -U lfuse:w:0xe2:m -U hfuse:w:0xd1:m -U efuse:w:0x06:m

Once the fuse bits are set, you can remove the crystal and the mcu should run on its internal clock.

On the 1.4s, the crystal pin pads are located on the left of atmega328 and marked X1. There are three pins. You can either get a ceramic oscillator, which has 3 pins that match it, or a 2-pin crystal, in which case you connect the two pins to the first and third pad, leaving the middle pad unconnected. If you don't have any ceramic oscillator or crystal, shoot me an email and I am happy to send you one at a small cost.

[got1]

Thanks I did follow the instructions to compile and upload...but must have got mixed up along the way and gone off the rails.

It was 2am and the moral of this story is clearly do not play with microcontrollers at 2am!

I'll grab a crystal from the electronics store on the way home and have a hack..earlier in the night this time.

Thanks so much for the help and let's hope this gets me back to a working unit.

On Wednesday, 10 October 2012 12:31:00 UTC+11, Ray wrote:

No, that's incorrect. Look, if you follow the instructions:

http://rayshobby.net/?page_id=732#compile

I have not mentioned 'upload bootloader' anywhere. Bootloader was only used on OpenSprinkler v1.0/1.1 which do not have a built-in USBtiny programmer and had to rely on an external serial programmer.

Now I understand the problem: when you burned a bootloader, it must have changed the fuse bits to use external crystal. But OpenSprinkler v1.4s is supposed to run on its internal clock, so there is no external crystal installed on the board. As a result, the microcontroller cannot start because there is no crystal. This is a common issue with avr microcontrollers, that is, if you happen to change the fuse bits the wrong way, you will end up bricking the microcontroller.

But you don't need to panic, the clock issue is easy to solve. All you need is to connect a crystal of 8MHz (or 16Mhz, or any frequency that's at least 4MHz) to the crystal pin pads, and run the following command to change the fuse bits back:

avrdude -c usbtiny -p m328p -B 250 -F -U lfuse:w:0xe2:m -U hfuse:w:0xd1:m -U efuse:w:0x06:m

Once the fuse bits are set, you can remove the crystal and the mcu should run on its internal clock.

On the 1.4s, the crystal pin pads are located on the left of atmega328 and marked X1. There are three pins. You can either get a ceramic oscillator, which has 3 pins that match it, or a 2-pin crystal, in which case you connect the two pins to the first and third pad, leaving the middle pad unconnected. If you don't have any ceramic oscillator or crystal, shoot me an email and I am happy to send you one at a small cost.

On Tuesday, October 9, 2012 9:00:04 PM UTC-4, got1 wrote:

[got1]

Happy now.  All working again.

Thanks so much for the amazing support Ray. All I can say is WOW!

C:\Documents and Settings\user>avrdude -c usbtiny -p m328p -B 250 -F -U lfuse:w:xe2:m -U hfuse:w:0xd1:m -U efuse:w:0x06:m


avrdude: initialization failed, rc=-1

avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA328P is 1E 95 0F

avrdude done.  Thank you.

<install crystal>


C:\Documents and Settings\user>avrdude -c usbtiny -p m328p -B 250 -F -U lfuse:w:xe2:m -U hfuse:w:0xd1:m -U efuse:w:0x06:m


avrdude: AVR device initialized and ready to accept instructions


Reading | ################################################## | 100% 0.05s


avrdude: Device signature = 0x1e9514

avrdude: Expected signature for ATMEGA328P is 1E 95 0F

avrdude: reading input file "0xe2"
avrdude: writing lfuse (1 bytes):


Writing | ################################################## | 100% 0.03s


avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xe2:
avrdude: load data lfuse data from input file 0xe2:
avrdude: input file 0xe2 contains 1 bytes
avrdude: reading on-chip lfuse data:


Reading | ################################################## | 100% 0.02s


avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xd1"
avrdude: writing hfuse (1 bytes):


Writing | ################################################## | 100% 0.05s


avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd1:
avrdude: load data hfuse data from input file 0xd1:
avrdude: input file 0xd1 contains 1 bytes
avrdude: reading on-chip hfuse data:


Reading | ################################################## | 100% 0.02s


avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0x06"
avrdude: writing efuse (1 bytes):


Writing | ################################################## | 100% 0.03s


avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0x06:
avrdude: load data efuse data from input file 0x06:
avrdude: input file 0x06 contains 1 bytes
avrdude: reading on-chip efuse data:


Reading | ################################################## | 100% 0.02s


avrdude: verifying ...
avrdude: 1 bytes of efuse verified


avrdude: safemode: Fuses OK


avrdude done.  Thank you.


C:\Documents and Settings\user>avrdude -c usbtiny -p m328p -F -U flash:w:firmware
1.8.1.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s


avrdude: Device signature = 0x1e9514

avrdude: Expected signature for ATMEGA328P is 1E 95 0F
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed


         To disable this feature, specify the -D option.

avrdude: erasing chip
avrdude: reading input file "firmware1.8.1.hex"
avrdude: input file firmware1.8.1.hex auto detected as Intel Hex
avrdude: writing flash (32652 bytes):


Writing | ################################################## | 100% 7.36s






avrdude: 32652 bytes of flash written
avrdude: verifying flash memory against firmware1.8.1.hex:
avrdude: load data flash data from input file firmware1.8.1.hex:
avrdude: input file firmware1.8.1.hex auto detected as Intel Hex
avrdude: input file firmware1.8.1.hex contains 32652 bytes
avrdude: reading on-chip flash data:


Reading | ################################################## | 100% 5.25s






avrdude: verifying ...
avrdude: 32652 bytes of flash verified


avrdude: safemode: Fuses OK


avrdude done.  Thank you.

[Ray]

Cool. Good to know. Thanks for the update.

[garygid]

Does the uP on the 1.4u also run on the internal clock?
I thought that there is a 3-pin ceramic oscillator near the uP.
Thanks for your continued splendid work and support.

[Ray]

It does, but the fuse bits can be programmed to use internal clock.

[garygid]

On Friday, October 12, 2012 6:54:48 AM UTC-7, Ray wrote:
> It does, but the fuse bits can be programmed to use internal clock.
>
> On Thursday, October 11, 2012 2:06:29 PM UTC-4, garygid wrote:Does the uP on the 1.4u also run on the internal clock?

I am confused, do you mean that the uP can be programmed to use
the EXTERNAL ceramic oscillator?

If so, is there any reason to NOT use the external clock?

Is the external ceramic oscillator substantially more accurate than
the internal clock?

If the fuses are set once, will avrdude still work, or will avrdude need to
reset the fuses each time it is used to flash the uP?

What arguments do we give avrdude to set the fuses for EXTERNAL clock?

Thanks for your help.

[Ray]

On Friday, October 12, 2012 9:51:33 PM UTC-4, garygid wrote:

On Friday, October 12, 2012 6:54:48 AM UTC-7, Ray wrote:
> It does, but the fuse bits can be programmed to use internal clock.
>
> On Thursday, October 11, 2012 2:06:29 PM UTC-4, garygid wrote:Does the uP on the 1.4u also run on the internal clock?

I am confused, do you mean that the uP can be programmed to use
the EXTERNAL ceramic oscillator?

Yes, you can change fuse bits to set whether the microcontroller will run on external or internal clock. This is pretty standard on all microcontrollers. Some microcontrollers also allow you to change the clock source on the fly.

 

If so, is there any reason to NOT use the external clock?

If internal clock is sufficient, you don't need external clock. Saves component, less soldering. 

Is the external ceramic oscillator substantially more accurate than
the internal  clock?

In terms of accuracy, typically crystal > ceramic > internal clock 

If the fuses are set once, will avrdude still work, or will avrdude need to
reset the fuses each time it is used to flash the uP?

Fuse bits are non-volatile. On AVR chips, you can program fuse bits separately with the binary code. You can change fuse bits without changing the binary code, and vice versa

What arguments do we give avrdude to set the fuses for EXTERNAL clock?

Check the AVR fuse calculator. 

Thanks for your help.