Out of ideas to get atmega4809 to work

Go To Last Post
88 posts / 0 new

Pages

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

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).

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

toddcromiii wrote:
to make my SYSCFG0 look like his.
Which rather raises the question why John's one has this very "odd" value in it? I wonder if there's a display fault in AS7 or something. 0xF5 in that byte just does not "look right" in any sense!

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

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.

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

I'm going to have to fire up my 4809 if only to see what default fuses I have!

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

That'd be great! What is your physical interface like? STK600 with QFP socket on board? STK600 with your own clamshell or other? xplained pro board? other?

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

It's the Xplained board.

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

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).

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

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.

Last Edited: Fri. Jun 15, 2018 - 08:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

all one needs to hook up is the pwr supply pins and the UPDI pin.

....fitted with bypass/ decoupling caps...did I mention this before? wink (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.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

toddcromiii wrote:

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.

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

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.

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

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.

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

Are the pins on your board for portb actually toggling at high speed with my code

Possibly, I was just looking at the user LED on PB5. The scope is on another bench, I'll reprogram the board and bring it over the other side of the workshop.

 

By the way how sure are you of your clam shell arrangement? The pins are so close together that it would not take much to misalign them and have a short circuit or an open circuit on some pins

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

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

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.

Attachment(s): 

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

So stop worrying about the firmware, it all works as expected. I get the clock out on PA7 and PORTB is toggling at ~2.4ys.

 

This is with the hex file you posted above, not my build.

 

edit you picture shows the pins at left and right no making contact with the chip.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. Jun 15, 2018 - 09:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toddcromiii wrote:
I am not sure we have seen that yet in this thread.
by a few redirects.

mega4809 blinky, PB5 out, while, PB5 set, delay 500ms, PB5 clear, delay 500ms, end while

via

Hackaday.io

Details

Blinky test on ULTRA 4809 Explorer

by kodera2t 

05/22/2018

https://hackaday.io/project/134831-atmega4809-developing-board-project/log/146590-blinky-test-on-ultra-4809-explorer

via https://www.avrfreaks.net/forum/megaavr-0-series?page=1#comment-2475486

 

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

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

pgillard wrote:
A 168 would also work, but you would have to recompile his source code.
now mega48 per a change by El Tangas

https://github.com/ElTangas/jtag2updi/commit/237016cac1bb93b8de7462899b3d992b3e8d190e

due to https://www.avrfreaks.net/forum/megaavr-0-series?page=1#comment-2475636

 

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

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

That code will not work as expected because there is no code to disable the divider so the chip will run @3.333MHz not 20MHz.

 

Can the divider be disabled by fuse? Don't know.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

 

Darn.

Last Edited: Fri. Jun 15, 2018 - 10:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toddcromiii wrote:

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...

 

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

toddcromiii wrote:
... but does he post a schematic for the 4809?
5th photo at

4809 Ultra-Explorer board from microwavemont on Tindie

https://www.tindie.com/products/microwavemont/4809-ultra-explorer-board/

via https://hackaday.io/project/134831-atmega4809-developing-board-project/log/146590-blinky-test-on-ultra-4809-explorer

though with defect(s) at U1 (LDO); BOM may be in that project's log thread.

 

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

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

toddcromiii wrote:

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.

 

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

Thank you for all the help, folks.

 

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).

 

Also sadly, my review of that 5th photo schematic 4809 ultra-explorer thing doesn't reveal any problems with my setup.

 

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.

Last Edited: Sat. Jun 16, 2018 - 03:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)).

 

Last Edited: Sat. Jun 16, 2018 - 11:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm, it appears as though it is difficult to submit as case to Atmel without having a support contact. Does anyone have an email address or something to submit a bug report to them?

 

Hmm, maybe by making an account on support.microchip.com -> my support. We'll see if that works, given that I didn't want to give them my address hence gave them their own address.

Last Edited: Mon. Jun 18, 2018 - 05:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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;

}

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

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 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.

Last Edited: Tue. Jun 19, 2018 - 03:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you suspect a fault in AS7 or its support for STK6500 I would raise a ticket with Atmel. Apart from anything else they will have STK600+4809 combinations to try so they can replicate what you see.

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

clawson wrote:

If you suspect a fault in AS7 or its support for STK6500 I would raise a ticket with Atmel. Apart from anything else they will have STK600+4809 combinations to try so they can replicate what you see.

 

I did just that a few days ago, and they are able to replicate the problem.

We have courses that use the SDK600; we find them convenient.

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

As you can see from a post a couple before yours, I did submit a case to Atmel.

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

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.

Last Edited: Wed. Jun 20, 2018 - 02:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

With a bit of "surgical" skill you should be able to do it. The Xplained board has a connector designed to plug in an external ICE to the board and don't use the internal debugger chip.

 

It has the UPDI pin as well as a reset pin available, you would have to separate the on board chip I guess from the UPDI.

 

However by the time you buy the board you can add a bit more money and get a proper Atmel ICE, then you can program and debug a zillion chips including ARM.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

Last Edited: Wed. Jun 20, 2018 - 03:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Finally could change clock settings. My code is below. Have to set CCP before every change in clock setup AND the first change is not working...

 

#ifndef F_CPU

#define F_CPU 20000000UL

#endif

 

#include <avr/io.h>

#include <util/delay.h>

 

int main(void) {

  CCP = 0xD8; //Enable clock configuration change.

  CLKCTRL.MCLKCTRLA |= CLKCTRL_CLKOUT_bm; //Enable clock out

  //First call to clock setting change doin' nothin'.

  CCP = 0xD8; //Enable clock configuration change.

  CLKCTRL.MCLKCTRLB &= ~CLKCTRL_PEN_bm; //Disable prescaler.

  CCP = 0xD8; //Enable clock configuration change.

  CLKCTRL.MCLKCTRLA |= CLKCTRL_CLKOUT_bm; //Enable clock out

 

  PORTB.DIRSET |= PIN5_bm;

 

  while (1) {

    PORTB.OUTSET |= PIN5_bm;

    _delay_ms(500);

    PORTB.OUTCLR |= PIN5_bm;

    _delay_ms(500);

  }

}

Last Edited: Fri. Aug 31, 2018 - 05:02 PM

Pages