AVR Freaks

I put an atmega88 I had lying around on a breadboard and built El Tangas' jtag2updi code for it, and flashed that code, and made use of his avrdude.conf file in order to use avrdude from linux to flash the atmega4809.

This results in a working atmega4809 in both my clamshell and breadboarded breakout, which can not only accept the flashed code but actually run it. I can see with my simple psg.hex file (originally posted) the intended CLKOUT on pin 3 (PA7) of the 4809 at 3.3Mhz, and see also the simple pin toggle on any of the PORTB pins, as intended . . .

. . . leaving open the mystery of why the STK600 cannot flash the atmega4809 in a way that results in a running program. Hmm. If I use avrdude to read the flash as produced by STK600 and compare that with flash as produced by my atmega88-el tangas' jtag2updi (still read by avrdude etc), I see that the memories appear to be different. The memory as produced by avrdude but that was written by STK600 starts with all FFs and ends with the intended code present but offset wrt to the working case by 0x4000 bytes (so at 0x204000 rather than 0x200000 in the working case). The memory as produced by avrdude that was written by avrdude and the atmega88-el tangas jtag2updi starts right away with the intended code at 0x200000 (the vector table, followed by the text). There is also a difference in hex file addresses; the avrdude ones start at 0x200000 and in the working case the code is there, but in the non-working one written by STK600, the hex file is addressed starting at 0x100000. Of course, the flash appears in the data space at offset 0x4000 for this chip; perhaps that is the source of this weirdness. This is weird enough that I am a little hesitant to be sure, but the problem may simply be that STK600 or its conf files do not have proper addressing information for the chip (a little temporary playing around in those Atmel config files did not yield a working flashing from STK600; it might be good for me to report this to Atmel and see what they think (and whether they can flash their own chip with STK600)).

Ok, submitted case 00307099 to Microchip, with subject "AS7 + STK600 cannot yield running ATMEGA4809". (I accidentally left the "include ..tpc.h.. in there, but hopefully they will figure out they don't need that.) We will see what they say.

My text:

Atmel Studio 7 in conjunction with STK600 cannot yield a running ATMEGA4809, in my experience and that of at least a couple of others on avrfreaks.net.  I used gcc to compile the program (5.4.0 or 8.1.0).

One can apparently flash the 4809, and read back the content of the flash, but the program does not run (where the program is a simple "blinky"-type example setting direction for PORTB, disabling alternate use of PORTB pins, and toggling all PORTB lines).

Subsequent testing with the same code using avrdude plus an avrdude backend setup from avrfreaks.net user "El Tangas" that allows programming through UPDI reveals that the AS7 + STK600 pair apparently flashes at the wrong address, flashing the program text offset +0x4000 too far into the flash, leaving 0xFFs at the beginning of flash, which of course will not work. (The AS7 tool nonetheless reports the flash content as starting with the program text).

So using avrdude plus an appropriate backend yields a working 4809, with the program text flashed in the proper place within flash, and reveals also that AS7 + STK600 places that same code incorrectly within the flash. Also, avrfreaks.net users reported that programming the board using the Xplained Pro setup for 4809 works as well (i.e., as well as the avrdude + "El Tangas" backend solution).

*

Question: Please, would you folks try using AS7 + STK600 to yield a running 4809 with the attached simple program? If your results mirror ours on avrfreaks.net (at least in my thread there), AS7 + STK600 will not work; the code will appear to be in flash at the right address, but the chip will not run (because AS7 + STK600 flashed it at the wrong address). If you use the xplained pro board (or the avrdude...etc soln) it will work. This represents in my view a fairly bad problem for this AVR and AS7/STK600 as presumably those are the premier tools to use with this chip.

_____

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

Simple code to use with AS7 + STK600 + ATMEGA4809:

#include "tpc.h"

#include <avr/io.h>

#include "util/delay.h"

#include "util/atomic.h"

int

main(void)

{

  PORTMUX.USARTROUTEA = 0xff; // try and disable USARTs in favor of GPIO.     

  PORTMUX.TCAROUTEA = 0x2;

  PORTB.OUT = 0;

  PORTB.DIR = 0xff;

  CCP = 0xd8;

  CLKCTRL.MCLKCTRLA = 0x80; // see if can get clock out                       

  while (1) {

    PORTB.OUTTGL = 0xff;

    _delay_us(200);

  }

  return 0;

}

Thank you for sharing your wisdom, clawson! I myself have found the STK600, well, not in such a different class than the STK500. I used the STK500 for years, and it was fine, though I found the lack of ZIF sockets annoying hence I laid out and had fabbed a ZIF daughterboard for it to plug into the EXPAND{0,1} headers. Thereafter I used the ISP programming so I didn't need sockets of any sort independent of my circuits, which is what I largely do with the STK600. I generally do not want to buy a dedicated board for every chip I want to use, hence, I like general programming interfaces (e.g., for ARM I have a SEGGER J-LINK Pro). Maybe one can use the xplained board as a programmer, don't know.

My guess here is the problem is not with STK600 but rather with AS7, though hmm, I am trying to remember if, maybe it was js, used AS7 as front end software to load the 4809 yielding a successful running 4809. If yes, then yeah, presumably a problem with STK600. As I mentioned, to me it looked like (when I read the working 4809 with avrdude plus my mega88 programmed with El Tangas jtag2updi firmware) the AS7 + STK600 flashed the program too far down in the flash.

Thanks, pgillard. Atmel gave me a phone number to call for my submitted case; perhaps they will tell me they reproduced the problem, as they apparently told you. I think it may be a simple case of the AS7 + STK600 programming the program text too far down into the flash address space, as I mentioned above. As I explained, my own personal tastes are not to buy a development board for every chip I want to use in a design, so I personally have good reasons for using (years ago) the STK500 and now the STK600. I do not have the xplained board so I do not know if it can program one's own 4809 in-circuit. I would doubt it can, but I don't know.

Thanks, js. I suspected lifting the UPDI pin on that xplained board would be one way. I have fair soldering skills (enough to solder the 4809 into a breakout) but it can be a little finicky. What I really dislike is the move to QFN because I so far can't solder those at all, and my gf's toaster oven is already in use (being a toaster). The QFN form factor is pretty irritating for a hobbyist in my view, making chips like the FTDI EVE pretty unusable for me. Not that chip manufacturers likely have much reason to care about hobbyists (except that we work at places for which hobby experience could be relevant). As far as 4809, at the moment I have the ATMEGA88 running El Tangas' code, and hopefully Atmel can get the STK600 working to allow my normal workflow. The Atmel ICE could be good for doing debugging . . . As far as ARM I have the SEGGER but it has been a little while since I powered it up so I don't know how well it has tracked with the times.