Jump to content


  • Content Count

  • Joined

  • Last visited

About dmitrygr

  • Rank
    Noob Class

Contact Methods

  • Website URL

Profile Information

  • Location
  1. Thank you for all your help guys. I will use this new info to hopefully not brick the next watch. I am, however, still curious why it is so trivial to permanently kill a chip. Am I the only one who thinks this shouldn't be so easy. Especially by copy-and-pasting existing sample code from the vendor. has anyone else been able to replicate my results, or I am just unlucky with (now 3) cc430s ? as for stripped down code, just rename hwrInit() to main() in the code i gave
  2. The code was copied from chronos sample app provided with the watch incl the delay, and worked there
  3. The plot thickens.... I got the chip on the chronos replaced with a new one from TI. the device is now programmable. i rolled back the last change i made to my codebase and flashed with my fingers crossed. device did not die. re-applied the change. device died.... here is the code of my hwrInit() function, with the deadly part marked off....why does it kill chips? #include <cc430x613x.h> #include <signal.h> #include "hwr.h" static void __delay_cycles(unsigned short n) { __asm__ __volatile__ ( "1: \n" " dec %[n] \n" " jne 1b \n" :
  4. This is interesting and would explain a lot, but I do not see that in the linked doc. am i missing something? If i wanted to flash the proper BSL onto a device how would I do it using the FET? edit: found it in the chip doc slau259e, page 72
  5. sidenote: if you enter mspdebug and try to read the BSL, do you see any code? In each of these devices, as they were shipped to me from TI, when i did "md 0x1000 2048" i just saw a bunch of "0x3FFF" instead of code. is this intended? the msp doc says that reading memory that does not exist produces this value (whereas erased flash would be 0xFFFF).
  6. flash in my chip starts at 0x8000, but i wanted the code to start at 0xc800, so that i can use all preceding flash for storage (later) vectors "start" at 0xff80, but no vectors are defined in the cc430f6137 until 0xffd0, so i saw no use to writing previous values. neither of those should produce issues AFAIK (it wouldnt on avr,pic,arm) is msp different?
  7. Anyone brave enough to flash a chip w/ that firmware to see what happens? [radio registers are untouched so i do not think a cc430 is required, msp430 should do]
  8. I have the watch open and can access any lines, but how can the fuse at 0x17fC get blown when it was never touched by the programmer (as per programmer output) i did think of this and googled around. everyone seems to say that once the fuse is blown the chip is ROM and i am SOL. but two chips..identically... :-(
  9. I've been working on a Chronos altimeter app. But after some code changes suddenly my Chronos is not recognized by the FET. I got another, same story - programmed my code and it is bricked. I did not change the BSL address (so it should not be locked). The hex file of the code that kills the cc430f6137: http://dmitry.gr/ChronosAlt.hex Here is the session whewre I flash it and the part dies. It should not be a complier issue, since no opcode shoudl disable debugging, but in case it matters: mspgcc to compile&link, mspdebug to program the code. I verified that the FET is functional b
  • Create New...