I have now fixed the problem properly and I thought I would post it on
this mailing list for future reference.
The simple fix was to change the low fuse to 0xFF. It was previously set
at 0xFD which is what is stated in the fuse information on the xbow
site. However, I noticed in a different Mica2 document that a screen
shot of rd_fuses showed is was 0xFF. The difference here relates to the
clock setting. According to page 37 of the ATMEGA128 datasheet OxFF is
used for a XTAL with low rising power (start-up time from power save is
16K CK and additional delay from reset of 65ms). OxFD is used for a
ceramic resonator with fast rising power (start-up time from power save
is 1K CK and additional delay from reset is 4.1ms).
This problem probably won't ever bother anyone with a purchased Mica2,
but may catch out those people like me who are making a node from scratch.
Cheers,
Simon
Simon Willis wrote:
Some more news on this problem.....
It is still occurring, but I can now get around it consistently. I
also discovered that it will program the board with no problems if I
change the high fuse to 0xD9 (uisp makes is 0xD8). In my last email I
said that I was setting this fuse to 0x19, but it seems 0xD9 also
works. The only difference this has from the uisp 0xD8 is that the
BOOTRST vector is disabled. Does anyone have any idea what's going on
here? I also discovered that writing 0xD8 to the high fuse will allow
me to read the fuses reliably (it seems), but when I program it (with
Blink for example) the program does nothing.
So here is how I program my boards:
-Write 0xD9 (or 0x19) to the high fuse several times: uisp
-dprog=mib510 -dserial=/dev/ttyS0 -dpart=ATmega128 --write_fuse_h=0xD9
-Check the fuses: uisp -dprog=mib510 -dserial=/dev/ttyS0
-dpart=ATmega128 --rd_fuses
-If the fuse has changed then continue
-Upload the program: make mica2 reinstall mib510,/dev/ttyS0
Does anyone have any ideas why it might be doing this or how I can fix
it? Or even a few things I can do with the MIB510 to try and
troubleshoot it?
I have tried reinstalling cygwin and the tinyos environment, but this
did not fix it. I am using TinyOS1.1.15
Thanks again,
Simon
Simon Willis wrote:
I am having problems programming with uisp. I am using Blink for
testing.
I have a MIB510 and a board that we designed that is based on the mica2.
Once I have programmed the ATMEGA128 I cannot reprogram it. It goes
through all the correct actions, but the program doesn't seem to
change (tested by changing the blinking LED) With a bit of playing
around I discovered that I can get it to program after I change the
fuse high byte to 0x98 (from 0xd8 set by uisp). This turns on the
'enable JTAG' option (even though I don't have the JTAG plugged in)
then it works. Another problem is that when I issue a 'rd-fuses'
command it will quite often return all 0s (or give some other error
message), also the wr_fuses_h command usually takes about 5 attempts
until it does actually change the fuses (checked using rd_fuses).
Once it has changed the fuse to 0x98 then rd_fuses will work reliably
and I can upload my program. I have also tried other combinations for
fuses (like 0x19) and it seems that whenever the 'enable JTAG' option
is on it will work. Does anyone have any idea why this might be or
what might be wrong here? I have been able to replicate this problem
on 2 boards now (I have only built 2 so far).
Perhaps I should try changing the makefile so that uisp always
enables JTAG, but this seems like a bit of a workaround problem,
since normal mica2s seem to work OK.
Anothter note: It also seems that I can't program a fresh ATMEGA with
uisp until I have plugged in a JTAG and changed the fuses to 0xfd (e)
0x19 (h) 0xfe (l). Is this normal? I was thinking that perhaps this
is done by Crossbow before the motes leave the factory.
Thanks for your help.
Simon
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
