Archive for February, 2011

Reset clock fuse bits on AVR

I am just starting to learn about AVR programming and I really enjoy myself! 😀
Except maybe when I play with the fuse bytes and I screw things up…

Basically, I was using a ATtiny13A microcontroller and I configured the fuse bytes to use the internal low-frequency oscillator running at 128kHz. I thought it would be a good idea to check if my simple blinking LED program was still working with this internal oscillator.
The good news is the LED was still blinking. But the bad news is I wasn’t able to reprogram the chip anymore… 🙁 After some research, I figure it out: the ISP interface needs to run slower than the microcontroller in order to flash it! And obviously, my ISP interface was running faster than 128kHz…

These microcontrollers are very cheap so I could just throw it away. But I am not the kind of person to give up without a fight! 😉
So I talked to my friend Google and he suggested me to read the following article: Fixing a bad frequency fuse bit on an AVR.
I followed the instructions and here is the output:

C:\AVR>avrdude -p attiny13 -P usb -c usbtiny -tuF

avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATtiny13 is 1E 90 07
avrdude> sck 1000
>>> sck 1000
avrdude: Setting SCK period to 250 usec
avrdude> e
>>> e
avrdude: erasing chip
avrdude> sck 10
>>> sck 10
avrdude: Setting SCK period to 10 usec
avrdude> quit
>>> quit

avrdude done. Thank you.

However, there is a missing instruction in this article. Indeed, these instructions erased the chip but didn’t fix the fuses, so now it’s blank but the fuses are still wrong!
In order to reprogram the fuses, you need to use the ‘-B250’ in the command line:

avrdude -p attiny13 -P usb -c usbtiny -U lfuse:w:0x6A:m -U hfuse:w:0xFF:m -B250

, , , ,

18 Comments

JDBC and the “zero” date

A few weeks ago, I was in the process of writing a little script in Java to extract data from a MySQL database. Because this is what we can call a micro project, I decided to simply use JDBC to talk to the database.

But when I tried to run my script, I got the following exception:

java.sql.SQLException: Value '0000-00-00 00:00:00' can not be represented as java.sql.Date
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:910)
	at com.mysql.jdbc.ResultSet.getDateFromString(ResultSet.java:2032)
	at com.mysql.jdbc.ResultSet.getDate(ResultSet.java:1956)
	at com.mysql.jdbc.ResultSet.getDate(ResultSet.java:1924)
	at com.mysql.jdbc.ResultSet.getDate(ResultSet.java:1972)
	...

After looking at the database, it seems that this exception has been thrown because the fields of type datetime contain the value ‘0000-00-00 00:00:00’. Don’t ask me why I have this kind of value in the database! Obviously, we would prefer to have a NULL value instead of a “zero” date.

There are two solutions to fix this problem:

  1. Replace all the “zero” dates by NULL using the following SQL query:

    UPDATE table SET datefield = NULL WHERE datefield = '0000-00-00 00:00:00';
    
  2. Add the parameter zeroDateTimeBehavior=convertToNull to the connection url which will automatically convert the “zero” date to NULL. Please find below an example of connection url with this parameter:

    jdbc:mysql://localhost:3306/dbname?zeroDateTimeBehavior=convertToNull
    

Personally, I choose the second solution as I didn’t want to change the original data of the database.

, , , ,

No Comments