Support LGT8F328P

[mcuee]

Ref: as of now urboot does not work for the LGT8F328P. It will be good to have the support.

• Serial drain timeout and -c urclock avrdudes/avrdude#1193 (comment)

More info about typical LGT8F328P board. It seems to me the most common one is the Nano style, followed by the Pro Mini style and the Uno style.
https://github.com/dbuezas/lgt8fx

So far only the vendor provided Optiboot bootloader firmware works on my Nano LGT8F328P board.
https://github.com/LGTMCU/Larduino_HSP/tree/master/hardware/LGT/avr/bootloaders/lgt8fx8p
https://github.com/dbuezas/lgt8fx/tree/master/lgt8f/bootloaders/lgt8fx8p (same as above)

For people who want to try different bootloaders, they can use Nano or Uno to burn the bootloaders with the following projects.
https://github.com/LGTMCU/LarduinoISP (from the vendor)
https://github.com/brother-yan/LGTISP

[mcuee]

The vendor seems to point to their partner for development board.
https://ocrobot.com/collections/alpha/products/lgt8f328p-u-control-board
https://www.aliexpress.com/store/1100080027?spm=a2g0o.detail.1000007.1.386c5619BKeuLD

Schematics:
https://wiki.ocrobot.com/lib/exe/fetch.php?media=ocrobot:alpha:8f328p-u:ocrobot_alpha_8f328p-u_r3.pdf

[mcuee]

BTW, I can see that picoboot is running on my Nano LGT8F328P clone (PB5+ LED glowing). Still I can not use -c arduino or -c urclock to talk to the board.
https://github.com/nerdralph/picoboot/tree/master/arduino

But with urboot_atmega328p_autobaud_led+b5_ur_vbl.hex I do not even see the LED light up.

The stock optiboot bootloader FW lights up the LED properly (short pulse LED).

[stefanrueger]

as of now urboot does not work for the LGT8F328P

I am not convinced this is true!

The LGT8F328P does not have eeprom and has different execution times for opcodes; so must use USART (not SWIO).

Last time I checked the lgt8f328p was not supported by avr-gcc/avr-libc. So, out of necessity, need to choose from the atmega328p bootloaders. Choose a fixed baud rate urboot bootloader without eeprom support. If you have double F_CPU then the baud rate will be double. So if you use a 16 MHz/115200 baud urboot bootloader it will run at twice the baud rate (230400 baud) when F_CPU is 32 MHz instead of 16 MHz. Vice versa, if you do not know the F_CPU of your board after reset, just try different baud rates. You will need to take care of the fuse settings etc just as you would with a ATmega328P.

Autobaud bootloaders require -c urclock send a different sync byte. Use this PR from avrdude or git main once this has been merged. Figure out how many cycles this loop takes

urboot/src/urboot.c

Lines 2323 to 2325 in 1c26c69

	"2: adiw r26, 256/8\n" /* Add 0.125 to X, ie, 256/8 to XL, in 8-bit fixed point rep */ \
	" sbis %[RXPin],%[RXBit]\n" /* Loop as long as rx bit is low */ \
	" rjmp 2b\n" /* 5-cycle loop for 5 low bits (start bit + 4 lsb of 0x30) */

and choose a sync byte accordingly. Rumour has it the loop takes 3 cycles for the lgt8f328p.

Sync byte	Cycles
0x20	6
0x30	5
0x18	4
0x1c	3

Ensure avrdude.conf holds autobaud_sync = 0x1c; for the lgt8f328p part. Using avrdude from PR from avrdude or git main once this has been merged try

avrdude -plgt8f328p -F -curclock ...

with the autobaud urboot bootloader. This should work. You need to force -F the part definition lgt8f328p for the autobaud_sync byte.

If your board does not have an RTS/DTR reset mechanism, you need to press reset manually, release reset, then start avrdude (possibly with -xdelay=-110).

If none of the above works

• Carefully recheck every step try again, it should work
• Still no joy? Find other differences between AVR and LGT parts
  • Is the USART API the same? Same registers? Same register addresses? Same syntax?
  • Are the ISP tables the same?
  • Is flash the same? What is the emulated EEPROM that is taken from flash all about?
  • Can bootloaders snuggle up in high flash as they do on all classic AVRs?
  • Are the fuses the same?

[mcuee]

@stefanrueger

From what I read, with regard to the KB bootloader, you are right that only 1KB is for bootloader and the other 2KB is for EEPROM (using 2KB Flash to emulate 1KB EEPROM).

From what I read, this is actually not the default, the default is 32KB Flash and no EEPROM emulation.

Could you provide autobaud bootloader hex file with or wthout the EEPROM emulation? LED pin is PB5+. CPU frequency by default is 32MHz RC oscillator upon power up.

The programmer LGTISP does not support EEPROM or Fuse settings. From my quick glance of the datasheet for the LGT8F328P, there is no fuse settings anyway. Reset vector is at 0x0000 (two bytes). WDT reset vector is at 0x000C

[stefanrueger]

Could you provide autobaud bootloader hex file with or wthout the EEPROM emulation?

Seeing as you have the part, the datasheet, ability to read Mandarin, and ability to compile your own (make F_CPU=32000000L ...), I am not sure how much I can help you. You are in a far better position than I am.

If you want to move the bootloader to a different location than top flash that is a bit tricky, but can probably be done. make and urboot-gcc print out the command lines that are ultimately used to generate the bootloader. For example,

$ make atmega328p_amin
make TOOLVER=4.8.1 GCCROOT=./avr-toolchain/4.8.1/bin/ MCU=atmega328p AUTOBAUD=1 URPROTOCOL=1 EEPROM=0 VBL=1 FRILLS=3 MOVETO=atmega328p_amin
make[1]: Entering directory '/home/srueger/etc/clock/urboot/src'
./avr-toolchain/4.8.1/bin/avr-gcc -DSTART=0x7f00UL -DRJMPWP=0xcfe2 -Wl,--section-start=.text=0x7f00 -Wl,--section-start=.version=0x7ffa -D_urboot_AVAILABLE=2 -g -Wundef -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328p -DF_CPU=16000000L -Wno-clobbered -DWDTO=1S -DAUTOBAUD=1 -DDUAL=0 -DEEPROM=0 -DURPROTOCOL=1 -DFRILLS=3 -DVBL=1 -Wl,--relax -nostartfiles -nostdlib -o atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.elf urboot.c
./avr-toolchain/4.8.1/bin/avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.elf atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.hex
./avr-toolchain/4.8.1/bin/avr-objdump -h -S atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.elf > atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.lst
mv atmega328p_16mhz_auto_115200bps_v1f3_wdto1s_ur.hex atmega328p_amin.hex
-- 254 256 u7.7 w-u-jpra- atmega328p_amin.hex

You could try to manually compile by dropping the start addresses by 2k, ie, use -DSTART=0x7700, then for the .text linkage -Wl,--section-start=.text=0x7700 but keep the .version linkage -Wl,--section-start=.version=0x7ffa. This would still leave the RJMPWP jump opcode wrong: you could use -DRJMPWP=0x9508, which is the ret opcode thus disabling w or you might strike lucky by subtracting 1024 form the RJMPWP opcode computed by urboot-gcc, ie, jump 1024 = 2048/2 words further backwards to catch the moved pgm_write_page() routine. (Striking lucky means, my memory of how the rjmp opcode encodes the jump destination is correct). In the example above this would be -DRJMPWP=0xcbe2. Note that -c urclock still expects the version bits to be in top flash, which would be in the emulated EEPROM area and are thus at risk of being overwritten by the user eeprom "emulation" code.

[mcuee]

Thanks, I have build urboot with F_CPU=32000000L but it does not work. So I was thinking that the location of the bootloader is the issue. It will still be at the top of the flash, just that we need to pretend the bootloader is 3KB size.

Or maybe I will try the 1KB bootloader option which is supposed to be the default upon power up (no EEPROM emulation). It seems to me the bootloader source code published does not match the hex file from the vendor.

I will check if the fork here has newer source code.
https://github.com/nulllaborg/arduino_nulllab/tree/master/bootloaders/lgt8fx8p

Let me try again later with your suggestion.

[stefanrueger]

autobaud should not need F_CPU. The .hex files should be the same irrespective of F_CPU.

[SpenceKonde]

IMHO this ain't worth it. It's a poorly documented chip from a sketchbag vendor likely based on stolen silicon IP. And don't you dare get me started on that holtek serial chip it usually comes bundled with. That thing so bad, you don't want to throw it away in you own garbage cans, because if raccoons get into your trash and see the HT42B534s in your trash, and then they'll know your incompetent, and next time they see you with food, they'll attack, confident that if you bought that bridge from holtek, you're probably too clueless to fight a racoon. (speaking as someone with 100 of them kicking around. During the periods when they work, they really scream, they too often just choke. The windows CDC driver crashes when you do anything it doesn't like, it's only able to make a small limited selection of baud rates, and it's modem control input line start off all "off" until one changes, at which point all of them switch from active low to active high, and remain that way until next reset). I haven't thrown them out yet. I think I'm gonna put them in with my "$XX for a priority mail small flat rate box packed to the gills with bad PCB." so the local wildlife and can hobos doesn't know holtek ripped me off with bunk serial adapters. I've got like a whole xerox box worth of bad boards now. And the results of my last order with the board house. ah.. let's just say that order isn't preventing growth of the box of bad boards.

[mcuee]

I have a few boards with the LGT8F328P and they actually use CH340.

But I agree this is not a priority. The factory optiboot bootloader is working.

[mcuee]

Reference in Optiboot as well.

• To support LGT8F328P Optiboot/optiboot#359

You can see that I can build the optiboot hex file but the hex files generated do not work, even though factory hex file works.

[mcuee]

I will give up for now. Hopefully someone else who is more familiar with the chip can chime in and help out.

[stefanrueger]

| even though factory hex file works

The key will be to figure out how the manufacturer changed optiboot to make it work for their factory hex file...

[mcuee]

| even though factory hex file works

The key will be to figure out how the manufacturer changed optiboot to make it work for their factory hex file...

Yes, it seems to me the optiboot source codes provided might not match the factory hex file. Reverse engineering is needed in this case. Or maybe the source codes match the hex file but I need to use old version of compilers.
https://github.com/LGTMCU/Larduino_HSP/tree/master/hardware/LGT/avr/bootloaders/lgt8fx8p

Probably the lst file is the key. I have not really looked into it yet.
https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/optiboot_lgt8f328p.lst

For one thing it does match here why the bootloader starts at 0x7400.
https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/optiboot.c#L458-L468

  // WDT clock by 32KHz IRC
  PMCR = 0x80;
  PMCR = 0x93;

  // system clock: 16MHz system clock
  CLKPR = 0x80;
  CLKPR = 0x01;

  // enable 1KB E2PROM (for LGT8F328P)
  ECCR = 0x80;
  ECCR = 0x4C;

[stefanrueger]

These lines indicate initialisation of registers that the ATmega328P does not have: PMCR and ECCR. CLKPR (clock prescale reg) exists and is set to a divisor of 2, ie, the first thing that happens is that the clock speed is set to 16 MHz. Do you know of any avr toolchain that has the relevant io*.h file for the LTG8F328P that defines the registers? I don't. That's necessary to compile for that MUC, so avr-gcc can translate lines like ECCR = 0x4C;. It's a bit hard to program for an MUC that isn't in the avr-libc, that the compiler does not support and without a clear data-sheet.

[mcuee]

@stefanrueger

Finally I got it working by using WInAVR toolchain. I can reproduce exactly the same hex file and it works.

• To support LGT8F328P Optiboot/optiboot#359 (comment)

It also works with Atmel toolchain based on avr-gcc 5.4.0, but not the Atmel toolchain based on avr-gcc 7.3.0.

As for the header file, it is provided by the vendor here.
https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/lgtx8p.h

[mcuee]

@stefanrueger

From here.

• To support LGT8F328P Optiboot/optiboot#359 (comment)

Here are some major changes by the vendor from an older version of optiboot (v5.0). There are also quite some changes if you compare the source codes.
https://code.google.com/archive/p/optiboot/downloads
https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/optiboot/optiboot-v5.0.zip

1. the header file is provided by the vendor here.
   https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/lgtx8p.h

2. initialization sequences
   https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/optiboot.c#L458-L468

  // WDT clock by 32KHz IRC
  PMCR = 0x80;
  PMCR = 0x93;

  // system clock: 16MHz system clock
  CLKPR = 0x80;
  CLKPR = 0x01;

  // enable 1KB E2PROM (for LGT8F328P)
  ECCR = 0x80;
  ECCR = 0x4C;

3. Makefile changes here.
   https://github.com/LGTMCU/Larduino_HSP/blob/master/hardware/LGT/avr/bootloaders/lgt8fx8p/Makefile#L336-L354

# LGT8F328P
#
lgt8f328p: EXT_OSC ?= 0
lgt8f328p: TARGET = lgt8f328p
lgt8f328p: MCU_TARGET = atmega328p
lgt8f328p: CFLAGS += $(COMMON_OPTIONS)
#lgt8f328p: CFLAGS += $(COMMON_OPTIONS) '-DSOFT_UART'
lgt8f328p: CFLAGS += '-DVIRTUAL_BOOT_PARTITION'
lgt8f328p: AVR_FREQ ?= 16000000L 
lgt8f328p: LDSECTIONS = -Wl,--section-start=.bootv=0x0
lgt8f328p: LDSECTIONS += -Wl,--section-start=.text=0x7400 -Wl,--section-start=.version=0x77fe
lgt8f328p: $(PROGRAM)_lgt8f328p.elf
lgt8f328p: $(PROGRAM)_lgt8f328p.hex
lgt8f328p: $(PROGRAM)_lgt8f328p.lst

lgt8f328p_isp: lgt8f328p
lgt8f328p_isp: TARGET = lgt8f328p
lgt8f328p_isp: MCU_TARGET = atmega323p
lgt8f328p_isp: isp

4. Watchdog related changes.

5. GUID

6. EEPROM changes

[stefanrueger]

Too many undocumented changes for this to be currently tackled.

As a fist step, the part ought to be supported by avr-libc and avr-gcc. For example, avr-gcc needs to take -mmcpu=lgt8f328p or some such as argument, select the right lgtx8p.h header file and link with the appropriate libray functions for the part. There are further undocumented changes how EEPROM works, so this is quickly becoming a project on its own, as the part really is quite different from the AVRs... Afraid to say, that's not a priority right now.

[mcuee]

Afraid to say, that's not a priority right now.

Totally agree with you here. I am happy to be able to build the factory bootloader hex file and that is about it. I may also try to remove the 2KB EEPROM support to see if it works (move the bootloader from 0x7400 to 0x7c00).

EEPROM read/write is not working anyway.

PS C:\work\avr\avrdude_test\avrdude_bin> .\avrdude -c urclock -P COM19 -b 57600 -p lgt8f328p -qqt
avrdude> dump eeprom 0 0x10
avrdude error: bootloader might not have paged EEPROM read; try -xeepromrw if it has
avrdude error: bootloader might not have EEPROM access; try -xeepromrw if it has
avrdude error: unable to read eeprom page at addr 0x0000
avrdude error: (dump) error reading eeprom address 0x00000 of part LGT8F328P
               read operation not supported on memory type eeprom
avrdude> dump flash 0 0x10
0000  0c 94 66 00 0c 94 78 00  0c 94 78 00 0c 94 78 00  | .f. .x. .x. .x.|

avrdude> dump flash 0x7400 0x10
7400  11 24 8f ef 98 e0 9e bf  8d bf 94 b7 14 be 89 2f  |.$............./|

avrdude> dump flash 0x73c0 0x40
73c0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
73d0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff 42 6c  |..............Bl|
73e0  69 6e 6b 2e 69 6e 6f 2e  6c 67 74 38 66 78 38 70  |ink.ino.lgt8fx8p|
73f0  2e 68 65 78 00 e6 07 06  04 14 38 1c 04 c2 6f 17  |.hex......8...o.|

avrdude> quit

[mcuee]

I think it is probably not worth the efforts in the end. So I will close this for now.