atmega328pb optiboot

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey!

 

so i stepped upon an issue that Optiboot doesn't(?) support UART1, on atmega328pb or im just doing something wrong. 

This is the output of AS7, when trying to build while UART1 is defined.

(its custom board, i took xplained project stub as it uses same MCU)

Severity	Code	Description	Project	File	Line
Error		#error UART == 1, but no UART1 on device	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	47
Error		recipe for target 'baudcheck' failed	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\Makefile	519
Error		recipe for target 'xplained328pb' failed	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\Makefile.atmel	25
Error		'UCSR1A' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	49
Error		'UCSR1A' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	49
Error		'UCSR1A' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	49
Error		'UCSR1B' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	50
Error		'UCSR1C' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	51
Error		'UBRR1L' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	52
Error		'UDR1' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	53
Error		'UDR1' undeclared (first use in this function)	xplained328pb	C:\Users\Joni S\Desktop\optiboot-master\optiboot\AtmelStudio\pin_defs.h	53

 

Which did lead me to watterott/wattuino github**, supposedly i could use that one and make use of UART1 or atleast that is what i believe, but i did come across a error i can't understand.

 

C:\Users\Joni S\Desktop\wattuino-master\software\Optiboot>make BAUD_RATE=38400 UART=1 AVR_FREQ=16000000
The system cannot find the path specified.
The system cannot find the path specified.
ECHO is off.
-------- begin --------
avr-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

-f was unexpected at this time.
Makefile:298: recipe for target 'sizebefore' failed
make: *** [sizebefore] Error 255

**https://github.com/watterott/wat...

 

maybe someone could share a thought or two with me, so i know where to look next and hopefully get the bootloader in.

Last Edited: Sun. Feb 19, 2017 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
(its custom board, i took xplained project stub as it uses same MCU)
An alternate route is via Atmel START.

http://start.atmel.com/

 

on 'test -f'

Is MSYS installed?

https://www.gnu.org/software/coreutils/manual/html_node/File-type-tests.html#File-type-tests

http://mingw.org/

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
on 'test -f' Is MSYS installed? https://www.gnu.org/software/cor... http://mingw.org/

 

if i answer "i have no idea" i guess its not then? i did use the make.exe and other files from arduino ide installation to try compile it.

 

 

i tried build the wattuino optiboot from AS7 directly, same error as from command line.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An assumption is Optiboot can be rebuilt from within the Arduino IDE.

https://github.com/watterott/ATmega328PB-Testing

via

http://www.watterott.com/en/Wattuino-pro-mini-PB-5V-16MHz

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
i tried build the wattuino optiboot from AS7 directly, same error as from command line.
Should be able to build Optiboot in Atmel Studio 7 if all the pieces are in a Studio project.

Could import a Makefile; IIRC, Atmel Studio will convert from GNU make to Microsoft MSBuild.

Atmel Studio

Frequently Asked Questions

Atmel Studio Interface

How can I use an external makefile for my project?

http://www.atmel.com/webdoc/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD/index.html?GUID-91013923-6B97-4F3F-9D45-7D181066CBB6

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:
Should be able to build Optiboot in Atmel Studio 7 if all the pieces are in a Studio project.

 

This is what i was thinking too. i have the files which i think i need added in the project, this is from "xxxx.cproj" file 

<ItemGroup>
    <Compile Include="..\..\..\..\..\..\..\wattuino-master\software\Optiboot\boot.h">
      <SubType>compile</SubType>
      <Link>boot.h</Link>
    </Compile>
    <Compile Include="..\..\..\..\..\..\..\wattuino-master\software\Optiboot\optiboot.c">
      <SubType>compile</SubType>
      <Link>optiboot.c</Link>
    </Compile>
    <Compile Include="..\..\..\..\..\..\..\wattuino-master\software\Optiboot\pin_defs.h">
      <SubType>compile</SubType>
      <Link>pin_defs.h</Link>
    </Compile>
    <Compile Include="..\..\..\..\..\..\..\wattuino-master\software\Optiboot\stk500.h">
      <SubType>compile</SubType>
      <Link>stk500.h</Link>
    </Compile>
  </ItemGroup>

Uh, what the heck is that path actually......

 

and as build settings, which i believe should be correct or well atleast correct in sense that it should build with it.

 

E: no idea what happened, but restarting atmel studio seemed to do something, it builds now.

 

Last Edited: Sun. Feb 19, 2017 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An assumption is Optiboot can be rebuilt from within the Arduino IDE.

 No.  :-(  Optiboot is  all makefile based (sometimes "intensely" so), and the Arduino IDE doesn't even include "make" any more.

 

 

I'll take a look at the main branch; I think it only supports the PB in the sense of building a lying result that claims to be a -P (at the time, the Arduino compiler didn't support the PB, so there was little point in telling the truth...)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for I was not aware.

westfw wrote:
I think it only supports the PB ...
fyi, mega328PB is a recent addition to Platform_IO :

http://docs.platformio.org/en/latest/history.html#id3

3.2.0 (2016-12-07)

...

 

Development platform Atmel AVR

...

  • Added support for ATmega328PB MCUs

...

Platform_IO has an equivalent of make but am not certain that the bootloaders are in it; the only obvious bootloader there is Micronucleus.

http://docs.platformio.org/en/latest/platforms/atmelavr.html#packages

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
E: no idea what happened, but restarting atmel studio seemed to do something, it builds now.

 

it builds != it works. And there are way too many things that might be wrong, i dont really know where to start.

 

This is my fuse settings.

 

and build commands (im using makefile provided with watterott/wattuino github)

all BAUD_RATE=38400 UART=1

avrdude command burn program.(which can't connect at all -> avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x47).

-v -p m328p -c arduino -b 38400 -P COM5 -D -Uflash:w:"$(ProjectDir)Debug$(ItemFileName).hex":i -C E:\Arduino\hardware/tools/avr/etc/avrdude.conf

Or then it of course might be my hardware also which i'm testing at the moment.

E: hmmn, I'm actually missing resistor between RTS(ftdi) and reset(avr), which is something original Arduino design had in there, could it be the cause?

Last Edited: Mon. Feb 20, 2017 - 03:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
E: hmmn, I'm actually missing resistor between RTS(ftdi) and reset(avr), which is something original Arduino design had in there, could it be the cause?
DTR instead of RTS?

https://learn.sparkfun.com/tutorials/sparkfun-usb-uart-breakout-cy7c65213-hookup-guide#programming-an-arduino-pro-or-pro-mini

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

JoniS wrote:
E: hmmn, I'm actually missing resistor between RTS(ftdi) and reset(avr), which is something original Arduino design had in there, could it be the cause?
DTR instead of RTS?

https://learn.sparkfun.com/tutorials/sparkfun-usb-uart-breakout-cy7c65213-hookup-guide#programming-an-arduino-pro-or-pro-mini

 

I have actually only RTS wired, DTR is unconnected as I had impression avrdude would try both of these pins to reset the avr. Well it's fast to test if connecting DTR also will make a difference, guess I should try manually holding avr in reset state too while on that.

 

E: not even holding the reset manually will let avrdude connect, safe to assume there is something wrong my build .hex file?

 

E2: Actually found one thing wrong on the board, CTS was supposed to be the pin to reset AVR, not RTS which i have routed by accident, well not a big deal and easily fixed.

Last Edited: Mon. Feb 20, 2017 - 07:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well some progress made i guess, or step back i dont know.

 

I did delete all related to wattuino // optiboot from hardrive, got the official optiboot sources and started all over again with success in adding mega328pb and it also compiles with uart=1 defined,  avrdude can't still connect for uknown reason.

 

I'm pretty sure it must be software error still(==i don't compile it how i should) and why i believe so is that i can talk with the mcu via usb from terminal, holding reset manually low does not have effect.

 

E: also i did test that RTS(FTDI) -> RESET(AVR) should be viable, reset pin is pulled to 0,13v.

 

------ Rebuild All started: Project: optiboot-real, Configuration: Release AVR ------
Build started.
Project "optiboot-real.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "E:\ATMEL studio\7.0\Vs\Compiler.targets" from project "C:\Users\Joni S\Documents\Atmel Studio\7.0\optiboot-real\optiboot-real\optiboot-real.cproj" (target "Build" depends on it):
	Task "RunCompilerTask"
		Shell Utils Path E:\ATMEL studio\7.0\shellUtils
		E:\ATMEL studio\7.0\shellUtils\make.exe -C "C:\Users\Joni S\Documents\Atmel Studio\7.0\optiboot-real\optiboot-real" -f "Makefile" atmega328pb AVR_FREQ=16000000 BAUD_RATE=38400 UART=1
		make: Entering directory 'C:/Users/Joni S/Documents/Atmel Studio/7.0/optiboot-real/optiboot-real'
		avr-gcc (AVR_8_bit_GNU_Toolchain_3.5.4_1709) 4.9.2
		Copyright (C) 2014 Free Software Foundation, Inc.
		This is free software; see the source for copying conditions.  There is NO
		warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
		BAUD RATE CHECK: Desired: 38400, Real: 38461, UBRRL = 51, Error=0.1%
		avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328pb -DF_CPU=16000000  -DBAUD_RATE=38400 -DLED_START_FLASHES=3      -DUART=1   -c -o optiboot.o optiboot.c
		avr-gcc -g -Wall -Os -fno-split-wide-types -mrelax -mmcu=atmega328pb -DF_CPU=16000000  -DBAUD_RATE=38400 -DLED_START_FLASHES=3      -DUART=1 -Wl,--section-start=.text=0x7e00 -Wl,--section-start=.version=0x7ffe -Wl,--relax -nostartfiles -nostdlib -o optiboot_atmega328pb.elf optiboot.o -lc
		avr-size optiboot_atmega328pb.elf
		   text	   data	    bss	    dec	    hex	filename
		    464	      0	      0	    464	    1d0	optiboot_atmega328pb.elf
		avr-objcopy -j .text -j .data -j .version --set-section-flags .version=alloc,load -O ihex optiboot_atmega328pb.elf optiboot_atmega328pb.hex
		avr-objdump -h -S optiboot_atmega328pb.elf > optiboot_atmega328pb.lst
		rm optiboot.o optiboot_atmega328pb.elf
		make: Leaving directory 'C:/Users/Joni S/Documents/Atmel Studio/7.0/optiboot-real/optiboot-real'
	Done executing task "RunCompilerTask".
	Using "RunOutputFileVerifyTask" task from assembly "E:\ATMEL studio\7.0\Extensions\Application\AvrGCC.dll".
	Task "RunOutputFileVerifyTask"

		Display Output File Size Skipped due to : Output File not found
	Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "optiboot-real.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "E:\ATMEL studio\7.0\Vs\Avr.common.targets" from project "C:\Users\Joni S\Documents\Atmel Studio\7.0\optiboot-real\optiboot-real\optiboot-real.cproj" (entry point):
Done building target "Build" in project "optiboot-real.cproj".
Done building project "optiboot-real.cproj".

Build succeeded.
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

 

 

E: its working now, i did never think about it but the RTS was holding avr in reset state so it was not able to boot in the bootloader? oh well need to fix this on the next board.

 

Well hopefully i learned something with this journey, atleast i got optiboot with 328pb support now.

Last Edited: Tue. Feb 21, 2017 - 03:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well done!

JoniS wrote:
... need to fix this on the next board.
To continue, can fix it on the current board though from what you've stated the AVR is now booting.

It's very common to patch a prototype PCBA; accumulate patches until you want to re-spin the PCBA.

Ideally, one's patch process is complete (iow the schematic and PCB CAD are both updated)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Well done!

 

JoniS wrote:

... need to fix this on the next board.

 

To continue, can fix it on the current board though from what you've stated the AVR is now booting.

It's very common to patch a prototype PCBA; accumulate patches until you want to re-spin the PCBA.

Ideally, one's patch process is complete (iow the schematic and PCB CAD are both updated)

 

 

I did allready solder some jump wire on the avr end, still need to figure wether DTR/CTS is the better option for resetting into bootloader then fixing schematic, maybe I could wire both as original arduino did.

 

And next PCB will propably add some new stuff to fix since I wanted to add control for 2x addressable led stripes, and only real solution I could come up with is to add attiny mcu along side with the mega to drive those, since the driver code for leds is timing critical and needs interrupts disabled.

 

E: one thing I was left wondering was how the avr was not on reset state when I tested the software earlier, since it was providing rpm readings etc via USART flawless, but that might have something to do with avrdude enabling flow control? Since on the terminal software I used I did untick flow control, and can't really see any other difference.

Last Edited: Tue. Feb 21, 2017 - 06:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
... and only real solution I could come up with is to add attiny mcu along side with the mega to drive those, since the driver code for leds is timing critical and needs interrupts disabled.
A programmable interrupt controller will allow one set of interrupts to exist with or without another set of interrupts.

Such is on tinyX AVR and XMEGA AVR but tinyX won't have the I/O of mega328PB and XMEGA are a different sub-architecture from mega328PB.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
... since I wanted to add control for 2x addressable led stripes, and only real solution I could come up with is to add attiny mcu along side with the mega to drive those, ...
There are LED drivers that implement such in hardware instead of software; commonly used to drive LED lights on automobiles.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

JoniS wrote:
... since I wanted to add control for 2x addressable led stripes, and only real solution I could come up with is to add attiny mcu along side with the mega to drive those, ...
There are LED drivers that implement such in hardware instead of software; commonly used to drive LED lights on automobiles.

 

i decided to take the route of adding tiny to assist the mega, because of following reason.

  • Full control over the led stripes(ws2812b), only imagination as limitation.
  • i got "expander" header on the PCB, HW uart // 4 ADC from tiny
  • can now connect temperature sensors for standalone operation via tiny.
  • its not going to be mass produced, so if its not most cost effective solution it does not matter.

 

Hopefully i got everything right this time :)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking good!

JoniS wrote:
... only imagination as limitation.
Then there is no limit.

JoniS wrote:
its not going to be mass produced, ...
It's a solution to one of your problems, one will see your solution as a solution to one of their problems, and so forth and so on.

If you find it reasonable to assemble yourself then it might be acceptable for low-rate production.

JoniS wrote:
Hopefully i got everything right this time :)
Yeah, "right" wink

Kaizen

https://www.kaizen.com/about-us/definition-of-kaizen.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did some searching today related using "RTS" as autoreset, it should work even according to avrdude source file comments.

 

From "Arduino.c"

83	static int arduino_open(PROGRAMMER * pgm, char * port)
84	{
85	  union pinfo pinfo;
86	  strcpy(pgm->port, port);
87	  pinfo.baud = pgm->baudrate? pgm->baudrate: 115200;
88	  if (serial_open(port, pinfo, &pgm->fd)==-1) {
89	    return -1;
90	  }
91
92	  /* Clear DTR and RTS to unload the RESET capacitor
93	   * (for example in Arduino) */
94	  serial_set_dtr_rts(&pgm->fd, 0);
95	  usleep(250*1000);
96	  /* Set DTR and RTS back to high */
97	  serial_set_dtr_rts(&pgm->fd, 1);
98	  usleep(50*1000);
99
100	  /*
101	   * drain any extraneous input
102	   */
103	  stk500_drain(pgm, 0);
104
105	  if (stk500_getsync(pgm) < 0)
106	    return -1;
107
108	  return 0;
109	}

Only proplem is that it does indeed pull "RTS" low on that point, but its never pulled high again, it must be a bug?(or am i missing something here).

 

E: i tried with all 6.xx versions i can find pre-compiled.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
it must be a bug?
In AVRDUDE, driver for the USB bridge, or usbser.sys?

Microsoft logo

Microsoft Windows USB Core Team Blog

What is new with Serial in Windows 10

by George Roussos [MSFT]

July 29, 2015

https://blogs.msdn.microsoft.com/usbcoreblog/2015/07/29/what-is-new-with-serial-in-windows-10/

...

 

1.   Improved Serial over USB driver support in Windows 10

...

In Windows 10, we added inbox support for USB CDC Abstract Control Model (ACM) compliant hardware.

Usbser.sys is now installed as a compatible ID match for USB CDC compliant hardware, without requiring a 3rd party driver or inclusion via modem INFs.

...

… including popular prototyping boards like Arduinos – just work with our built-in driver.  

...

 

2.   A Windows Runtime API for communication with Serial devices

...

Peripherally connected USB to RS-232 Adapters

...

Each UART discrete (iow DTR, RTS, etc) can be toggled via the serial API.

Instead of testing UART discretes using AVRDUDE could go direct via the serial API.

JoniS wrote:
(or am i missing something here)
I'm missing something for I didn't know that part of AVRDUDE.

Thanks!

 


Microsoft

Microsoft

USB serial driver (Usbser.sys) (Windows Drivers)

https://msdn.microsoft.com/en-us/library/windows/hardware/dn707976

 

Edit : MSDN

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Feb 24, 2017 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
In AVRDUDE, driver for the USB bridge, or usbser.sys?

 

Well, this one is harder and i have to say i have no clue.

 

enabling flow control would cause RTS to be active LOW, i tested this with terminal software and its in line with datasheet, but why would AVRdude enable it // not do anything to prevent enabling it is uknown to me, since it would straight up destroy compability with original design arduinos, which did wire both DTR and RTS to reset if i was looking at legit schematic.

 

E: FTDI driver// .inf file is loaded to the device.

 

E: hmmn, i wrote a really simple test program in C# to test RTS behaviour, it can be pulsed and its not doing anything silly.

 SerialPort AVR = new SerialPort("COM12", 38700, Parity.None, 8, StopBits.One);

        public MainWindow() {
            InitializeComponent();
        }

        private void BTN_connect(object sender, RoutedEventArgs e){

            AVR.Open();
            if (AVR.IsOpen) {
                AVR.RtsEnable = true;
                Thread.Sleep(1000);
                AVR.RtsEnable = false;
            }
        }

Now for the real proplem, how do i make this in AVRDUDE and compile it again.

 

Last Edited: Sat. Feb 25, 2017 - 07:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally got it working completely, send fixed PCB to production.

 

It seems the inline cap is needed with RTS too, even thought I did find many claims it's only needed with DTR..sadly that cap means I can't use debugwire I believe, well have to live with manual reset when writing the avr code it seems.

Or other option would be to modify avrdude, making RTS pulse slower, and actually pull the signal back high then no cap was needed.

 

Inline cap in the RTS track also fixes other issue I did come across, behaviour of RTS pin seems to be undefined at best when another USB device is attached to the same root hub, meaning it might spike low performing reset that was not wanted, or it could play nice and stay high.

 

E: got reminder how important it is to re-check everything, two errors were found I have made when drawing everything to kicad from eagle, another would have damaged fet in long run, which it would have never gotten since avr was dead instant if apply power.

 

Last Edited: Mon. Feb 27, 2017 - 04:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes.  The cap is needed on the AVR side to turn the modem control signal into a momentary pulse, so you need it regardless of which signal you use.  RTS is subject to being interpreted as part of "hardware flow control", which means that it could fluctuate during normal operation, so DTR is preferred.  (The cleverness of the autoreset function WAS that it happened automatically as a part of the serial port open operation; I think avrdude then got "smarter" about not fiddling with the signals, so special code had to be added to make it continue doing so (on some operating systems?)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Ah yes.  The cap is needed on the AVR side to turn the modem control signal into a momentary pulse, so you need it regardless of which signal you use.  RTS is subject to being interpreted as part of "hardware flow control", which means that it could fluctuate during normal operation, so DTR is preferred.  (The cleverness of the autoreset function WAS that it happened automatically as a part of the serial port open operation; I think avrdude then got "smarter" about not fiddling with the signals, so special code had to be added to make it continue doing so (on some operating systems?)

 

Yes, that DTR "trick" is clever one.

On this project reset when opening comport is not wanted, which did lead me to look for alternative ways, using RTS was one I found, and that is something ft230xs usb-uart ic offers to me, there is no DTR signal pin to begin with.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

new PCB new proplems? Yes.

 

Only that this time I know my optiboot is working for sure, USB comms working aswell, if avr is clean IE. Only optiboot flashed and no application I can successfully flash via avrdude ONCE.

 

Second attempt seems almost like if avrdude hangs(?) There is no output on the terminal window after the usual port, baud...stuff. no error no nothing and it seems like the avr is not resetted at all, since if I manual reset avrdude will instant flash the hex file.

Only difference compared to last PCB is that I now have ft230x instead of the big brother ft232rl, also there 1k resistors in Rx/TX lines because those are shared with ISP. Anyone have ideas?

 

E: what I have figured this far is that, the resistors in Rx/TX most likely don't cause it since the communication is working other than the flashing.

 

Ft230x uses 3.3v logic instead of 5.0v, but would this cause the issue? I can see that wattuino uno uses same connection as I, but DTR pin instead of RTS since it uses ft231x. So basically I would think that the drop to 3.3v logic can't be a proplem if same is used in commercial product.

Last Edited: Wed. Mar 8, 2017 - 05:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can successfully flash via avrdude ONCE.  ...  Second attempt seems almost like if avrdude hangs

Failure to load the second sketch usually means you have not properly set (zeroed) the BOOTRST fuse.  The first time, the AVR resets and starts at location 0, where there are a bunch of 0xFFFF in the (erased) flash. 0xFFFF turns out to be almost a no-op, so the AVR quickly runs through nearly 32k of them and gets to the beginning of the bootloader, which then runs and loads your sketch.   The SECOND time, your sketch is loaded at location 0, so it just runs instead of the bootloader.   The BOOTRST fuse causes execution to begin at the start of the bootloader instead of 0.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks westfw, I will check that first when get back to the project. Would this also cause the avrdude to "hang", IE. No output to terminal window at all, after the com, baud and ISP type it first outputs?

 

E: appereantly someone have had very similar issue, which is also only hit I can find, where avrdude don't actually output any errors or anything, but just "hangs" 

https://www.avrfreaks.net/forum/x...

 

Soon home and able to start testing different solutions.

Last Edited: Wed. Mar 8, 2017 - 12:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BOOTRST fuse was like it should be(just incase i also tried it unprogrammed/programmed no luck), seems like i'm almost back in where i was with the first PCB.

 

This is from where i did start today, AVRDUDE makes total freeze if my program is transmitting via usart. (disabling the transmit to see that AVRDUDE does not hang anymore is fine, but not a real solution for sure)

avrdude.exe: Version 6.3, compiled on Feb 17 2016 at 09:25:53
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2014 Joerg Wunsch

             System wide configuration file is "F:\avrdude\avrdude.conf"

             Using Port                    : COM1
             Using Programmer              : arduino
             Overriding Baud Rate          : 38400

(it just sits there without giving any output, i did let it be there for like 10minutes without anything happening)

 

what else i tried:

  • delete all memorized comports from windows, to not get like comport 20.
  • different size caps inline with the reset (100-470nF)
  • re-flash the bootloader in multiple times (always able to flash the first program after this)
  • different lock fuses and without them at all.

 

 

i'm pretty much starting to be out of ideas sadly :/

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
i'm pretty much starting to be out of ideas sadly
Buy an Atmel-ICE. You will probably resolve this in about 5 minutes with one of those.

 

I guess I'm odd (well yes!) but I couldn't envisage developing something like a bootloader without access to an ICE. I even pick chips for solutions because they are ICE-able and discount ones that are not.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

JoniS wrote:
i'm pretty much starting to be out of ideas sadly
Buy an Atmel-ICE. You will probably resolve this in about 5 minutes with one of those.

 

I guess I'm odd (well yes!) but I couldn't envisage developing something like a bootloader without access to an ICE. I even pick chips for solutions because they are ICE-able and discount ones that are not.

 

I have atmel ice actually.

 

the bootloader part should be working, since it lets me flash once via avrdude when the avr is empty. Also it did work flawless on my proto PCB after i sorted the initial proplems.

 

What i want to look for particularry when i launch debug session, if that is what you are suggesting.

Last Edited: Wed. Mar 8, 2017 - 03:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With an ICE the entire internal operation of the bootloader from the very first opcode fetch at the BOOTRST point and on into every other last thing it does is "open" to you so surely it's just a matter of comparing what you expect with what you observe while debugging the code to determine why it's not behaving as you expected?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hardware fault again.....attaching ice to the PCB while avrdude is in stuck mode starts the program upload, why it happens, hope that google tells that to me, maybe the ice forces reset when it's attached?

 

Might be that the ftdi230x with 3.3v logic can't reset the avr after all, which lefts me wondering how is it working in the wattuino board?!?

 

And as an bonus I killed my keyboard once again with the ft_prog software, since I forgot to unplug it -.-

 

Damn it's hard to get the avr in debug mode when there is capasitor in reset line, was not able to step in the boot section if it's even possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
Damn it's hard to get the avr in debug mode when there is capasitor in reset line, ...

http://www.atmel.com/products/microcontrollers/avr/megaavr.aspx?tab=documents

ATmega328PB Complete
(file size: 5.53MB, 425 pages, revision C, updated: 10/2015)

http://www.atmel.com/Images/Atmel-42397-8-bit-AVR-Microcontroller-ATmega328PB_Datasheet.pdf

(bottom of page 337)

When designing a system where debugWIRE will be used, the following observations must be made for correct operation:

  • Pull-up resistors on the dW/(RESET) line must not be smaller than 10kW. The pull-up resistor is not required for debugWIRE functionality
  • Connecting the RESET pin directly to VCC will not work.
  • Capacitors connected to the RESET pin must be disconnected when using debugWire.
  • All external reset sources must be disconnected.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. Mar 8, 2017 - 09:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My connections are identical with same value components to the wattuino uno, only real difference is the RTS instead of DTR because ft230x does not have DTR,neither do I want autoreset when comport is opened, but that did work nicely with the ft232rl chip, so that should not be an issue.

Yeah I did notice the atmel Ice manual telling me to disconnect the caps for debugwire, that is actually one reason I did not want series capasitor with reset line in the first place, but had allready forgotten it.

Last Edited: Wed. Mar 8, 2017 - 09:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
Ft230x uses 3.3v logic instead of 5.0v, but would this cause the issue?
It's close.

mega328PB threshold for logic 1 is 5.0V * 0.6 = 3.0V < 3.3V

mega328PB threshold for logic 1 on RESET pin is 5.0V * 0.9 = 4.5V

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JoniS wrote:
And as an bonus I killed my keyboard once again with the ft_prog software, since I forgot to unplug it -.-
A possible work-around is an inexpensive USB HID keyboard.

 

FT230X drive strength is configurable via ft_prog but FT230X datasheet does not state the default drive strength.

If abandon ft_prog and therefore FT230X then could turn to mega8U2 or mega16U2 as the USB bridge to UART.

mega8U2 and mega16U2 are configurable via Atmel-ICE or USB DFU (AVRDUDE 6.3) and have more than sufficient source and sink current.

The USB megaAVR's USB bridge could be Dean's LUFA or Arduino's.

USB megaAVR is powered from mega328PB Vcc.

 

If don't want to abandon FT230X :

FT230X can't level convert to 5V from 3.3V.

Add level converters to TXD, RXD, and RTS (mega328PB RESET)

Power FT230X from USB VBUS via its internal LDO.

When USB VBUS drops the level converters will go high impedance therefore freeing mega328PB RESET for debugWIRE.

JoniS wrote:
Damn it's hard to get the avr in debug mode when there is capasitor in reset line, ...
RC of 10K and 100nF is long; mega328PB RESET needs only a 2.5micro-second pulse.

Decrease 100nF to 1nF then debugWIRE might work if its "clock" is set "low" enough (IIRC there's an Atmel Studio screen to set debugWIRE speed)

Scope RESET, toggle RTS, and evaluate it's slew; it might be too slow to rise to the 4.5V threshold.

 

Edit : USB DFU

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Mar 9, 2017 - 04:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
It's close. mega328PB threshold for logic 1 is 5.0V * 0.6 = 3.0V < 3.3V mega328PB threshold for logic 1 on RESET pin is 5.0V * 0.9 = 4.5V  

 

Yes it seems to be "super close", I think I need to go back to very basics of electronics to solve this, it seems that weaker pullup for reset(20k instead of 10k) + ice attached to the PCB let's avrdude successfully reset the avr thus leading to succesful burn the program, with 10k pullup there needed to be attach event of ice during avrdude running to successfully reset the avr, so the weaker pullup did something. Maybe I try even more weak pullup when get back to it.

gchapman wrote:
If abandon ft_prog and therefore FT230X then

I'm starting to really think about this, the thing is that ft230x was propably most cheap/easy solution, small footprint compined to the fact that it does not need external clock and it can feed 12mhz for the tiny same time, hard to beat that all or im looking at wrong component selection.

 

E: anyway one way or other I'm going to solve this, since I don't like giving up.

E2: and yes I have changed the drive strength of pins to 16mA which is maximium, also did adjust the ftdi to ask more power from USB.

Last Edited: Thu. Mar 9, 2017 - 05:19 AM