Just received a batch of 10 Nano Clones from Aliexpress. The first 5 I have checked, have Mega328PB-U chips.
Might not hurt to check new Clones to see if they have the new chip.
I have not been able to load sketches to them until I burn the Minicore bootloader. They seem to work OK for loading sketches after that.
I am marking mine with fingernail polish and will just use them. It's not worth the hassle to return them.
The new Nano's also have a CH340C USB Chip. No external crystal on the CH340C.
I ran Serial and Serial1 for several hours with no problems. Just a simple test though.
Well at least you have two extra digital IO pins on A6 and A7 as a consolation prize. The ATmega328PB is a bit cheaper than the ATmega328P so I suppose it's not surprising but I'm sure this could cause a lot of confusion for someone with less experience.
I found a problem with the beta version of Arduino AVR Boards required by MiniCore for the PB chips:
That's only an issue if you use the "Arduino as ISP" programmer. I also ran into a problem with the compiler that forced me to stop using it. It only occurred when compiling a very large and ugly code with a lot of templates and it wasn't consistent so I never got around to reporting it to Arduino. I forget the exact error but it wasn't a code error, but rather a glitch in the compiler itself.
Try making this change to the arduinoISP sketch...
case 'E': // extended parameters - ignore for now
{
uint8_t l = getch();
if (l >= 4 && l < 20) { // do a bit of sanity checking
fill(l);
}
empty_reply();
break;
}
case 'P'
With your modified ArduinoISP sketch Burn Bootloader using Arduino AVR Boards 1.6.206's avrdude 6.3.0-arduino12 still fails, but with different output (see attached westfw_verbose_1.6.206.txt).
However, that sketch also causes Arduino AVR Boards 1.6.21's Burn Bootloader using avrdude 6.3.0-arduino9 to fail, with similar output to that of avrdude 6.3.0-arduino12 (see attached westfw_verbose_1.6.21.txt).
When I use the stock ArduinoISP sketch, my results remain the same as I reported in my issue report (success using avrdude 6.3.0-arduino9, failure using avrdude 6.3.0-arduino12, with ~same -v -v -v -v output).
Huh. The stk500v1 spec says 4 parameters including the "EOP" character, but it looks like avrdude has been sending 5.
AVRISP says it receives 4 parameters, which I guess is correct, but I wonder if that's from the spec, or from testing...
I guess I'll try to test my next patch before I ask you to try it!
And since I mentioned it before and now have Arduino AVR Boards 1.6.206 installed again, here's the error message I get when compiling a specific program that uses a stupid number of templates and macros:
E:\electronics\arduino\libraries\EtherEvent/EtherEvent.h: In function 'bool EtherEventClass::send<IPAddress, IPAddress, __FlashStringHelper const*>(EthernetClient&, unsigned char const*, unsigned int, IPAddress, IPAddress, __FlashStringHelper const*) [clone .isra.15] [clone .constprop]':
E:\electronics\arduino\libraries\EtherEvent/EtherEvent.h:474:5: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper.exe: fatal error: C:\Users\per\AppData\Local\Arduino15\packages\arduino\tools\avr-gcc\5.4.0-atmel3.6.1-arduino2/bin/avr-gcc returned 1 exit status
compilation terminated.
c:/users/per/appdata/local/arduino15/packages/arduino/tools/avr-gcc/5.4.0-atmel3.6.1-arduino2/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
Every time I started to simplify it to produce a reasonable bug report the error would go away but if anyone wants to have a look I'm happy to provide everything you need to reproduce it. The program compiles fine with Arduino AVR Boards 1.6.21 and earlier.
The new toolchain has been in the pipeline for a long time now so I suspect it's planned to hit the next release. I definitely would like to see any serious issues resolved before it's unleashed on the masses. It shows how important it is for the community to get involved in the beta testing process. It takes some effort and inconvenience but so does providing support on the forum for all the people affected by a bug that goes out in a production release. I know there have been at least two threads here already regarding the Arduino as ISP problem.
westfw:
I guess I'll try to test my next patch before I ask you to try it!
I surely don't mind being guinea pig if it can be helpful. I suppose I'm at least qualified for that role if not to dig into the inner workings of avrdude.
It would be nice if there was better adherence to a formal versioning system. I should be able to easily compare the commits between avrdude 6.3.0-arduino9 and avrdude 6.3.0-arduino12. Instead, the only tag in the arduino/avrdude-build-script repository is "6.3-arduino", even though there have been 4 separate production releases of avrdude 6.3.0. I assumed the changes made in the avrdude versions included with the Arduino AVR Boards 1.6.20x beta releases would only be the addition of the PB parts definitions to avrdude.conf since that's the only necessary change I would foresee for the toolchain update which was the subject of those beta releases and no other avrdude changes were mentioned.