PTL-ino replicator
– or –
/******************************************************************************
* ___ _____ _ _ _ _ _ *
* | _ \_ _| | ___(_)_ _ ___ _ _ ___ _ __| (_)__ __ _| |_ ___ _ _ *
* | _/ | | | |_|___| | ' \/ _ \ | '_/ -_) '_ \ | / _/ _` | _/ _ \ '_| *
* |_| |_| |____| |_|_||_\___/ |_| \___| .__/_|_\__\__,_|\__\___/_| *
* |_| *
* *
******************************************************************************/
The PTL-ino replicator is a software that runs on the PTL-ino. The PTL-ino running it (we call it “master”) is connected to a second PTL-ino (“target”). Once connected, the master will procreate its software onto the target. Once the process is over, the target PTL-ino will have the same software installed on its two micro-controllers, the PCI and the AVR as the master. Important here is that the target can be virgin, i.e. without any boot loader or firmware installed. The PTL-ino replicator also contains the standard AVR boot loader PIC firmwares. In other words, once a PTL-ino replicator is available, it can replicate itself onto all other PTL-inos out there and make sure their PICs and AVRs are properly programmed.
Status
Status du project | |
---|---|
Date de début | mid 2015 |
Status | Work in progress |
Initiateur | Magnus |
Detailed description
Operation
Pinout
/******************************************************************************
* _ *
* / _ ._ ._ _ __|_o _ ._ _|_ _.|_ | _ *
* \_(_)| || |(/_(_ |_|(_)| | |_(_||_)|(/_ *
* *
* MASTER TARGET *
* ========= ============== *
* GND GND *
* +5V +5V *
* 18 (PC4) /RST (AVR /RST) *
* 10 (PB2) 13 (PB5, AVR SCK) *
* 9 (PB1) 12 (PB4, AVR MISO) *
* 8 (PB0) 11 (PB3, MOSI) *
* 7 (PD7) PIC MCLR *
* 6 (PD6) PIC DAT *
* 5 (PD5) PIC CLK *
* *
* LED: 13 (PB5) *
* Manual mode: A0 (PC0) (tie to GND to disable automatic programming) *
* *
******************************************************************************/
Interconnection
- 2 devices: 1st is master, 2nd is target:
- 3 devices: 1st ist master, 2nd is target. Once 2nd is programmed it becomes master. Then 3rd ist target. (same legend applies)
- more devices: the middle part can be repeated several times (image gimped; a la copy-paste):
Technical details
Programming the AVR
The AVR is programmed using the “Serial Downloading” mode. This certainly works for virgin devices and also if one has not messed up with the fuses… nothing really special. A bit more tricky is the storage of the image to be programmed. Since a the goal is to achieve a full copy of the device, one can just reads the content of the master device's flash and write it to the slave. Well, not quite. The bootloader section might be read protected. To overcome this, a copy of the bootloader is safed in user space flash (note that this copy is also copied to the next target – ).
Programming the PIC
The PIC is programmed in “low-voltage ICSP” mode (search for a copy of DS41620C – “PIC16(L)F145X Memory Programming Specification”). Again, this works for virgin devices and if one has not mistakenly misconfigured the option words. As the master AVR cannot read the master PIC (well, at least not in a straight forward way, and not without adding more cables) also the PIC code is saved in the AVR user flash.
Btw: the data sheet says: “The LVP bit cannot be programmed to ‘0’ when Programming mode is entered via LVP.” So, we cannot lock us out (even not deliberately…).
MISC
PIC hexfile mode
WARNING: this is very experimental
To send a hex file to the target PIC, you can boot up with A1
tied to GND
and then just send the hex file to the serial port. This can be done either using some serial terminal (e.g. CoolTerm, which I really like), or using the terminal (this is tested on OS X):
(sleep 1;cat images/pic.hex) > /dev/cu.usbmodem00000001
The sleep waits for the bootloader to finish its business.
Here using one of the abundant Arduinos + the heart milled on the cyclone:
Manual mode
WARNING: this is very experimental
I have just added a few menus for terminal use, needs some cleanup and testing. You can enter this mode by just sending a character on the serial port or by tying A0
to GND
.
AVR bootloader
I am experimenting with a modified version of optiboot, that welcomes the user in at more PTL-stylish fashion. For the tools to run smoothly, there is not much time to do so, but below a slow-motion of the LED after reset. Before that here some code:
void flash_ptl() { uint32_t ptl=0x15D1C5DD; uint8_t cnt=32; do { if (ptl&0x1) LED_PORT |= _BV(LED); else LED_PORT &= ~_BV(LED); ptl>>=1; TCNT1 = -200; TIFR1 = _BV(TOV1); while(!(TIFR1 & _BV(TOV1))); watchdogReset(); } while (--cnt); }
which GCC (4.9.1 -Os) nicely compiles to (somewhat commented by me):
ldi r24, 0x20 ; cnt ldi r20, 0xDD ; ptl=[r23:r22:r21:r20]=0x15D1C5DD ldi r21, 0xC5 ldi r22, 0xD1 ldi r23, 0x15 ldi r18, 0x38 ; [r19:r18]=-200 ldi r19, 0xFF ldi r25, 0x01 ; _BV(TOV1) loop: sbrs r20, 0 rjmp clear set: sbi 0x05, 5 rjmp next clear: cbi 0x05, 5 next: lsr r23 ; ptl>>=1 ror r22 ror r21 ror r20 sts TCNT1H, r19 sts TCNT1L, r18 out TIFR1, r25 wait: sbis TIFR1, TOV1 rjmp wait wdr subi r24, 0x01 brne loop