Go Down

Topic: Flashing sketch over serial port to a bare 328p. (Read 198 times) previous topic - next topic

jpadie

Hi

I have a bunch of home made nodes that user a 328p at the core (with rfm12b and a temp sensor). 

I am able to burn the bootloader over SPI with no problem.  and serial comms are fine too.  In each case I am using an Uno as the interface (for uart I remove the 328p chip from the Uno). 

The bootloader I am using is fused so that the brownout detection is disabled and the clock source is the internal 8MHz. 

programming with SPI and then debugging with serial is a bit fiddly (no headers on these boards as not enough vertical space in the enclosures - so it's a pogo pin job) and I was hoping to take advantage of the bootloader to programme via USB and debug at the same time. 

But no joy - whatever variation of programmer I use (at least of those that support stk500v1) nothing is uploaded.

Is this a timing issue?  If so, is there a way around that without changing the crystal on the Uno board?  I suppose I could debug the code on a sacrificial board and use a 16MHz bootloader and external crystal - but that doesn't help debug hardware issues on all of the other boards.

any thoughts/advice welcome.

thanks
Justin

 

groundFungus

How are you resetting the target board during upload? 

johnwasser

Note that if you use ISP to upload a sketch it overwrites the Serial bootloader.  To do a Serial upload you need to re-burn the bootloader.  

Be sure to use an 8 MHz bootloader or the baud rate will be wrong.

If you don't have the auto-reset circuit, you may have to manually reset the board at the right time to Serial-upload a second time.  The first time should work even without auto-reset since the bootloader has nothing better to do than wait for an upload.
Send Bitcoin tips to: 1G2qoGwMRXx8az71DVP1E81jShxtbSh5Hp

jpadie

Hi John

I'd thought exactly the opposite: that burning the bootloader deleted the sketch.  that may well be the answer to everything!

will try; and report back.

thanks
Justin

jpadie

alas no luck.

I reburned the bootloader using SPI and then tried to use the uart to burn a sketch.   

the Uno has an autoreset circuit and reset on the target board is pulled up with a 10k resistor.  probably unnecessary given that the Uno itself is pulled up by 10kOhm.

for sure I am using an 8MHz bootloader.   

after reburning the bootloader I still can't burn via uart.  the wiring is simple:

1. remove 328p chip from Uno
2. reset -> reset
3. 5v -> Vin
4. GND->GND
5. RX->RX
6. TX->TX

there is one non 5v tolerant component on the board but it does not get powered up until told by the sketch.  so not a problem at the moment (and burning that is the least of my concerns). 

the verbose response from avrdude is unhelpful:
Code: [Select]

        Using Port                    : usb
         Using Programmer              : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)

avrdude done.  Thank you.

An error occurred while uploading the sketch

 

any suggestions please?

thanks again
justin



jpadie

@groundfungus

thanks for the question.  I've also received a notification that you posted something about the reset process.


because i can't find the post that you made, the text of the notification was
Quote
The reset of the target board is necessary during the upload process.  When the chip comes out of reset, the booloader looks to the serial port to see if an upload is in progress.  If not, the boot loader runs the sketch that is already there.  If there is serial activity the boot loader loads the incoming sketch.  Since you are using an Uno as a FTDI there is no DTR signal to generate an auto reset so the reset must be done manually.
I think you're correct, of course.  However I'm using the Uno board and not the chip as a usb to serial programmer (it's not an FTDI in fact).  The usb-serial chip generates the reset pulse to the right pin, which is mapped by jumper wires to the pin on my board.  so I think that the reset pulse would be correctly received and dealt with (and when I'm monitoring the board over the serial connection the reset pulse does reset the chip). 

My working assumption is that I've somehow corrupted the chip. so I will try another board and see whether anything different occurs.

groundFungus

#6
Oct 31, 2017, 08:25 pm Last Edit: Oct 31, 2017, 08:32 pm by groundFungus
I removed the post after reading your post again and realised that the reset should be happening.  I know how you are using the Uno board.  You are, in fact, using the board like an FTDI.  Try something for me, please.  Connect the Uno board to your chip RX TO RX and TX to TX.  I remember that that is the connection when using the Uno board without the chip as a serial programmer.

jpadie

Hi groundFungus

that's exactly how i have the lines connected

thanks
Justin

groundFungus

Sorry, my eyes, for some reason, saw TX to RX where you actually had TX to TX.  Caffine must be wearing off.

aarg

If you have two 10k resistors in parallel in the reset circuit, it could be disturbing the timing because it's used in combination with a capacitor.
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

jpadie

why is that? 

there is no cap in the reset circuit that I'm aware of.  and even with two 10k resistors in parallel you've still got 5k of pull up.  which is more than enough to create stability in ordinary working mode. 

aarg

why is that? 

there is no cap in the reset circuit that I'm aware of.  and even with two 10k resistors in parallel you've still got 5k of pull up.  which is more than enough to create stability in ordinary working mode. 
The serial programmer uses a cap on the DSR line to reset the AVR. Does yours not have one?
  ... with a transistor and a large sum of money to spend ...
Please don't PM me with technical questions. Post them in the forum.

jpadie

I will have to check in the morning.  If the Uno r3 has a cap in parallel with the pull-ups i hadn't noticed.  In any event I can't see why it would create a problem with another resistor in parallel. The reason for the pull-up is to stop the pin from floating during normal running.  And evidence suggests that the board is working fine other than accepting UART programming. 

jpadie

you are correct that there is a 100nF cap in the mix.  but it is necessary for the reset pulse to be generated by the usb to serial converter. 

the presence of the two external pull up resistors in parallel should not affect the timing nor should they prevent the line being pulled low by the reset pulse.

more interesting is that this has reminded me of the debug wire interface and the ability to debug via spi (for which the cap would need to be removed).  that's worth looking at as an alternative solution. 

Go Up