Out of ideas to get atmega4809 to work

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

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.

 

Critical part of source code:

 

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                                                                                     

  //  delay_ms(500);                                                                                                                        

  while (1) {
    PORTB.OUTTGL = 0xff;
    //    delay_ms(1000);                                                                                                                   
  }
  return 0;
}

Critical part of objdump:

 

__trampolines_start():
../../../../crt1/gcrt1.S:226
  a0:   11 24           eor     r1, r1
../../../../crt1/gcrt1.S:227
  a2:   1f be           out     0x3f, r1        ; 63
../../../../crt1/gcrt1.S:228
  a4:   cf ef           ldi     r28, 0xFF       ; 255
../../../../crt1/gcrt1.S:230
  a6:   cd bf           out     0x3d, r28       ; 61
../../../../crt1/gcrt1.S:232
  a8:   df e3           ldi     r29, 0x3F       ; 63
../../../../crt1/gcrt1.S:233
  aa:   de bf           out     0x3e, r29       ; 62
../../../../crt1/gcrt1.S:310
  ac:   0e 94 5c 00     call    0xb8    ; 0xb8 <main>
../../../../crt1/gcrt1.S:311
  b0:   0c 94 6f 00     jmp     0xde    ; 0xde <_exit>

000000b4 <__bad_interrupt>:
__vector_38():
../../../../crt1/gcrt1.S:205
  b4:   0c 94 00 00     jmp     0       ; 0x0 <__vectors>

000000b8 <main>:
main():
/home/todd/Dev/AVR/test_4809/psg.c:13
static inline void delay_us(uint16_t count);

int
main(void)
{
  PORTMUX.USARTROUTEA = 0xff; // try and disable USARTs in favor of GPIO.
  b8:   8f ef           ldi     r24, 0xFF       ; 255
  ba:   80 93 e2 05     sts     0x05E2, r24     ; 0x8005e2 <__TEXT_REGION_LENGTH__+0x7005e2>
/home/todd/Dev/AVR/test_4809/psg.c:14
  PORTMUX.TCAROUTEA = 0x2;
  be:   92 e0           ldi     r25, 0x02       ; 2
  c0:   90 93 e4 05     sts     0x05E4, r25     ; 0x8005e4 <__TEXT_REGION_LENGTH__+0x7005e4>
/home/todd/Dev/AVR/test_4809/psg.c:15
  PORTB.OUT = 0;
  c4:   10 92 24 04     sts     0x0424, r1      ; 0x800424 <__TEXT_REGION_LENGTH__+0x700424>
/home/todd/Dev/AVR/test_4809/psg.c:16
  PORTB.DIR = 0xff;
  c8:   80 93 20 04     sts     0x0420, r24     ; 0x800420 <__TEXT_REGION_LENGTH__+0x700420>
/home/todd/Dev/AVR/test_4809/psg.c:18

  CCP = 0xd8;
  cc:   88 ed           ldi     r24, 0xD8       ; 216
  ce:   84 bf           out     0x34, r24       ; 52
/home/todd/Dev/AVR/test_4809/psg.c:19
  CLKCTRL.MCLKCTRLA = 0x80; // see if can get clock out
  d0:   80 e8           ldi     r24, 0x80       ; 128
  d2:   80 93 60 00     sts     0x0060, r24     ; 0x800060 <__TEXT_REGION_LENGTH__+0x700060>
/home/todd/Dev/AVR/test_4809/psg.c:24

  //  delay_ms(500);

  while (1) {
    PORTB.OUTTGL = 0xff;
  d6:   8f ef           ldi     r24, 0xFF       ; 255
/home/todd/Dev/AVR/test_4809/psg.c:24 (discriminator 1)
  d8:   80 93 27 04     sts     0x0427, r24     ; 0x800427 <__TEXT_REGION_LENGTH__+0x700427>
  dc:   fd cf           rjmp    .-6             ; 0xd8 <main+0x20>

000000de <_exit>:
exit():
/home/todd/tmp_avr_gcc_8.1/gcc-8.1.0/obj-avr/avr/avrxmega3/libgcc/../../../../libgcc/config/avr/lib1funcs.S:2278
  de:   f8 94           cli

000000e0 <__stop_program>:

Attachment(s): 

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

Is the 4809 inside the ZIF socket? I'm currently playing with the ATmega4809 Xplained Pro board and a few more people will start to use the same board too so eventually someone will be able to help.

 

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

 

It doesn't seem to have much in the way of out of the box code in Studio/Start yet, just some ADC examples.

 

EDIT you may want to post the .h file (s) as well as the .c files

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Jun 13, 2018 - 10:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

Oh, I guess it might be unclear since I left the two delay_.. fns in there. They aren't called in that test and can be removed.

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

If you are testing the chip, try smaller code:

 ;  Four words total
 zero:
 LDI R16, 0xFF
 OUT DDRB, R16
 top:
 OUT PINB, R16  ; assuming device uses PINx for toggle
 RJMP top

 

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

The assembly produced looked OK to me (referring only to the manual, alas)

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

skeeve that code will NOT assemble for the 4809, it uses newer Xmega like instructions.

 

I have USART0 working in assembler using LPM and trying to get the memory mapped mode working.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

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

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

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

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

Last Edited: Wed. Jun 13, 2018 - 11:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have just put together this hex file for you, it prints on USART0 (PA0) 2 strings at 19.2K

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

I didn't use a bootloader.

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

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?

Last Edited: Wed. Jun 13, 2018 - 11:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Wed. Jun 13, 2018 - 11:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And of course you need a TTL to RS232 converter, I don't see any on your board. Also I don't see any decoupling caps near the chip and on ALL GND, VCC pins which I hope are ALL properly connected.

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:

@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 ?

 

Last Edited: Wed. Jun 13, 2018 - 11:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(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?

 

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

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!

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

I could put some caps on the white strip

Too far, they need to be very close to the pins and 100nF, otherwise the chip may oscillate and behave erratically. This goes for ALL  brands of micros.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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?

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

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.

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

toddcromiii wrote:

@pgillard

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 ?

 

 

Exactly.

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

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.

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

are you able to enable the clk output on PA7

Yep, my code is a bit different than yours wink

	lds		temp, CLKCTRL_MCLKCTRLA
	ori		temp, CLKCTRL_CLKOUT_bm
	ldi		temp1, CPU_CCP_IOREG_gc
	sts		CPU_CCP, temp1
	sts		CLKCTRL_MCLKCTRLA, temp

I get 3.296 MHz which is close to the theoretical 3.333 MHz.

But then as I said, no clamshell solution would ever work reliably if that won't.

you can solder caps on the clam shell pins under the board which would be as close as possible.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

seeing serial output from the device for about 15-20 seconds

It only prints 2 strings and stops, I have other problems with the way the code is supposed to work but I'm getting sidetracked. smiley

The bottom line is supposed to be printed using the memory mapped mode but had to revert to LPM mode because it's not working.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

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

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.

 

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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.

 

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

This is a stripped down version of your code, added F_CPU to use the standard delay function, the LED (PORTB) flashes at 500ms at the clock out is present.

#include <avr/io.h>

#define F_CPU 3333333UL

#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_ms(500);
  }
  
}

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Oh, and, I was interested in whatever setup you do for the chip, not just the CLKCTRL part.

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

Ah ha! So it works for you. Would you send me the hex and elf files you generated for that? I wonder if it works for me. If you try my hex file (originally posted) does that work for you?

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

The system only allows hex files, I have now disconnected everything as it is a beautiful day outside and I've had enough of computers for a while. cheeky

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Raining heavily here, no surprise. Thanks for your help!

 

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.

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

I meant, your psh.hex, not psg.exe.

 

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?

Last Edited: Thu. Jun 14, 2018 - 02:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toddcromiii wrote:
I'd love to hear from others, too, on success with non-arduino, non-xplained setups with 4809.
https://hackaday.io/project/134831-atmega4809-developing-board-project 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

if my .hex file works on your setup

It "works" as in PORTB is high and the clock out is present.

what did you build and flash this code with?

AS7 version 1645  and debug/program directly from it into the board that has it's own debugger/programmer.

 

Edit deleted nonsense line.

 

oh and did I mention bypass caps close to the chip? wink

 

I'm posting the Xplained board schematic, maybe you can get some hints from it.

 

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Thu. Jun 14, 2018 - 02:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Last Edited: Thu. Jun 14, 2018 - 03:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So... what do you have the fuses set to?  I notice that they're much different than traditional AVRs...

 

I'm particularly looking at:

 

The CRCSCAN can be configured to perform a code memory scan before the device leaves reset. If this check fails, the CPU is not allowed to start normal code execution.

 

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

Do not have a fuse called that. What I have:

APPEND and BOOTEND set to 0

BODCFG 0

OSCCFG 0x2

SYSCFG0 0xe5

SYSCFG1 0

TCD0CFG 0

WDTCFG 0

 

(I noted after this post that you were talking about the crc related part of syscfg0)

Last Edited: Thu. Jun 14, 2018 - 07:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

 

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

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.

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

toddcromiii wrote:
Ok, well, pursuing avrdude on linux with this 4809 part is proving to be difficult for me.
mega4809 is in the forthcoming AVRDUDE 6.4

http://svn.savannah.gnu.org/viewvc/avrdude/trunk/avrdude/NEWS?revision=1425&view=markup (line 30)

 

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

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

In an idle moment I just read through that. Learnt something new on line 115 that I don't think I knew about previously!...

 

http://svn.savannah.gnu.org/view...

115 - The -B option can be suffixed with "Hz", "kHz", or "MHz", in
116 order to specify a bitclock frequency rather than period.

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

js wrote:

skeeve that code will NOT assemble for the 4809, it uses newer Xmega like instructions.

 

I have USART0 working in assembler using LPM and trying to get the memory mapped mode working.

I expect OP could fix it.

The point was not that I cold write wonderful assembly.

The point was that a test program could be only four instructions.

 

If a bootloader is getting in the way, OP might need to change some fuses.

International Theophysical Year seems to have been forgotten..
Anyone remember the song Jukebox Band?

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

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

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

STK600-QFP48 socket board (which I do not have); surely they have used that plus AS7 to program their own chips?

Maybe but unlikely, most people would use the Atmel ICE with AS7 for debugging and programming. The ICE is currently the only device likely to be kept up to date for newer chips.

 

I managed to squeeze all the fuse readings in one screen.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

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

I'd love to test this stuff, but I think customs just ate the 4809 Xplained Pro that was coming my way angrycrying

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

when I program syscfg0 with f5, it comes back on a later read as e5

There is only 2 bits used in the top half of syscfg0, so E5 or F5 is just random garbage on bits 4 and 5.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

toddcromiii wrote:
when I program syscfg0 with f5
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).

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

clawson wrote:
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).

 

This particular chip has a separate programming pin, but the tiny AVR-0 and AVR-1 can indeed be "bricked" with the wrong fuse setting.

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