Off to a rough start... AVR128DA48

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

I've been following a couple of Threads that discuss the (new) AVR128DA chips, and thought I get one and Flash an LED.

 

Ought to be doable, (I said naively), as I unburied my SNAP programmer, looked up its pin-out, and made a programming cable for the PCB.

 

Know that since neither Bascom nor ZBasic (yet?) support the AVR128DA's I already crossed one giant hurdle and by deciding that I could write my first program in C to flash an LED on the new chip.

 

A few minutes on Google and I had a pretty good idea of the code, as there are plenty of examples to simply copy at this point.

I'll figure out .c .a .s .h and whatever other files there are in time.

 

I load Studio, which I routinely use for programming .hex files into chips, but have never used as an actual programming environment.

 

I start a new project and there is a pull-down box for one's chip selection.

Unfortunately, Studio 7.0.xxx doesn't list the AVR128DA's.

 

So I use the update option via another pull-down and spent 2 hours letting it update my version of Studio.

 

Restart Studio and there are still no AVR128DA chips...

 

That was frustrating.

 

So I load MPLab X IDE which I tried a couple of times when I first purchased a Snap programmer, and have not used since.

(That was a terrible experience.  It kept resetting the Fuses on my AVR chips to some default value every time I used it as a .hex file programmer.)

I've not used the MPLab X IDE or the SNAP programmer since then.

 

So, I take deep breath, figure I'll try it again.

 

I click on Create New, Standalone Project, All Families, and it, also, fails to list the AVR128DA chips.

 

What???

 

Since I'm not seeing the chips under either IDE either I have to go look for the most up to date versions and try again, or I'm missing something basic, (which is very possible).

 

Unfortunately, (tinkering wise, anyways), I have to work tomorrow, so its off to bed.

 

Very frustrating. 

I had truly hoped to see a little tiny LED flash on and off this evening.

 

After Studio updated itself I expected to at least find the chip...

 

I'll give it another try in a couple of days.

 

Sigh.

 

JC

 

 

 

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

MPlab X version 5.40 has that chip listed

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

MPLABX 5.30 has 4 AVR128DA's listed (28-64pins). When creating a new project, it informed a 'pack' was needed and had a link to open the 'pack manager' where it can be downloaded within the ide.

 

I created a simple project, seemed ok except the linker script may need to be changed if its not using __DATA_REGION_ORIGIN__. It also seems the .rodata section in the linker script needs to change like the avr0/1, although it also seems like the compiler will only deal with const/.rodata data in the first 32k. I'm not sure how they map the other 32k flash segments into data memory space, but I assume they are using rampz to choose the 32k segment. I suspect the compiler does not yet deal with rampz for these things and you are probably left with the using the old style of dealing with const/flash data.

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

After Studio updated itself I expected to at least find the chip...

You may have to update the device packs yourself, going through the update here (my AS7 version still had a 1 in front) see if an get anywhere.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

And for Studio, Tools/Device Pack Manager and install the DFP for the Dx parts to get this device...

You should have a notification regarding this, check the flag icon in the upper right corner of Studio...

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Sun. May 24, 2020 - 02:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reason for the IPE to reset the fuses is because it will program them as described in the hex file. If you don't describe any fuses they are defaulted.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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


OK my updates now bring up the Dx family, thanks Morten. hmm I think I did not restart Studio the 1st time around blush

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The reason for the IPE to reset the fuses is because it will program them as described in the hex file. If you don't describe any fuses they are defaulted.

There's a checkbox where you can tell IPE/MPLABX *NOT* to program the fuses.  I seem to have set my SNAP to do that by default, somehow (ie it says I've got the  "Exclude configuration memory from programming" option set, which I think is different from the per-project "choose memories to program" option.  Because that one is set to "let SNAP choose the memories to program.")

 

I would certainly hope that if there are no fuses in the .hex file, the programming software doesn't "make them up."  But I wouldn't count on it :-(

 

Putting the fuses in your program (and binaries) is the only way to program some of the fuses with MPIDE/MPIPE.  Their manual "Window/Target Memory Views/Configuration bits" panel is missing some (Bootloader-related config for instance.)
At least, as of 5.3.

 

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

>The reason for the IPE to reset the fuses is because it will program them as described in the hex file. If you don't describe any fuses they are defaulted.

 

If the fuses are not in the hex file, both mplabx and ipe do not program the fuses. You can leave the fuses alone until you want a change, if you like.

 

I have a Fuse.hpp that I just add fuse options as needed (anything not default) to a function argument list (any order) that creates a fuse array for me, then I have a define in the main options header to decide if I want to program the fuses or not-

 

//at end of Fuse.hpp

#ifdef FUSE_DO_PROGRAMMING //set in MyAvr.hpp

    [[ gnu::section(".fuse"), gnu::used ]]
    inline auto constexpr FUSE_BYTES { Fuse::fuse };

#endif

 

The same kind of thing can be done in C also.

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

That is true now... Was not true some versions back (for avr specifically)

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

you might like this info:

 

Here is some funtime errata ...so far, so good??

http://ww1.microchip.com/downloads/en/DeviceDoc/80000882A.pdf

 

A nice DA user's guide (I didn't look much at it).

http://ww1.microchip.com/downloads/en/Appnotes/AN3429-Getting-Started-AVRDA-Family-DS00003429A.pdf

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

>I'm not sure how they map the other 32k flash segments into data memory space, but I assume they are using rampz to choose the 32k segment.

 

Looks like I was wrong, rampz is still just for Z things as usual. They have a FLMAP bitfield in NVMCTRL.CTRLB that has to be set for a 32k segment to map into data space addresses. By default it is set to 3 so you get the upper 32k of flash mapped which also means changing the linker script .rodata section like avr0/1 will also not work by default (and you will not really know which 32k segment you rodata will end up in since it will be at the end of .text).

 

Their plan may be to make sure the .rodata is in the last 32k if not already (via linker script), and with the default FLMAP value there will be nothing more to do (probably why 3 is default). That's assuming your rodata is < 32k, which will most likely be true, and also assuming the flash mapping errata is fixed.

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

And for Studio, Tools/Device Pack Manager and install the DFP for the Dx parts to get this device...

You should have a notification regarding this, check the flag icon in the upper right corner of Studio...

A little update:

 

Thank you to everyone for pointing me in the right direction!

 

Morton's suggestion above lead me to getting the updated chip data files downloaded into Studio.

 

I also downloaded the current version of MPLab X IDE & IPE, to upgrade from V5.1 to 5.4.

 

It was still a painful process to simply flash an LED, however.

I could see the chips, and I started a new project, but the darn SNAP wouldn't work.

I got lots of various error messages...

 

When I originally purchased the SNAP I actually purchased 3 of them, with the intention to give one away, have one for myself, and have a "spare".

 

So I finally tried another SNAP, and it connected to both Studio and to the MPLab X IDE & IPE easily.

 

Sigh.

A dead SNAP out of the box.

I probably would have tried a different programmer much sooner but I'm not familiar with the usual responses, so I kept thinking I had loaded something incorrectly, or pressed the wrong buttons...

 

I then switched back to mostly using Studio.

I wrote a simple Flash the LED program, but all of the examples I had were for classic Megas and Tinies.

I changed the instructions to set the I/O pin direction using the DA registers and hoped for success...

 

I think I was compiling a null new program and kept downloading that, and that I wasn't really compiling and downloading my LED flasher program.

 

In any event, I finally wrote (mostly copied) my first C program, and made an LED flash on the new AVR128DA48 chip!

 

Hurrah!

 

Clearly I have a lot of learning to do with just navigating around and using Studio and the MPLab programs.

 

But I'm off and running at this point!

 

Thank you, again, to everyone for their guidance!

 

JC

 

 

 

Edit: Typo

Last Edited: Tue. May 26, 2020 - 08:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a load of example code on Github...

 

https://github.com/search?q=avr1...

 

[EDIT]

Link updated.

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

Last Edited: Wed. May 27, 2020 - 07:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally wrote (mostly copied) my first C program

Congratulations, see you are more than just a pretty face....

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

DocJC wrote:
I also downloaded the current version of MPLab X IDE & IPE, to upgrade from V5.1 to 5.4.

 

May be a good idea to avoid Mplab X as long as you can, it can be a pain in the rear end

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

DocJC wrote:

In any event, I finally wrote (mostly copied) my first C program, and made an LED flash on the new AVR128DA48 chip!

I have lived to see the day!

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]