Go Down

Topic: Burning the bootloader on a Chinese Nano (Read 10691 times) previous topic - next topic

knut_ny

Is all this because of the CH340 chip ? ..and a missing driver ?

Ny

lesept

I don't think it's because of the CH340 chip, because all the other nanos I use have this chip and are working fine.

Here is the wiring I used for my last answer:
Code: [Select]
NanoA -- NanoB ICSP connector
  D13 -- 3 (SCK -- SCK)
   5V -- 2
  GND -- 6
  D10 -- 5 (SS -- RESET)
  D11 -- 1 (MISO -- MISO)
  D12 -- 4 (MOSI -- MOSI)
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

Robin2

Here is the wiring I used for my last answer:
Why have your two Nanos got different pin connections for the same thing?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lesept

Because I use the pins for working NanoA and the ICSP connector for NanoB. This is presented like in the instructable website I used at the beginning (it was my first attempt for burning a bootoader). Do yu think I should use the pins for both ?

A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

Robin2

Do yu think I should use the pins for both ?
Wouldn't it avoid a lot of confusion?

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lesept

Sorry for the confusion, but it should give the same results, shouldn't it ?
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

Robin2

Sorry for the confusion, but it should give the same results, shouldn't it ?
How would I know unless I go to the datasheet and check the correspondence of all the different pins (which I have no intention of doing).

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lesept

Ok, I understand.
So I have changed : wired pin to pn as below:
Code: [Select]
NanoA -- NanoB
D11 -- D11
D12 -- D12
D13 -- D13
5V -- 5V
GND -- GND
D10 -- pin 5 of ICSP connector


Then I connect NanoA (working one) to the computer, choose the options "Arduino Nano" and "Atmega 328" on the IDE, and "AVRISP mkll" as programmer.

I then  upload the borad programmer on NanoA and I get on the console :
Code: [Select]

Atmega chip programmer.
Written by Nick Gammon.
Version 1.37
Compiled on Nov 12 2017 at 20:07:14 with Arduino IDE 10802.
Attempting to enter ICSP programming mode ...
Entered programming mode OK.
Signature = 0x1E 0x94 0x0B
Processor = ATmega168PA
Flash memory size = 16384 bytes.
LFuse = 0xC6
HFuse = 0xDD
EFuse = 0xFC
Lock byte = 0xEF
Clock calibration = 0x91
Bootloader address = 0x3E00
Bootloader length = 512 bytes.
Type 'Q' to quit, 'V' to verify, or 'G' to program the chip with the bootloader ...

Then I type V and I get:
Code: [Select]
Verifying ...
Verification error at address 3FF4. Got: 0x00  Expected: 0xFF
Verification error at address 3FF5. Got: 0x00  Expected: 0xFF
Verification error at address 3FF6. Got: 0x00  Expected: 0xFF
Verification error at address 3FF7. Got: 0x00  Expected: 0xFF
Verification error at address 3FF8. Got: 0x00  Expected: 0xFF
Verification error at address 3FF9. Got: 0x00  Expected: 0xFF
Verification error at address 3FFA. Got: 0x00  Expected: 0xFF
Verification error at address 3FFB. Got: 0x00  Expected: 0xFF
Verification error at address 3FFC. Got: 0x00  Expected: 0xFF
Verification error at address 3FFD. Got: 0x00  Expected: 0xFF
10 verification error(s).
Programming mode off.
Type 'C' when ready to continue with another chip ...

So there seems to be a problem. When I try to uplad the Blink sketch on NanoB, I get the same error messages, such as:
Code: [Select]
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x0a
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

lesept

And if I choose "Atmega 168", it doen't upload, I get :

Code: [Select]
Arduino : 1.8.2 (Windows 10), Carte : "Arduino Nano, ATmega168"

Les options de compilation ont été modifiées, tout sera recompilé
Archiving built core (caching) in: C:\Users\Chuwi\AppData\Local\Temp\arduino_cache_818645\core\core_arduino_avr_nano_cpu_atmega168_0c812875ac70eb4a9b385d8fb077f54c.a
Le croquis utilise 10286 octets (71%) de l'espace de stockage de programmes. Le maximum est de 14336 octets.
Les variables globales utilisent 241 octets (23%) de mémoire dynamique, ce qui laisse 783 octets pour les variables locales. Le maximum est de 1024 octets.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x5d
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x5d
Problème de téléversement vers la carte. Voir http://www.arduino.cc/en/Guide/Troubleshooting#upload pour suggestions.


I will most probably give up...
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

Robin2

#39
Nov 12, 2017, 11:31 pm Last Edit: Nov 12, 2017, 11:31 pm by Robin2
I can't think of anything else to suggest.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

lesept

Thanks for your valuable help anyways !!!
A force d'essayer on finit par réussir... Donc, plus ça rate, plus on a de chances que ça marche (proverbe Sharduinok).

Phoenixset

Hey, i know this may be late but i had same problem, try this if it's not too late:
in arduino IDE goto: Tools->Processor and choose ATmega328P (Old BootLoader).
That worked to me, no need to reflash it.
Now you can upload any sketch.

GoForSmoke

#42
Jan 06, 2019, 11:16 am Last Edit: Jan 06, 2019, 11:43 am by GoForSmoke
Quote
Le croquis utilise 10286 octets (71%) de l'espace de stockage de programmes. Le maximum est de 14336 octets.
Les variables globales utilisent 241 octets (23%) de mémoire dynamique, ce qui laisse 783 octets pour les variables locales. Le maximum est de 1024 octets.
You filled the RAM to the limit. Are you sure that's Blink?
1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

sterretje

Hey, i know this may be late but i had same problem, try this if it's not too late:
in arduino IDE goto: Tools->Processor and choose ATmega328P (Old BootLoader).
That worked to me, no need to reflash it.
Now you can upload any sketch.
In 2017 when this thread started, the 'old bootloader' option did not exist; only came in the beginning of 2018 with board manager 1.6.21.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.

Go Up