• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 1903 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DS89C450 code burning problem.

Bhai jagtap jagtap

Hello Everybody,

I have a EPROM programmer at my college. I wanted to burn code in my DS89C450 uC.
the programmer had only DS89C420. i checked the datasheet it says that the 2 IC's are pin compatible and applications using DS89C420 can be replaced with DS89C450. When i tried burning my code the programmer says " MANUFACTURER'S CODE NOT MATCHED". what does it mean and what should i do?

Parents
  • 0 in reply to Andy Neil

    Another problem with parallell programming is that wrong programming algorithm can result in chips that "looks" like they are programmed, but the chip may start getting bit errors after months, weeks or maybe even hours.

    That is a big advantage with chips with IAP - the chip itself have all the hardware or at least optimized firmware to get the best result. But even then, chip manufacturers now and then have to send out bootloader updates because the factory code didn't perform as expected over the full voltage and/or temperature range.

Reply
  • 0 in reply to Andy Neil

    Another problem with parallell programming is that wrong programming algorithm can result in chips that "looks" like they are programmed, but the chip may start getting bit errors after months, weeks or maybe even hours.

    That is a big advantage with chips with IAP - the chip itself have all the hardware or at least optimized firmware to get the best result. But even then, chip manufacturers now and then have to send out bootloader updates because the factory code didn't perform as expected over the full voltage and/or temperature range.

Children
  • 0 in reply to ImPer Westermark

    Another problem with parallell programming is that can result in chips that "looks" like they are programmed, but the chip may start getting bit errors after months, weeks or maybe even hours.

    also, the "wrong programming algorithm" can even blow the chip (e.g. applying 12V "programming voltage" to a pin)

    but the chip may start getting bit errors after months, weeks or maybe even hours.
    which is precisely why most manufacturers have stopped supporting kitchen table programmer makers.

    one related note: when shopping for a parallel programmer be sure to ask "how long will you support this model with updated software to cover newly introduced chips". I got so badly burnt by Xeltek, 9 months after the purchase I got "to program that chip you need to buy our new model". Of course, for the sake of full disclusure, I must say they 'generously' offered me $50 for the old one.

    Erik

  • 0 in reply to ²erik malund

    Yes - that was my original point!

    The OP didn't seem to understand this...

  • 0 in reply to Andy Neil

    Not too much problems with chips that lets out the magic smoke from incorrect programming parameters.

    The big problem is chips that just got a little bit damaged, or chips that was "almost" programmed. I.e. chips that gets sent out to a customer and then fails.

    When the chip blows up directly while being programmed, it's just a fixed learning cost, not to program with wrong algorithms.

  • 0 in reply to ImPer Westermark

    Not too much problems with chips that lets out the magic smoke from incorrect programming parameters.

    The big problem is chips that just got a little bit damaged, or chips that was "almost" programmed. I.e. chips that gets sent out to a customer and then fails.

    When the chip blows up directly while being programmed, it's just a fixed learning cost, not to program with wrong algorithms.
    the pro will agree with you, the amateur not

    Erik