Monday, 27 October 2014

Cloned chips? From bad to weird

A few people have posted suggesting that a lot of AVR chips need a crystal on them, before they can be programmed. I've never heard of this, and never had experience of it with a PIC (though PIC programming is done at high-voltage, rather than the low-voltage/SPI method favoured by many atmega-variety chips).

We already have a couple of working chips, from Farnell, mounted onto breakout boards and one of our original prototype gaming boards, and they work fine; although possible to put a chip on the breakout boards, we're pretty sure they were programmed before introducing an external crystal (which we introduced to debug the M103 problem which was stopping the chip from working properly).

But our prototype game board has no crystal onboard, and never has. There's no way we could have programmed the chip on the board with a crystal connected. Yet it's programmed up with our latest firmware and is working. So perhaps it's not the crystal.

But in the same way we spent most of Sunday proving that the chip was faulty (it was a lot of effort, to confirm the suspicion "this will never work", but something that needed to be done!) we felt it necessary to prove that the problem didn't stem from the lack of a crystal on the board.

After connecting a 16Mhz crystal to pins 23+24 we tried once again to get AVRDudess to recognise the chip. As before, the result was the same - MCU not detected. So what device ID were we getting this time?



Strangely, the device ID seems to change on each detect request.
There doesn't seem to be a pattern to it either - just apparently random numbers each time we hit the detect button! The id 0x666c61 comes up most frequently, and 0x656570 is also pretty common. But there's also a whole heap of junk in there too.

Whatever this chip is, and whether this chip needs a crystal or not, it's certainly not behaving anything like an AVR atmega chip!


No comments:

Post a Comment