Improved LarduinoISP

[SuperUserNameMan]

Hello,

As mentioned into pull request #50, when LarduinoISP/LGTISP is used to dump flash content using the AVRdude terminal, it will displays 0xFF everywhere.

This is because LarduinoISP/LGTISP only implements minimal required functionalities to upload/verify bootloaders and sketches using Arduino IDE.

So, today, I've managed to implement the missing functionality used by the dump flash command of AVRdude in terminal mode.

Many more functionalities are missing though (erase, dump eeprom, write flash/eperom/fuzes, etc).

You can find my LGTISP fork and updated instructions here : https://github.com/SuperUserNameMan/LGTISP

[dbuezas]

This is awesome! We should link to your repo in the readme.
Would it be ok for you to add your code to the examples of this one so it comes built in? Then all the readmes & issues link back to your repo of course,

[SuperUserNameMan]

This is awesome! We should link to your repo in the readme.
Would it be ok for you to add your code to the examples of this one so it comes built in? Then all the readmes & issues link back to your repo of course,

Do like you want.
It's open-source like the rest of the original code anyway :-D
(about which i don't even know what license it was).

I wish I could have published a "push request" or a "patch" to brother-yan/LGTISP or to your repository, but I don't remember how to use git and I think I've made too much modifications at once. (I just copy pasted my code to Github)

[dwillmore]

I agree that it's open source and people can do what they want as long as they comply with the license, but it's still polite to ask. ;) Especially as a means of showing respect and appreciation for the work that you've done. So, thank you!

…

On Tue, Nov 3, 2020 at 12:43 PM SuperUserNameMan ***@***.***> wrote: This is awesome! We should link to your repo in the readme. Would it be ok for you to add your code to the examples of this one so it comes built in? Then all the readmes & issues link back to your repo of course, Do like you want. It's open-source like the rest of the original code anyway :-D (about which i don't even know what license it was). I wish I could have published a "push request" or a "patch" to brother-yan/LGTISP or to your repository, but I don't remember how to use git and I think I've made too much modifications at once. (I just copy pasted my code to Github) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/dbuezas/lgt8fx-forum/issues/1#issuecomment-721279533>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPEX7B46SLOTE7OIYBBTK3SOA6N3ANCNFSM4TI5GNVA> .

[SuperUserNameMan]

I've started implementing the code for the dump eeprom command of AVRdude in terminal mode.

However, you can already see the content of the EEPROM with dump flash 0x7800 512 and dump flash 0x7c00 512 (since the LGT8F328p EEPROM is stored into the flash)

[SuperUserNameMan]

I've just added the support for dump eeprom command of AVRdude in terminal mode.

Note : the EEPROM is automatically erased each time we update the sketch using the Arduino IDE.

[LaZsolt]

Does anyone know what this means in the datasheet?

New programming Encryption Algorithm, ensure of user code security

I don't remember finding an explanation for how it works.

[LaZsolt]

I think I figured out from Brother-yan and SuperUserNameMan comments what programming Encryption Algorithm mean.

So programming Encryption Algorithm is when someone want to read progmem flash the LGT8Fx chip will erase its flash contents.
This "encrypion algorithm" activate itself when chip powered off after programming.
But, as Brother-yan wrote, he figured out the bigger part of the progmem can be made readable somehow. Maybe after writing something into the flash, then became readable all the content?

[SuperUserNameMan]

But, as Brother-yan wrote, he figured out the bigger part of the progmem can be made readable somehow. Maybe after writing something into the flash, then became readable all the content?

According to the google-translated comment of brother-yan into swd_lgt8fx8p.cpp, the trick is to erase the first 1KB of the flash. Then, the rest become readable.

uint8_t crack() // 破解读保护(目前只能读出除了前1k以外的flash，前1k会被擦除) // Crack the read protection (currently only the flash except the first 1k can be read, the first 1k will be erased)
{
	SWD_EEE_CSEQ(0x00, 1);
	SWD_EEE_CSEQ(0x98, 1);
	SWD_EEE_CSEQ(0x92, 1); // 会擦除flash的第一页(1024 bytes) // Will erase the first page of flash (1024 bytes)
	delay(200);
	SWD_EEE_CSEQ(0x9e, 1); // 解锁 // unlock
	delay(200);
	SWD_EEE_CSEQ(0x8a, 1);
	delay(20);
	SWD_EEE_CSEQ(0x88, 1);
	SWD_EEE_CSEQ(0x00, 1);
}

However, I'm not sure this crack was mandatory, because when I implemented the dump flash support, I was using this older version of swd_lgt8fx8p.cpp : https://github.com/dbuezas/lgt8fx/tree/master/lgt8f/libraries/LarduinoISP/examples/LarduinoISP
which does not contains the crack().
And it seems to me that the flash did not need this crack to be readable with dump flash.

Maybe my memory is wrong ? maybe i did not notice because i did not powerdown the LGT each time ? maybe it becomes write protected if a secret bit is set ? I don't know ...

[SuperUserNameMan]

@LaZsolt :

Ok, so I've just made several tests. Here is what I can confirm :

• once powered down, the LGT8Fx will lock itself and will refuse to be programmed again using the ISP (but it will not self-destruct its flash if you try to dump flash ).

The flash is actually erased by LarduinoISP and LGTISP as part of their procedure to unlock the chip.

The original LarduinoISP erased the whole content, but brother-yan/LGTISP found that only the first 1KB of flash could be erased to unlock the flash.

So, if we want to debug/dump the whole content of the flash using AVRdude terminal, we must do that without powering down the LGT8Fx, just after programming it ...

EDIT : also, if we connect the LGT8Fx to AVRDUDE terminal after a power down, we will lose the first 1KB of flash ....

[SuperUserNameMan]

Ok, I've just disabled the destructive unlock by default.

Once powered down, the flash will be locked, and dump flash will display 0xFF everywhere.

dump lock will replies 0x3E if device locked, and 0x3F if unlocked.

write lock 0 0 will force the destructive unlock.
The first 1KB of flash will be lost, but the rest of the memory (including the EEPROM) will be readable.

The only way to inspect the first 1KB of flash is to keep the device powered between the programming and the dump flash 0x0000 1024.

I've updated the repo and the readme.

Thanks again to @LaZsolt for pointing that out ! :-)

[LaZsolt]

Your work are awesome again.

[SuperUserNameMan]

Because we're a good team ;-D

[SuperUserNameMan]

update :

• I added a workaround to dump the content of the EEPROM when it is greater than 1KB.

Because the ISP pretend to be connected to an ATmega328p, AVRdude will only allow to dump 1024 bytes of EEPROM.
dump eeprom 0 1024 is the maximum we can get.

To workaround this limitation, we can now use the command write eeprom 1023 0x<page><size> to tell to the ISP which 1KB page of the EEPROM we want to dump, and what is the size of this EEPROM.

<page> must be replace by a number from 0 to 7.
<size> must be replaced by a number among 1, 2, 4 and 8.

<page>	EEPROM address space	hex
0	0 - 1023	0x0000 - 0x03FF
1	1024 - 2047	0x0400 - 0x07FF
2	2048 - 3071	0x0800 - 0x0bFF
3	3071 - 4095	0x0c00 - 0x0FFF
4	4096 - 5119	0x1000 - 0x13FF
5	5120 - 6143	0x1400 - 0x17FF
6	6144 - 7167	0x1800 - 0x1bFF
7	7168 - 8191	0x1c00 - 0x1fFF

<size>	EEPROM size
1	1024
2	2048
4	4096
8	8192

Examples :

• write eeprom 1023 0x04 will select page 0 of a 4KB EEPROM.
• write eeprom 1023 0x38 will select page 3 of a 8KB EEPROM.

dump eeprom 0 1024 will display this page.