Won't flash using IDE 2.2.1

[bmentink]

Hi, I am trying to program LGTBF328P - MiniEVB nano board. I get the following error:

avrude error: protocol expects OK byte 0x10 but got 0xfc
avrdude error: unable to read signature data for part ATmega328P, rc=-3
avrdude error: unable to read signature data, rc=-3
Failed uploading: uploading error: exit status 1

Any idea's ?

[Devilscave]

@Devilscave, can you check which chip you have on your board?

I also have the CH340C on all the purple ones. The green LGT has the HT42B534-2

[wollewald]

@Devilscave , thank you. But I don't have the CH340C, I have the CH9340C. It's a small difference in the name, but these are dfferent chips. Sorry, but can you double check? @Devilscave , danke. Aber ich habe nicht den CH340C, ich habe den CH9340C. Es ist nur ein kleiner Unterschied im Namen, aber es sind verschiedene Chips. Entschuldigung, aber können Sie das noch einmal überprüfen?

[dbuezas]

That's very interesting, i really didn't expect that. Serial communication works normally at any baudrate otherwise?

Übrigens, lass uns auf Englisch bleiben, das hier wird wahrscheinlich von anderen auch gelesen.

Or maybe the reset line is held too long? I think that's controlled by the usb-ttl chip. The capacitor trick could serve to test that.

[Devilscave]

@Devilscave, danke. Aber ich habe nicht den CH340C, sondern den CH 9 340C. Es ist ein kleiner Unterschied im Namen, aber das sind unterschiedliche Chips. Tut mir leid, aber können Sie das noch einmal überprüfen?

No it's a CH340C

Übrigens, lass uns auf Englisch bleiben, das hier wird wahrscheinlich von anderen auch gelesen.

Sorry, I worked with a page translator and he simply translated my English answer as well. I've changed it.

[wollewald]

@Devilscave , thank you. Helpful information. Then it's something else on the board. Yesterday I tried to use a purple LQFP48 board which uses a CH340C hip like yours and that work as a programmer.

@dbuezas , usually I take a 10µF capacitor. I also tried a 100 µF and a 100 nF capacitor and no capacitor. It all didn't work. Or what do you mean with capacitor trick?

[dbuezas]

Yes I meant a cap at the reset pin. I thought maybe the programmer maybe was reset for too long by dtr.

I burnt my isp without bootloader to avoid accidentally flashing it instead of the target device. I wonder if the purple ones come with a different bootloader?

[wollewald]

I have just burned a new bootloader on the purple LQFP32 and tried again to use it as programmer. But no success. Maybe I will have a good idea over night.

[dbuezas]

Could it be that the serial doesn't work well at the specific baudrate used when isp programming?

[wollewald]

At least worth a try to change the baud rate. I am quite busy currently and so I cannot promise trying this within the next days. It might also help to compare the circuit diagrams of the purple LQFP32 board vs the green one and the purple LQFP48 board which do work. Unfortunately, I have not found circuit diagrams for the purple boards.

[wollewald]

I have some news. I have now received purple LQFP32 boards with a CH340C from two different shops and both work as programmers as they should. I double checked that the purple board with the CH9340C still did not work. Since @Devilscave tried a board with a CH340C chip, which did not the difference between the CH340C and the CH9340C should not be the reason. I have burned on all boards the same bootloader, so this is also not the reason. I have no idea yet why some of these boards do not work. Maybe a bad batch of the PCBs? Here's a photo of one board that is working and another which does not. I can't see obvious differences:

So, good that this is no general issue, but bad that we don't know why the problematic boards behave like they do and how to identify them (before you buy them!).

[Devilscave]

@wollewald Maybe you could, since you own both boards and they seem to be identical, simply swap the CH340 chips across. If the error moves, it is the chip, if it stays, it is the board. If the non-functioning one happens to be the top one on yout picture, I almost assume it is a fake ch9340, the labeling is different and much worse executed. This often tests for counterfeits as the manufacturers usually have very good labeling. EDIT: ahh i see thet the upper one is the CH9340C But change it across.

[wollewald]

Hi @Devilscave , good idea. Let me check if get the chip desoldered and transferred without damage.

[Devilscave]

here the Pinouts from the two ICs

[LaZsolt]

I have an idea about the problematic serial converter chip, CH9340C. The pin 8 low level selecting the dedicated baud rate mode, whatever that means. So lift up pin 8 from PCB for deselect the dedicated baud rate mode.

[wollewald]

Hi @LaZsolt , you are the hero! I cut the pin 8 and then it worked. To be absolutely sure, I reconnected pin 8, then it did not work, disconnected again and it worked. And it does not seem to have negative side effects. I can still upload sketches to the board when not used as programmer. Cutting the pin is not the nicest workaround, but at least we know what that issue is. However, this is only an explanation for the boards that I used. It does not explain why the board of @Devilscave does not work as a programmer since his one has a CH340C chip. @Devilscave , do you still know where you ordered your board? I would buy a board from the same source and hope that they have not changed the design meanwhile.

[Devilscave]

@wollewald I have just checked my source of supply, (aliexpress) )unfortunately the shop no longer has an LGT8 in its range.

[dbuezas]

@Devilscave there's dozens of other shops offering them, they're all fine :)

[Devilscave]

@dbuezas I know, I don't want to buy any, but Wollewald asked for my source of supply.

[wollewald]

Things are getting weird. I have tested some additional purple LQFP32 boards and found different behaviour when trying to use them as programmers. In summary I found four types:

1. Boards with CH9340C: a) Some work if you cut pin 8 b) For others this workaround does not help

2. Boards with CH340C: a) Some just work without any trick b) Others don't

The behavior of each board is reproducible, i.e. it's no a random effect. In some cases I get the "out of sync" meassage, in other cases AVRDUDE reads 0x0000 as device signature. All boards look identical apart from the USB-to-TTL chip. I burned the bootloader on all boards but this had no effect. Whenever I tested several boards from one shop, they all behaved the same. I.e. this is not a random phenomenon.

[dwillmore]

Are these with a known bootloader?

On Fri, Jun 28, 2024 at 3:20 PM Wolfgang (Wolle) Ewald < @.***> wrote:

Things are getting weird. I have tested some additional purple LQFP32 boards and found different behaviour when trying to use them as programmers. In summary I found four types:

1.

Boards with CH9340C: a) Some work if you cut pin 8 b) For others this workaround does not help 2.

Boards with CH340C: a) Some just work without any trick b) Others don't

The behavior of each board is reproducible, i.e. it's no a random effect. In some cases I get the "out of sync" meassage, in other cases AVRDUDE reads 0x0000 as device signature. All boards look identical apart from the USB-to-TTL chip. I burned the bootloader on all boards but this had no effect. Whenever I tested several boards from one shop, they all behaved the same. I.e. this is not a random phenomenon.

— Reply to this email directly, view it on GitHub https://github.com/dbuezas/lgt8fx/issues/312#issuecomment-2197496162, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPEX7EK6DPSPXBSHZ22MXTZJWZRDAVCNFSM6AAAAABDTZ5F42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGQ4TMMJWGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[wollewald]

I have tested the boards with the bootloader which was on them when they arrived but I also burned the bootloader again using a green board as bootloader. This made no difference.

[dbuezas]

I really don't get this. Once the isp starts up the communication between the pc and programmer is serial, and programmer <=> target is just gpio.

• we know its not the bootloader (you flashed it, and the reset cap inhibits dtr resets)
• we know it's not the gpio (you tested my variant with different gpios)
• we know it's not UART in general (otherwise they wouldn't be flasheable via serial)
• we know it's not the clock speed since the isp is flashed to use the internal clock (confirm?)

The only candidates left I see are specific baud rates, and here there's something odd:

• Boards.txt sets isp flashing baudrate to 19200: https://github.com/dbuezas/lgt8fx/blob/master/lgt8f/programmers.txt#L13
• The ISP code sets baudrate to 115200: https://github.com/dbuezas/lgt8fx/blob/master/lgt8f/libraries/LarduinoISP/examples/LarduinoISP/LarduinoISP.ino#L88

That shouldn't work at all in any board (I don't understand how it works on any board), it may be worth trying:

• That the malfunctioning boards can do serial at 19200
• Changing those baud rate configurations to other values
• Making those baud rate match

[SuperUserNameMan]

Duno if it may help, but I remember that CHxxx UART IC that use internal clock source instead of an external crystal tends to fail more often (at certain baudrate speed).

[dbuezas]

Interesting, then changing the baud rate in platforms.txt and the isp code may work

[wollewald]

I spent some hours playing with different baudrates with no success. I will stop here, at least for the moment.

[dbuezas]

A mystery. Since the baudrate in the isp code and platforms.txt don't match, There may be something else setting the baudrate