Out of ideas to get atmega4809 to work

Go To Last Post
87 posts / 0 new

Pages

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.

Pages