Been working with Chronos for almost 2 months, managed to write quite a lot of code. Everything was going fine, until on day programming with mspdebug suddenly could not complete. When writing one of the last sections, mspdebug simply froze. The device became non-responsive, had to disconnect it and plug in again. Since then the hardware behavior became quite erratic. I could never complete software download using the same fet_block_size (500). After changing to 64, the download succeeded, slowly, but the software froze at the first expected interrupt. Even though on startup some text was displayed properly on the LCD (as expected), no UART/Timer/A2D interrupts occurred afterwards and the software basically stopped functioning. When breaking execution with Ctrl-C, a very strange disassembly block was displayed.
Here's what I got when downloading software:
Monitor command received: reset
Monitor command received: opt fet_block_size 500
Monitor command received: prog /Users/ej/dev/msp430-workspace/chronos/build/chronos/bin/chronos.elf
Erasing...
Programming...
Writing 4096 bytes to 8000 [section: .text]...
Writing 4096 bytes to 9000 [section: .text]...
Writing 2916 bytes to a000 [section: .text]...
Writing 2178 bytes to ab64 [section: .rodata]...
Writing 86 bytes to b3e6 [section: .data]...
. . .
Mspdebug froze at this point. No programming progress was observed for a few minutes. When I disconnected eZ430U from the USB port, the next error was displayed:
rf2500: can't receive data: Result too large
fet: failed to write to 0xb3e6
When I reduced the block size, re-programmed and ran the software (it just froze after a few code lines), got this disassembly block on manual break (Ctrl-C):
10002: ff 3f JMP 0x0002
10004: ff 3f JMP 0x0004
10006: ff 3f JMP 0x0006
10008: ff 3f JMP 0x0008
1000a: ff 3f JMP 0x000a
1000c: ff 3f JMP 0x000c
1000e: ff 3f JMP 0x000e
10010: ff 3f JMP 0x0010
At this point I decided the device was a goner. I would not have bothered publishing this on the forum, had this behavior not reappeared with my second Chronos kit. I used it for a while and everything worked properly (it worked on first use, without modifying the code). Then, after about two weeks the story repeated itself and the device died on me again. I assumed the problem was one of the following:
- ESD damage. Till now I have practiced zero ESD-safety. Is it possible the Chronos dev kit is highly sensitive to static discharge? Another thing that got me worried was that my laptop has no ground in its electrical adapter...
- Could my serial hack damage the CPU? The first two kits were modified to allow serial communication with the PC using the existing RX/TX pins of eZ430U. I decided to not repeat the hack with my third device, but the problem occurred again, this time after several minutes only. I now have 3 dead Chronos dev kits...
- Faulty USB port? I doubt this could be the case, since my Macbook Air has not displayed any problems with other USB devices: iPhone, Kingstone USB drive, WD Passport drive. Could this be a voltage problem?
Full setup:
- Macbook Air/ OS X 10.7.3
- mspdebug 0.19
Your thoughts would be highly appreciated.
Thanks!
-Eugene