Reflashing of Robotis MCUs
Reflashing of Robotis MCUs
by StuartL
Tue Jul 01, 2008 7:35 am
Last night we managed to (deliberately) brick and un-brick the CM-5.
The exercise was all about whether we could write a bootloader. To achieve this we needed to be sure that we could a) write a bootloader to the device and b) unbrick the device if the bootloader had bugs.
So after much googling, much soldering and much debugging of avrdude on OpenBSD (it doesn't appear to support it natively) we managed it.
The process uses a PC parallel port (also known as a TTL level latch) as a general purpose IO interface and (in our case, due to built in protection in the parallel port) directly connected it to the five-pin programming header on the CM-5 PCB.
Our pinout was:
Reset, parallel port pin 4
Sck, parallel port pin 5
MOSI, parallel port pin 2
MISO, parallel port pin 11
Ground, parallel port pin 18
The MOSI, Reset and Sck pins are just using the parallel port data bus pins, MISO uses one of the (many) input pins. Ground is obvious.
The avrdude conf was a bastardised 'bascom' definition and Matt had to hack together an OpenBSD driver (major hack, not worth publishing here) to make it work.
But work it did.
First steps were to read the signature bytes (1E 97 02) to prove the driver (eventually) worked, then we checked the fuse bytes and lock byte. Unfortunately the default lock byte is such that you can't read the flash or eeprom over the SPI programming interface. Fortunately the Robotis bootloader has no such restriction and happily dumped their contents into a waiting file.
So, at 10:30pm last night, we risked a chip-erase command. Please note, for all avrdude users, that the '-n' switch does NOT prevent a chip erase from working. This, to me, screams 'bug', but in our case it wasn't a disaster.
As expected the flash, eeprom and lock byte were reset. Strangely the fuse bytes were unchanged, despite being non-default, so I think the chip erase doesn't touch them.
The erase was confirmed as bricking the CM-5 (i.e. making it as useful for robotics as a house brick) and we set about reprogramming it.
First write of the flash dump I'd previously taken worked and the boot loader came up beautifully first time. Back to robotics!
NOTE: We used a VIA EPIA M-10000 Mini-ITX board's parallel port. It worked for us. This is the ONLY guarantee in this post. Whether your parallel port, motherboard or PC works is entirely your risk, your responsibility and I take no responsibility for blown up PCs or CM-5s. Or even burned down houses if you're really stupid. Be careful. It's expensive electronics.
The exercise was all about whether we could write a bootloader. To achieve this we needed to be sure that we could a) write a bootloader to the device and b) unbrick the device if the bootloader had bugs.
So after much googling, much soldering and much debugging of avrdude on OpenBSD (it doesn't appear to support it natively) we managed it.
The process uses a PC parallel port (also known as a TTL level latch) as a general purpose IO interface and (in our case, due to built in protection in the parallel port) directly connected it to the five-pin programming header on the CM-5 PCB.
Our pinout was:
Reset, parallel port pin 4
Sck, parallel port pin 5
MOSI, parallel port pin 2
MISO, parallel port pin 11
Ground, parallel port pin 18
The MOSI, Reset and Sck pins are just using the parallel port data bus pins, MISO uses one of the (many) input pins. Ground is obvious.
The avrdude conf was a bastardised 'bascom' definition and Matt had to hack together an OpenBSD driver (major hack, not worth publishing here) to make it work.
But work it did.
First steps were to read the signature bytes (1E 97 02) to prove the driver (eventually) worked, then we checked the fuse bytes and lock byte. Unfortunately the default lock byte is such that you can't read the flash or eeprom over the SPI programming interface. Fortunately the Robotis bootloader has no such restriction and happily dumped their contents into a waiting file.
So, at 10:30pm last night, we risked a chip-erase command. Please note, for all avrdude users, that the '-n' switch does NOT prevent a chip erase from working. This, to me, screams 'bug', but in our case it wasn't a disaster.
As expected the flash, eeprom and lock byte were reset. Strangely the fuse bytes were unchanged, despite being non-default, so I think the chip erase doesn't touch them.
The erase was confirmed as bricking the CM-5 (i.e. making it as useful for robotics as a house brick) and we set about reprogramming it.
First write of the flash dump I'd previously taken worked and the boot loader came up beautifully first time. Back to robotics!
NOTE: We used a VIA EPIA M-10000 Mini-ITX board's parallel port. It worked for us. This is the ONLY guarantee in this post. Whether your parallel port, motherboard or PC works is entirely your risk, your responsibility and I take no responsibility for blown up PCs or CM-5s. Or even burned down houses if you're really stupid. Be careful. It's expensive electronics.
