Unlike the many other AVR and ARM processors I have used, I have been unable to get atmega4809 to work after 10 hours of trying, now with a simple pared-down program that simply toggles a PORTB pin as a test. The symptoms are that I can read the chip 3 byte signature just fine (0x1e9651), and can program, verify, and even read back from flash my object code with Amel Studio 7, but when run, the chip produces nothing on the i/o pins at all. I have tried everything I can think of to debug this given the non-ICE hardware I have.

Can you help? Help might take one of these three forms, among, perhaps, others:

1. Spot a mistake.
2. Recommend any ideas for further debugging.
3. Try my simple example code on your atmega4809 setup, or some variant of that code.

I have the code running on a board I made that allows general qfp48 chips to be installed in my clamshell socket (pictured, below) with then access to all 48 pins in a simple form factor (patch bay for all pins). All I have hooked up to the 4809 is the 5 or 6 power supply pins, the updi pin to allow programming via atmel studio 7 and stk600, and my oscilloscope on the output pin(s). Other than these 6 or 7 connections, all other 4809 pins are not connected hence are floating. When I program it, the chip just sits there after programming exhibiting no output, and if I disconnect the stk600 ISP connections (really just the updi pin), and power cycle, the chip still produces no output. I am powering with an agilent supply supplying 3v3, thus, power external to the stk600. I have checked the power, and in any case, as I said I can successfully program the flash and read it back, only, my code produces no output.

As far as program code (psg.c, below), I have only the crt (C runtime) for the 4809, some code to desperately ensure that the port is active and not occupied by a USART, to set the direction and initial output, (to get the clk output from the prescalar on an output pin, too) and then to loop and toggle the output pin (at high speed with no delay desperately to ensure the delay code isn't somehow malfunctioning and to avoid introducing complication on the simplest possible code - so one has to look with a scope really to see the toggling output pin, if it would ever toggle).

I have objdumped (psg_elf_objdump.txt, below) the elf file corresponding to the hex file (psg.hex, below) I pushed to the 4809, and I have used atmel studio 7 to read the flash and thus ensure the machine code I read back matches the obdumped vector table and program text for 4809 crt and my main shown in my objdump. I have tried variants of my code, e.g. to use .OUT rather than .OUTTGL. I have tried hooking up oscillators, using an external reset pin after power up, carefully checking fuses and trying different things there, and more. I have verified the peripheral module addresses and other parts of the assembly code match what I expect for 4809.

I also added to the code, as I said, an attempt to output the clock output of the prescaler on one of the pins to avoid relying solely on PORTx setup or weirdness of alternate pin function messing me up (and the clock doesn't show up on that port F pin, so still no output of any kind).

As far as things that still might be wrong, thinking creatively, chip is defective (but I tried another I bought too), internal oscillator isn't starting, but as I understand it simply starts from POR at 20 mhz/6 = 3.33 mhz, so s/b OK at 3v3, chip inundated with interrupts hence code stopped in tracks (but none should be enabled). Perhaps I have a simple mistake somewhere but I don't see it.

I would welcome any recommendations for anything else to try, or anyone else who would push my small binary (or similar code of their own devising) to their atmega4809 to see if it works for them.

I have other questions and oddities I have noted about this new chip, but that is unnecessary complication right now in this plea for help.

It is indeed inside the ZIF socket. That is why I made that board, so I could easily play with various (AVR and not-AVR) chips without having to solder them (i.e. use a chip just to get to testing it) or buy a board to test with. Have you had any luck with the Xplained 4809 board? Get any output from the 4809 chip? What's your test code look like, if so? How hard to whip up a simple test led code like I posted here? Thank you for your reply!

The tpc.h file is unimportant, and the other .h files are standard, hmm, and also unnecessary to that small test.

I had the same problem, with virtually the same code. Code that would work on the Xplained board would not work when programmed with the SDK600. The SDK600 would program the ATTiny devices (1616, etc.) fine, and the code seemed to load fine in the 4809, but would not run afterwards. I tried a similar clamshell, and a also soldered a 4809 on a breakout board, but no luck. Yesterday I loaded the code by ElTangas on an arduino, and successfully loaded the code on both the processors in the clamshell and on the breakoutboard.

My guess is that when the code is loaded by the SDK600 it actually is stored in the flash, (verifying the flash is successful) but the 4809 is left in a state from which the program can't run. (No idea what that is yet).

I should add that I really appreciate ElTangas for making his code available. Wish I had tried it earlier, didn't expect the problem to be with the SDK600.

Yeah, I checked very carefully over the assembly for my small test and it matched the 4809 peripheral address map, so I didn't see any trouble there. Aside from the handful of instructions for the crt, which just sets up the stack pointer really, there's not a lot to my test. I can look to check if the vector table really has that layout . . .

I'd be very interested in any small test that people have that produces any output or hint of runtime life (beyond what I already verified, that I *can* flash the chip and read back my material, and the signature matches what it should for 4809). A simple LED toggle would be all that is needed. I had hoped that the instructions to place the clock prescalar output on one of the port F ports would allow me to get a fuzzy past relying on the PORTx setup . . .

@pgillard, that is interesting. Hmm, not sure what to do with that information. I do AVR rather than arduino, i.e., did AVR before there was such a thing as arduino and I like to make my own circuits rather than buy a board for each project . . .

What was it that you loaded on your breakout and clamshell? Maybe the STK600 leaves something weird, as you say. It'd be interesting to check out the fuse state after a working example and compare it to what I have.

I am wondering too if there is some weirdness with bootloader vs. non-.

I used Atmel Start to configure the board with one pin set as output (PB5), default everything else, but enabled the CLKOUT as well. Then added a line of code to toggle PB5, and added a delay using the _delay_ms function - very simple example. I used PB5 because it is connected to the led on the Xplained Pro board. I too don't use use Arduino generally, but had a pro mini board on hand that I could reprogram. The code by ElTangas is not really Arduino code either; it should run easily on any ATMega328p.

The SDK600 seemed to read and write the fuses correctly. I recall changing the clock from 20 to 16MHz and it persisted over several power cycles.

Thank you js, will try that USART test. At what frequency should I run my 4809? If it is anything but the standard internal 20 mhz, what frequency does the program set up to run, and what clock source will I need to match the setup?

I guess the clock source can't be EXTCLK, because PA0 is EXTCLK :)

Oh, and, you loaded that with Atmel Studio? With an STK600, like I am doing, or something else?

Don't worry about anything, just run the hex file, it's all set up with the default clock of 20MHz and the divide by 6 or 3.3333 MHz, once I get my head around other things I'll get a faster clock running.

I have the Xplained board and it has it's own loader/debugger but any programmer that supports the chip should work.

@pgillard, that is interesting. Hmm, not sure what to do with that information. I do AVR rather than arduino, i.e., did AVR before there was such a thing as arduino and I like to make my own circuits rather than buy a board for each project . . .

What was it that you loaded on your breakout and clamshell? Maybe the STK600 leaves something weird, as you say. It'd be interesting to check out the fuse state after a working example and compare it to what I have.

I am wondering too if there is some weirdness with bootloader vs. non-.

If I read correctly, I think #8 is saying he used Ardunio merely as a programmer, (running pgmr code by ElTangas ) to replace the suspect STK600 ?

(I was worried in my talk of frq about getting the baud rate right for 19.2k, but probably close enough anyway).

Anyway, ah! That does get some output; I can see with my scope that pin 44 is getting some output that looks like serial (but I have not found my serial cable to hook it up an view the serial output). So hmm, what is the difference between my program and yours? Do you do anything different when you set up the 4809 that I posted originally?

Yep, re TTL to RS232 - I have a couple solns for that. Good point on decoupling; I could put some caps on the white strip that is my power rails in that picture, but I do not think that is my problem (as I now see some output with your .hex file, as I mentioned). Hmm, now to verify I am seeing good serial, and hopefully to learn what you are doing that I am not doing!

hmm, if that is so, then no clamshell adapter will work reliably :) As I said, I am seeing output, so that particular part is likely not my problem. Still wondering what you did to make this work, and hmm, are you able to enable the clk output on PA7 and toggle pins like I did?

actually, I would do best to put decoupling caps on the black pieces, which are around an inch from the pins. As you say, even that might be suspect. But then as I said, no clamshell solution would ever work reliably if that won't. A bit off the path of my main inquiry here.

hmm, seeing serial output from the device for about 15-20 seconds, js, is that what your program does? As yet it is almost all a single uniform chararacter, like a shaded box, so must have a setting wrong somewhere. Still wondering what you are doing in your chip setup or build that is different than mine.

As I read your assembly, you OR in just the bit you want rather than setting the whole byte, on the MCLKCTRLA. I just set it to 0x80 for my small test, rather than doing the OR, because in my case I know that value 00 binary in the two right hand bits sets (the default of) OSC20M. Hmm. Still not seeing recognizable serial, but it is heartening to see something. Re soldering - that would entirely defeat the purpose of the clamshell, as I can put in any chip. As to whether an inch away from the pins makes much difference as to decoupling, that is beyond my electronics ability to determine; perhaps you are more advanced at analog than I am.

Would you be willing to show me your initial setup code? Maybe I can figure out why mine doesn't work. I can try the OR like you do just in case there are undocumented bits in MCLKCTRLA . . .

That's the only clock set up I do is to output the clock as you are trying to do, otherwise I was working with default settings (3.333MHz) , no setup.

I have partially sorted out the other problem I was having with a switch and LED, this hex file toggles a LED on PORTB bit 5 (anode to VCC via resistor) and prints the bottom string if the switch on PORTB bit 2 (to GND) is pressed (LED stops for as long as the button is pressed).

Those bits are used on the board I have.

You would be surprised with the disasters that can occur with no or badly positioned by pass caps.

Will have to check that out, thank you. As I do not have the board you have I will have to simulate button presses and such. Still unlucky as to seeing valid serial with this app, but that's pretty likely some problem on my end. I do not see the clock coming out on pin 3 - do you see it? CLKOUT bit should cause it to emerge, at 3.3 mhz.

Seeing output at all is a small step in the right direction. But I am still left with no success figuring out why my chip is completely silent with the test I posted. Hmm.

I'd love to hear from others, too, on success with non-arduino, non-xplained setups with 4809. Would be interested if someone'd try a test like I posted originally.

Hmm, so your psg.exe does not work on my setup. Nothing on pin 3 (PA7) and nothing on portb. would be interested to know when you get the time if my .hex file works on your setup, if you are game to try it. My hex and yours are a touch different, but a little tough to tell looking just at the machine code in hex just how.

At any rate, so far this supports the earlier person's post musing about, things work on the xplained board but not others. And possibly, work when flashed with something else than STK600. I missed it, what did you build and flash this code with?

Yeah, saw that schematic before, hmm. "Has its own debugger/programmer" <- that may be important. Hmm, great that with my hex file you can see the clk on PA7. Re portb high, that is unexpected - it is toggling at high speed; do you have the ability to see it with a scope? Is it toggling?

I am following up on the hackaday post there - maybe avrdude can flash a working thing.

And thank you! especially (head smack) oh! decoupling caps! So that's what you were saying :)

Ok, well, pursuing avrdude on linux with this 4809 part is proving to be difficult for me.

Hmm. Atmel (MC) of course has the STK600-QFP48 socket board (which I do not have); surely they have used that plus AS7 to program their own chips? That's not all that much different than what I am doing.

So we appear to have js with the ability to use my hex file on his 4809 setup and it works fine programmed with and running on the xplained programmer/board, but it will not work fine with stk600/my own (and perhaps one's own) board (can be programmed but will not run). Which brings me back to the earliest posts in this thread, still unsolved for me, with thanks to js.

I probably didn't give westfw's post enough visible consideration. My syscfg0 fuses are apparently set to do "no CRC", as my two msbs (via syscfg0 value 0xeX) are 11, so the concern should not apply. At one point in posts above I had syscfg0 0xe5, but I changed it back to what I had before. Weirdly, the "reset" value of syscfg0 fuse in the doc is 0xc4, where the right hand nibble '4' (0100b) doesn't appear in the bit description for this register (and nor does the 10b bit of 0xe). Could be RSTPINCFG is actually two bits, as implied in the Atmel-ICE guide around UPDI. This fuse register was one of the other "oddities" I mentioned in the OP but didn't want to get into. I originally had a drop-down that showed 3 values in AS7: GPIO, RST, and UPDI; now my drop down for that fuse field shows only GPIO and RESET, where one results in overall byte value 0xe4 and the other has value 0xec. I have played with the 12v programming for stk600 around the UPDI pin (after my initial troubles). The '4' part of that 0xe4 former value implies I have a constant bit set of the 1 in 100, which bit is not described by the user guide or its errata (as I said a couple sentences above). I have tried setting the fuses for syscfg0 to various values (after my initial troubles, not before them), but I am not understanding well there. I'd be interested in knowing what others have for the syscfg0 fuse value, along whether their runtime setup works or doesn't.

Thank you. Yes, I could fix that assembly. I didn't pursue it yet because the difference between 4 instructions and what I had was not large, so didn't pursue that yet. I think it is not my code, since that code works for js on his 4809 setup.

At this point there isn't much more I can do, perhaps when the new avrdude comes out I can try that.

I should have researched when I bought these 4809s that they are very new and support from various quarters is likely shaky (e.g., avrdude, and had to cobble together support in gcc for linux).

Thank you, js! I tried ensuring my fuses are like yours, but no fix there. Weirdly, when I program syscfg0 with f5, it comes back on a later read as e5, so I think there are some undocumented bits there (as I mentioned above, a couple of posts ago).

Given what John just showed why would you ever program F5 anyway? In the F you are programming bits 5 and 4 to one in "unused" positions and in the 5 you are not only writing to unused bit 2 but you are losing the default state of RSTPINCFG. I don't know about this AVR but in many setting the fuse bit that disables RESET is often disastrous! (often it will render a programming and/or debug interface inoperable).

Thank you for your time and reply, clawson. I was aware of the documentation for SYSCFG0 and what bits are documented there well before js posted it (though I appreciate greatly his help too). I programmed F5 in a desperate attempt to make my SYSCFG0 look like his. If you read my post #41 you will see why I think there are undocumented bits in this register (around RSTPINCFG, at least). Similarly, I programmed bit 3 of SYSCFG0 in a desperate attempt to get myself a dedicated RESET pin, because I thought it possible that the chip was somehow getting stuck (after programming with STK600) in a way RESETting the chip might cure (and it did not cure it, placing a pullup on the now-RESET pin and bringing RESET low momentarily).

In any case, as I have mentioned, I can see (and visually verify) my machine code in the 4809 flash using AS7 to read it back, so the primary problem appears to me, my code is present on chip but does not run (even with STK600 then disconnected), and regarding rendering the programming for the chip inoperable (though you didn't mention the "12v" interface and such apparently surrounding this intrigue), I can still program the chip via UPDI (can see changes made over UPDI), so I don't think that is related to my problem. I am interested to note that others (think it was pgillard, above) apparently experience a similar problem to mine (using the STK600).

I agree with that sentiment. js mused that the bits coming back that are not documented might just be random, but I am not sure. I noted in #41 that the reset value is 0xc4, which has at least bit 2 set (100b), which is not documented, unless RSTPINC is actually two bits as potentially documented in the Atmel-ICE guide (https://www.microchip.com/webdoc...). Maybe bit 2 is UPDI as documented there, and bit 3 maybe is GPIO vs RESET. His value of 5 for the right nibble might thus be UPDI? In any case, my main problem, as I said, appears to be that my code is in the flash, but I can't get output from the chip, for a test program that works when js programs it via whatever the xplained board has (as opp to STK600 programming). Heartening is that I can get some output from the chip, though not apparently the right output, when I flash js's hex file. But I get 20 seconds of potential serial output from his program, where it should be very brief as it is just one or two lines of serial. I have not been able to see that the output is quite valid asynch serial with my TTL serial to USB cable or with my scope.

Thank you for the reply. My experience so far with this thread is that folks who have the xplained board can run code on it, and even my initially posted psg.hex file will work on their boards, but not in other boards or housings for the 4809 (e.g. see post #8).

What I'd love to see is for someone who is not using the xplained pro board to have success running code. I am not sure we have seen that yet in this thread. pgillard said he loaded code (as I did) with STK600, but rereading that post #8 I don't get the sense he was able to run code on a non-xplained-housed 4809.

Unfortunately the schematic for the xplained pro board doesn't shed much light on anything of note I have different with the 4809 I am trying to run on my non-xplained setup. It appears that all one needs to hook up is the pwr supply pins and the UPDI pin. Sadly there do not exist (that I have found) other published schematics (like, for the hackaday-publicized board in post #35) for 4809. At this point I do not know if it is my hardware environment for the 4809 or the fact I used STK600 to program it. (It doesn't appear to be my code because at least the CLKOUT portion of it appears to work for js when he downloads my code to his board - not sure about my portb toggle as he said portb was "high" but not sure what happens if he looks at my code running on his xplained board with a scope to see my intended high frequency toggle on portb). Though as I think about it, if I put js's "2 strings" hex file on my 4809, I do see varying output on CLKOUT and on his USART, though not the signals I expect on either pin (weirdly). So I have some evidence the chip can be made through software to do something, if not the intended thing.

....fitted with bypass/ decoupling caps...did I mention this before? (see how close to the chip they are in the Xplained board?)

If you fit a switch and a LED as described in the Xplained board plus a RS232 or TTL/USB adapter on USART1 I can post the latest code running at 20MHz, with the LED flashing (freezes when the switch is on) and sending strings out every time the switch is pushed or released.

What I'd love to see is for someone who is not using the xplained pro board to have success running code. I am not sure we have seen that yet in this thread. pgillard said he loaded code (as I did) with STK600, but rereading that post #8 I don't get the sense he was able to run code on a non-xplained-housed 4809.

I do have the ATMega4809 running successfully, with the chip programmed using the arrangement as described by El Tangas, as I mentioned in #8. His github site provides an avrdude.conf file which allows the device to be recognized. The programmer works fine in both W10 and linux. In fact, you don't actually need an Arduino, you could put an ATMega328 on a breadboard, with a 16 MHz ceramic oscillator, and load the programmer code into that. A 168 would also work, but you would have to recompile his source code.

I am presently using a small Arduino equivalent board, connected to and powered from a cheap CH340 USB to serial converter. As a programmer, it is much smaller and more convenient than the SDK 600.

Yes, with decoupling capacitors. I now have those as close as I can get them to the pins, that is, on the black pieces which allow access to each pin in my clamshell. I suppose it is still possible that an inch is too far away, but I am doubting this is my problem. I could try soldering my other chip to a breakout, there to put such caps rather than an inch away, a few mm away. Short of devising my own board or defeating the purpose of my clamshell, there's no way to get them closer. I doubt it is much of a matter if there is nothing between the caps and the pins electronically (or, in my case, anything remotely near these pins electronically) and the lines are shorter than an inch or two.

So far, with your code (thank you) on my board, I see output, but as I mentioned, 20 seconds worth of output from the USART (maybe not quite look right there on my scope, or the TTL/USB adapter I have), as well as non-regular output on CLKOUT. Hmm.

js, you said with my code the portb output was "high". Do you have a scope? Are the pins on your board for portb actually toggling at high speed with my code on your board? I like that we see CLKOUT, but would feel even better if we knew that my code was working fully as intended on your board at least.

pgillard, can you elaborate on this? Other than trying out avrdude with his avrdude.conf file that has jtag2updi in it, I don't know what specific steps to try (don't know "the arrangement as described by El Tangas"). Does his stuff require the jtag mkii programmer? Have you had any success using STK600? What I want to be able to use (and have hardware for, is STK600, either with programming via AS7 or linux/avrdude). But when I tried his conf file with my avrdude, the avrdude program could not access the STK600, presumably because his conf file is not written to use STK600 with UPDI. Are you able to program your clamshell or breakout using STK600?

I am a little confused as to your hardware setup and what tools you are using to program it. Part of my confusion is I use STK600 and my own clamshell or breakout rather than xplained or arduino/arduino-lookalike.

Good question; I am using a Yamaichi clamshell as in https://www.mouser.com/ProductDe.... It looks pretty solid in there . . . this clamshell has worked for various ARM chips . . . hmm. I attach the best pic I could easily get of it.

I guess to take the clamshell out of the picture I could solder the 4809 into a breakout. Maybe should wait a bit to see if pgillard posts again -- as I understand it he tried 4809 with clamshell and maybe breakout, but unclear whether his setup is one I can easily duplicate or even that I understand how to duplicate.

Thanks js. Re the clamshell, the contacts are a bit springy; when the lids is closed it presses the pins into the contacts. Still, could use up one of my two 4809s soldering it to a 48-p breakout to double check that (as I say, this clamshell has worked with ARM chips). hmm; also, with your 2 strings fw I do see 3v3-looking output on PA7, and that pin is on the left (pin3) . . .

pgillard, that is what I was trying to get avrdude to work (just the conf file). AFAIK that conf file is not set up to use stk600 with avrdude and linux; it cannot find or connect to the skt600 as-is.

gchapman: yeah, but does he post a schematic for the 4809? That's what I want, as . . . well, as noted in conv with js, my firmware (my program) is working fine in his setup, suggesting the problem is with using the sk600 to program it (but the flash readback from AS7 shows my program is there) or with my 4809 hw environment.

pgillard, can you elaborate on this? Other than trying out avrdude with his avrdude.conf file that has jtag2updi in it, I don't know what specific steps to try (don't know "the arrangement as described by El Tangas"). Does his stuff require the jtag mkii programmer? Have you had any success using STK600? What I want to be able to use (and have hardware for, is STK600, either with programming via AS7 or linux/avrdude). But when I tried his conf file with my avrdude, the avrdude program could not access the STK600, presumably because his conf file is not written to use STK600 with UPDI. Are you able to program your clamshell or breakout using STK600?

I am a little confused as to your hardware setup and what tools you are using to program it. Part of my confusion is I use STK600 and my own clamshell or breakout rather than xplained or arduino/arduino-lookalike.

The current release of avrdude (6.3) doesn't support UPDI yet, I think. You would have to compile the unreleased trunk version.

That's why I needed to edit the avrdude.conf file to tell avrdude to use the pdi interface instead. Basically, it's an hack that makes avrdude think the UPDI chips are xmegas, and only works with my programmer, which is expecting it.

Naturally, STK600 fails if you use old versions of avrdude and my modified avrdude.conf file. This avrdude just doesn't know what UPDI is.

To sum it up, STK600 might work if you compile the most recent avrdude development version, and use the respective avrdude.conf (which I edited to make my avrdude.conf). These can be found here: http://svn.savannah.gnu.org/view...

pgillard, can you elaborate on this? Other than trying out avrdude with his avrdude.conf file that has jtag2updi in it, I don't know what specific steps to try (don't know "the arrangement as described by El Tangas"). Does his stuff require the jtag mkii programmer? Have you had any success using STK600? What I want to be able to use (and have hardware for, is STK600, either with programming via AS7 or linux/avrdude). But when I tried his conf file with my avrdude, the avrdude program could not access the STK600, presumably because his conf file is not written to use STK600 with UPDI. Are you able to program your clamshell or breakout using STK600?

I don't use the STK600. It doesn't work in the configuration you and I have tried. The Arduino is the programmer, replacing the STK600. Load it with the code at github, connect it as shown in the readme, (a single wire to UPDI, and power and ground), get avrdude to talk to it, and you are good to go. There is an example command line for avrdude in the readme, as well.

I soldered my second 4809 that I was trying in that clamshell onto a 48p breakout, and . . . it shows the same behavior as when it was in the clamshell. js will be happy that with the breakout my decoupling caps are a little closer at about 5mm and 9mm than they were before (as I said, I doubt that's the problem; only way to get them closer than with this dip breakout is buy a board or make one with kicad and a fab).

Regarding "using Arduino as the programmer" (rather than STK600), it appears you are referring me to El Tangas' page about that. Maybe I could pursue that, though that's a bit unattractive. The only arduino I have lying around is a mega2560 one (though as was said, I could put the code into a breadboarded 328p or similar). It sounds to me like I need to recompile El Tangas' stuff if I want to pursue that on something other than 328p. Actually, I don't have the arduino 2560, must have loaned it to someone. It's either pursue El Tangas' way on big/fast enough AVR to host the code or wait for (or compile myself) avrdude improvements, though that would still be using the STK600 and might still fail mysteriously. Maybe somebody will figure out how to get STK600 to work. I would expect Atmel/MC would be interested in making it work, as they are selling the chip, and I doubt they want it to be this difficult/constrained as to how to program it and produce a running program. That or bag the 4809; there are plenty of AVRs that work great with STK600, though I was hoping to use the attractive patch bay on my clamshell board.

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.

I doubt you'll find many users of stk600. It was never a great device. Atmel once sent me one for free, I ended up giving it to someone else. Over priced for what it was compared to the truly wonderful stk500 it was supposed to replace. Anyone looking to play the 4809 game will almost undoubtedly be going for the Xplained board, a much better option with a debugger.

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.