Porting a sample project to a bigger UC3L

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

Been bit by the UC3L EOL on the 064... we've got products in the field, I'm not able to debug any longer.  I can write code and program boxes... just can't debug in Studio7.

 

The only difference between the 064 and 0128 that is important for my code is the User Page has been moved up 8 bytes... so the start address has to have 8 added to it and the length has to be shortened by 8.  Got this going, we're able to sell stuff (important) as long as we program with atprogram, which is dumb enough to take whatever you give it.  I leave the device in Studio 7 configured as 064, edit the uc3l064.h file, and all compiles OK.

 

Big problems when I change the device to 0128... won't compile, gives crazy errors related to defines.  ASF doesn't even show a folder for 0128... there are no example 0128 projects, obviously... don't even believe there's a kit for it (not going to bother to look).  If you go out and try to buy 0128s you're SOL right now... and truly SOL for 064's, they're all gone.

 

I've tried just removing all BOARD-related stuff... still has problems.  Here's what I'm guessing... this was written for the UC3L-EK and nobody cares.  I'm not the only sucker here I hope... does anyone have a clue how to proceed?  Are we left to hang out and dry by Microchip?  They're going to EOL the whole series, they've just got a lot of 0128 and 0256 die banked up they want to dump first.  I'm going to stop writing here, because it's going to be unprintable very soon.

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

Got misdirected three times, including an interesting jaunt to Bangalore.  The last lady I talked to told me Atmel is no more... so I'm here talking to empty walls, obviously.  Good luck folks... get in the lifeboat while you can. 

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

Are you sure about that 8 byte shift of the userpage ?
The page sizes are different and the factory-programmed userpage data is different, but, as far as i can tell, the start of the userpage is still the same.
Both uc3l064.h and uc3l0128.h have AVR32_FLASHCDW_USER_PAGE_ADDRESS #defined as 0x80800000

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

scowell wrote:
If you go out and try to buy 0128s you're SOL right now...
Appears there is some UC3L0128 stock.

Microchip's UC3L0128 stock is iffy (package dependent); minimums for trays may be reasonable with possibly reasonable lead times.

A concern is UC3L0128 is being bought by EOL/NRND distributors.

One could evaluate the risk with one risk abatement being a major redesign to a non-legacy MCU (UC3 is legacy)

scowell wrote:
I'm not the only sucker here I hope...
Lose that hope for I too have fell into a hole (in the past)

Redesign is a PITA.

A new UC3A4 product :

https://shop.nitrokey.com/shop/product/nitrokey-storage-8gb-11

scowell wrote:
does anyone have a clue how to proceed?
Not me (I'm not a UC3 operator)

scowell wrote:
Are we left to hang out and dry by Microchip?
Contact a Microchip rep.

There's an acknowledged supply problem especially for Atmel parts.

scowell wrote:
They're going to EOL the whole series, they've just got a lot of 0128 and 0256 die banked up they want to dump first.
That's not certain though there are sharks smelling blood.

 


https://octopart.com/search?q=at32uc3l0128&avg_avail=(1__*)&start=0

http://new.microchipdirect.com/products/search/all/at32uc3l0128

http://www.microchip.com/about-us/contact-us

http://www.microchip.com/docs/default-source/announcements-documents/letter-to-our-clients.pdf?sfvrsn=2

 

Edit : Nitrokey Storage

 

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

Last Edited: Thu. Aug 3, 2017 - 04:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone else heard the rumor about Atmel/Microchip dumping bad UC3L on the market?

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

gchapman wrote:

scowell wrote:
If you go out and try to buy 0128s you're SOL right now...
Appears there is some UC3L0128 stock.

Microchip's UC3L0128 stock is iffy (package dependent); minimums for trays may be reasonable with possibly reasonable lead times.

A concern is UC3L0128 is being bought by EOL/NRND distributors.

One could evaluate the risk with one risk abatement being a major redesign to a non-legacy MCU (UC3 is legacy)

We're having problems with new stock (direct from Atmel) UC3L programming but not working.  Our board house bought *1*128s, if you can believe that... not even supposed to be available, mask ROM parts.  They're having to pull them off and put 0128's on... and they're failing... hence, my desire to debug.  Redesign?  Would have a big problem going with Atmel/Microchip.

gchapman wrote:

 

scowell wrote:
I'm not the only sucker here I hope...
Lose that hope for I too have fell into a hole (in the past)

Redesign is a PITA.

A new UC3A4 product :

https://shop.nitrokey.com/shop/product/nitrokey-storage-8gb-11

 

gchapman wrote:

scowell wrote:
does anyone have a clue how to proceed?
Not me (I'm not a UC3 operator)

scowell wrote:
Are we left to hang out and dry by Microchip?
Contact a Microchip rep.

There's an acknowledged supply problem especially for Atmel parts.

scowell wrote:
They're going to EOL the whole series, they've just got a lot of 0128 and 0256 die banked up they want to dump first.
That's not certain though there are sharks smelling blood.

 


https://octopart.com/search?q=at32uc3l0128&avg_avail=(1__*)&start=0

http://new.microchipdirect.com/products/search/all/at32uc3l0128

http://www.microchip.com/about-us/contact-us

http://www.microchip.com/docs/default-source/announcements-documents/letter-to-our-clients.pdf?sfvrsn=2

 

 

Yeah, they were OOO at 4:30 yesterday... going to try them again today of course.

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

mikech wrote:
Are you sure about that 8 byte shift of the userpage ? The page sizes are different and the factory-programmed userpage data is different, but, as far as i can tell, the start of the userpage is still the same. Both uc3l064.h and uc3l0128.h have AVR32_FLASHCDW_USER_PAGE_ADDRESS #defined as 0x80800000

 

You're right... not sure what crack I was smoking at the time... I'll get back to you on this.

 

 

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

scowell wrote:

mikech wrote:
Are you sure about that 8 byte shift of the userpage ? The page sizes are different and the factory-programmed userpage data is different, but, as far as i can tell, the start of the userpage is still the same. Both uc3l064.h and uc3l0128.h have AVR32_FLASHCDW_USER_PAGE_ADDRESS #defined as 0x80800000

 

You're right... not sure what crack I was smoking at the time... I'll get back to you on this.

 

Take a look at link_uc3l064.lds vs. link_uc3l0128.lds... here's some relevant code from the 0128 file:

 

MEMORY
{
  FLASH (rxai!w) : ORIGIN = 0x80000000, LENGTH = 0x00040000
  INTRAM (wxa!ri) : ORIGIN = 0x00000004, LENGTH = 0x00007FFC
  USERPAGE_RESERVED (r) : ORIGIN = 0x80800000, LENGTH = 0x00000008
  USERPAGE : ORIGIN = 0x80800008, LENGTH = 0x000001F8
}

 

Pretty sure some user page stuff is getting redefined... sneaky!  So I modified the linker description, not the device headers... I'm remembering this now... found my comments in the code (always comment thoroughly!).

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

I am puzzled as to the purpose of that 'reserved' region, because I would expect it to be overwritten when the userpage is erased/written-to.
If the linker-file is correct then it means that the datasheet and the ASF header-file are incorrect.
If you cannot debug with AS7 then a test-program that writes and reads known patterns to the userpage and the last flashpage might clarify the issue.

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

Here's some interesting info... I found one ASF project for the UC3L0128... a bootloader project.  Turns out there's a dummy board available:

 

<>

...
#define AVR_SIMULATOR_UC3          98  //!< Simulator for the AVR UC3 device family.
#define USER_BOARD                 99  //!< User-reserved board (if any).
#define DUMMY_BOARD               100  //!< Dummy board to support board-independent applications (e.g. bootloader).
//! @}

</>

 

This will probably help.

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

Turns out the UART bootloader project doesn't have linker scripts... at least when I try to change devices it gives me:

 

"ASF doesn't support device change since some of the existing modules in the project may not work"

 

ASF doesn't tell me that on my other project... it probably should.  Maybe impossible?

 

Interesting... it goes ahead and changes the device... and both compile.  When changing back, I get the same error message.  The .hex files are very different in places.

 

Last Edited: Thu. Aug 3, 2017 - 11:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

More interesting stuff.  First a link from Bugzilla:

 

http://asf.atmel.com/bugzilla/sh...

 

This is Studio6... I haven't read the pdf. 

 

Then I did some more searching and I found the linker script for the bootloader project.  It was not in the same place!  I found it at:

 

C:\Users\Engineering 4\Documents\Atmel Studio\7.0\UC3_UART_BOOTLOADER1\UC3_UART_BOOTLOADER1\src\ASF\avr32\applications\uc3-uart-bootloader\at32uc3l0_128_256

 

instead of:

 

C:\Users\Engineering 4\Documents\Penulator Files\Penulator Remote Pro 6_07 0128\UC3L for Arduino Funcs - Copy\src\SOFTWARE_FRAMEWORK\UTILS\LINKER_SCRIPTS\AT32UC3L\064\GCC

 

and... the script shows the same USER_PAGE address for both, no 8-byte offset!  Where did I find that RESERVED piece?

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

I tried some example projects in Studio 6.2 and found that
1) if you create a new 'blank' project there is no 8-byte offset to the start of the userpage.
2) if you create an example project, the linker gets a -T parameter that points to a linker .lds file which changes the start-address of the user-page.


If you go to the Fuse Settings section in the Flash Controller FLASHCDW section of the datasheet you will discover (after the FGPFRLO description)
that the first word of the userpage is used for the WDTAUTO flag and word 2 of the userpage is user for the 'Secure State' feature.

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

Found it... someone contributed an 0256 lds to Github... I copied the changes over.

 

https://github.com/eewiki/asf/bl...

 

Forgot where I got it... searching on the USERPAGE_RESERVED brought it back up.

 

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

OK... reading the PDF for the 0128/0256 clears that up... the first word of the user page is WDTAUTO at startup... the second word is Secure State End Addresses for flash and RAM.  I use the user pages, so this is important for me.  Don't erase them to zero unless you want to enable watchdog on reset and screw up your Secure State End Address... whatever that is.

 

Looking like I'm going to have to set a dummy_board at least... and all the Microchip folks have f'd off to Masters2017... so there'll be no support for two weeks.  Thanks MC.

 

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

I did a uc3l064 project a few years back and didn't notice those features in the datasheet.
The WDAUTO feature didn't bother me because one of the very first things that I do at startup is to always enable the watchdog.
I had no need for the Secure State feature, so again, no problem if that data got erased when I put my values into the userpage.

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

mikech wrote:
I did a uc3l064 project a few years back and didn't notice those features in the datasheet. The WDAUTO feature didn't bother me because one of the very first things that I do at startup is to always enable the watchdog. I had no need for the Secure State feature, so again, no problem if that data got erased when I put my values into the userpage.

 

Right... we used the 064 too.  Now it's EOL... and everyone has to move to the 0128 or 0256.  The 0128/0256 have the first two words of USER_PAGE reserved for these 'enhancements'.

 

I'm finding some other differences... the EIC is a 301 for the 064 and a 302 for the 0128... there is no SCAN* on the 302.... breaks compiling.  I'm assuming I'll find lots of things like this... this is where support from Microchip would help... like a porting doc.  Are we SOL?  I've put in another query to them... I assume they're still out on their big yearly junket.  Could really use some support right about now.

 

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

First thing that fails on compile is the 'scan' member of avr32_eic_t... looks like this may be legacy problems.  We are up to 302 for 0128/0256... neither of which have the 'scan' member in avr32_eic_t.

 

Here's an interesting snippet... from eic.c:

 

<>

#if !defined(AVR32_EIC_301_H_INCLUDED)
void eic_enable_interrupt_scan(volatile avr32_eic_t *eic,unsigned int presc)
{
  // Enable SCAN function with PRESC value
  eic->scan |= (presc << AVR32_EIC_SCAN_PRESC_OFFSET) | (1 << AVR32_EIC_SCAN_EN_OFFSET);
}

void eic_disable_interrupt_scan(volatile avr32_eic_t *eic)
{
  // Disable SCAN function
  eic->scan = 0 << AVR32_EIC_SCAN_EN_OFFSET;
}

unsigned long eic_get_interrupt_pad_scan(volatile avr32_eic_t *eic)
{
  // Return pad number that causes interrupt
  return(eic->scan>>AVR32_EIC_SCAN_PIN_OFFSET);
}
#endif

</>

 

So if 301 is undef you try to find and use 'scan'... which is gone.  Gonna comment this out and proceed.

 

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

It proceeds!  The SCIF is a 102 for 064... and a 110 for 0128.  Crazy broken stuff deep down.  I hope Microchip didn't pay much.

 

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

Here's a puzzler (if anyone's following along)... where is __GNUC__ defined?  Doesn't show to be, but definitely should be.

 

 

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

Here's my next quandry... the whole thing was written as if the 0128 would never exist... a snipped from scif_uc3l.h:

 

<>

#if (defined(__GNUC__) \
      && (defined(__AVR32_UC3L064__) || defined(__AVR32_UC3L032__) || defined(__AVR32_UC3L016__))) \
  ||((defined(__ICCAVR32__) || defined(__AAVR32__)) \
      && (defined(__AT32UC3L064__) || defined(__AT32UC3L032__) || defined(__AT32UC3L016__)))
      // For UC3L revC and higher

 

</>

 

I'm imagining that the compiler itself defines __GNUC__... but I'm going to have to define ...064... or edit *every* occurrence, which is outrageous.  More later.

 

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

My AT32UC3L016/32/64 datasheet (vintage 2012), shows that the '064 uses the first 2 words of the userpage for the WDTAUTO and 'Secure State' features.


Which IDE are you using ?
I think that you are using an old version of Studio.
I still use Studio 6.2 and scif_uc3l.h does not contain any #if(defined(__GNUC__) statements, but it does contain statements such as

#if (UC3L0128 || UC3L0256)<br />
...
and eic.c has
#if !defined(AVR32_EIC_301_H_INCLUDED) && !defined(AVR32_EIC_302_H_INCLUDED)<br />
void eic_enable_interrupt_scan(volatile avr32_eic_t *eic, uint32_t presc)<br />
...

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

mikech wrote:
My AT32UC3L016/32/64 datasheet (vintage 2012), shows that the '064 uses the first 2 words of the userpage for the WDTAUTO and 'Secure State' features.
Which IDE are you using ? I think that you are using an old version of Studio. I still use Studio 6.2 and scif_uc3l.h does not contain any #if(defined(__GNUC__) statements, but it does contain statements such as #if (UC3L0128 || UC3L0256) ... and eic.c has #if !defined(AVR32_EIC_301_H_INCLUDED) && !defined(AVR32_EIC_302_H_INCLUDED) void eic_enable_interrupt_scan(volatile avr32_eic_t *eic, uint32_t presc) ...

 

Using Studio 7... 7.0.1417, should be latest-greatest.  I've been told to use an older ATPROGRAM by Microchip, however.

 

As a funny aside, anyone ever seen this from ATPROGRAM.exe?

 

<>

[ERROR] Verification at address 0x80000000 failed. Expected: 0xE0. Actual: 0xE0.
Firmware check OK

</>

 

Just a barrel of laughs... this is my laughing face... can you tell?

 

 

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

OK, now I see... in the old 064 doc, it refers to it as 'user row'... it's at the same address in the new (0128) doc, now properly called 'user page'.  The diagram 7.1 (old 064) or 8.1 (new 0128) shows the Reserved spots *before* 0x08000000.

 

The words have always been reserved.  There is no difference between the chips in this regard.  My apologies for being mislead by the Norwegian children that wrote the documentation.

 

My example project is from an earlier ASF... how they imagine you are to migrate this to new versions is beyond me.  The example project I started from has no reserved spot for these words.  This does explain some problems I had before.

 

I found the *.lds file before.  It did not have the first eight bytes reserved.  I had to add the reserved bytes myself, which I obtained via StackExchange.  Turns out that these should have been in place for *all* UC3L!  Norwegian children.

 

I still am not able to debug.  I still have no idea why two different part labels give two different results.  I have a case number with Microchip.  Hopefully they don't hire Norwegian children.

 

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

scowell wrote:

Here's a puzzler (if anyone's following along)... where is __GNUC__ defined?  Doesn't show to be, but definitely should be.

 

 


It's defined by the compiler. Try compiling an empty source with -E -dM and the compiler will dump its predefined macros. You will see it there.
.
For example see:
.
https://stackoverflow.com/questions/2224334/gcc-dump-preprocessor-defines

Last Edited: Sun. Aug 27, 2017 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
scowell wrote:

Here's a puzzler (if anyone's following along)... where is __GNUC__ defined?  Doesn't show to be, but definitely should be.
 

It's defined by the compiler. Try compiling an empty source with -E -dM and the compiler will dump its predefined macros. You will see it there. . For example see: . https://stackoverflow.com/questi...

 

OK... thanks... I was sure that it was, but the environment can't see that, so when tracing #if (__GNUC__) stuff you get lost.

 

I've had some success... first big realization, you have to start a fresh 'board project', even if you don't have a kit.  This puts dummy_board.h in and lets you use ASF.  You can choose the 0128 from the list, it all works.

 

Next, you delete the main.c from your new project (right click, remove, choose delete) then take your main.c (and all other specific non-ASF files) and move them to the new project src folder.  You probably can get away with just replacing the file, since the name doesn't change.  Select the src folder, right-click, and select Add Existing Item, then browse to the new main.c etc. files.

 

Next you have to open ASF Wizard and bring over all the drivers etc that your old project used.  You can clean/build and look for errors, this gives you clues about what's missing.  Don't forget to Apply after your Add's.

 

Turns out that my big mistake was leaving in the wait state changes for the 064 flash write... the errata on the 064 requires that you go to wait state 0 when writing to the User Page... there are two versions of the 0128 out there, and one of them doesn't like going to wait state 0 at 50mhz.  I commented out the flashcdw_set_wait_state() statements and it ran.  Microchip would never let on about the different parts... Microchip was not helpful at all... looks like we've gone from Norwegian children to Bangalore children.  The best thing they did was convince me that I was on my own.