Self-Programming AVR32 UC3A internal flash

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

I wasn't sure which forum this belongs in, since it's both hardware and software related, but here goes. I'm having problems programming the internal flash memory via software. I'm using Atmel's flash driver, but it doesn't work. The problem is, one page gets programmed, but the processor is crashed or halted after that. After rebooting, I can see my test data has been burned into the page I chose, but only the first page in my test area was programmed.

My understanding is that I should be able to write to the flash as long as the code is running out of the lower region of the flash within the BOOTPROT section, which I have set to the maximum of 64K bytes. The end goal here is a program loader function for loading a larger application (higher in flash) via a serial port.

I am reasonably sure that all of my code and vectors and so on are contained within the bottom 64K. I have altered the linker script in such a way that the flash is limited to 64K (FLASH (rxai!w) : ORIGIN = 0x80000000, LENGTH = 0x00010000). If it gets bigger than that, the linker will complain.

Any ideas? I'm assuming I'm missing something obvious, but what?

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

Just as a suggestion, have a look at the USB DFU example application, as it contains all the stuff to program the flash, and may be able to help you find why the processor is crashing after the first page write.

Where the data comes from (USB or serial) shouldnt matter as far as writing to the flash is concerned.

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

CDaniel_MT wrote:
Any ideas? I’m assuming I’m missing something obvious, but what?

Can't help you with this, but...
CDaniel_MT wrote:
The end goal here is a program loader function for loading a larger application (higher in flash) via a serial port.

I have posted this at https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=111102. Please let me know how it works for you and especially, if you make any improvements.

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

Deleted the comment !

-Krishna Balan S

-------------------------------------------------------------------------

"Heroes are ordinary people with extraordinary commitment"

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

Simply use the flash driver with the memcpy function will work, try with the highest flash pages just to make sure you're not erasing your own code. Side note: you can't fetch in flash while writing in flash (cpu will be hold until the page program is done), so if this is not what you intend to do, you'll have to link your programming code in RAM and fetch from RAM.

-sma

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

Thanks, everyone, for the suggestions.

daffniles: I would look at the USB DFU loader, but I can’t find the source code anywhere. I’ve heard that it comes with AVR studio (is that true?), but I’m using Studio 5 and it’s not there.

jkuusama: I checked out your loader. Looks very much like what I’m shooting for here, and is basically what I’m doing in my test code right now. Unfortunately, I don’t see anything there that I didn’t already know.

sma: I am using flashc_memcpy. It does not work – crashes after one page. I am testing in the highest two pages of flash, while executing from the low 64K of flash. From one of the many things I’ve read on this subject, I inferred that we can execute from the boot-loader protected region (low end of flash) while writing to the other portions of the flash. That’s what the USB loader does, is it not? If the CPU stalls during the page write operation, then my assumption is false. But it seems like it should still work, as I would expect the CPU instruction fetch to continue from wherever it was when it stalled. But that does not appear to be the case. Would it matter whether interrupts are occurring? That is, do I need to disable interrupts during page write?

Interesting side note: I also checked out Atmel’s flashc example project (but did not build or execute it). They have done nothing special to move the flash burning code into RAM. They simply start programming flash. How can their example possibly work if the CPU stalls as soon as a flash write operation starts?

Still confused.

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

Maybe you should indeed disable interrupts. As sma said, you can't fetch in flash while writing in flash, and if an interrupt routine tries to do that...

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

Update: Atmel's flashc example project does not work (on EVK1100). It crashes in the same way as my test code. Their example first fills a flash page with zeros, then erases it and writes some other non-zero data. After their first page write (zeros), the program stops and never starts again. They never enabled interrupts, so I don't think that's the issue. I have submitted this same information to Atmel tech support. I'll update here if/when I find a definative answer.

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

Would suggest you download AVR32 Studio 2.6 which can be used to create all the example applications (including the USB DFU Bootloader examples), Although it does use an older version of the Framework, it is simple to then be able to look through the code. Its based on Eclipse and download is available from Atmel.

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

It appears my problem was the silicon rev of the processor on the EVK-1100. That board has a Rev I processor, which is mentioned in the datasheet errata as having a flash bug which would account for my problem. I assumed that the processor on the evaluation board was newer than that. My mistake.

Regarding Studio 2.6 versus Studio 5 flash driver: The main difference between the two different versions of flashc.c files is that the Studio 2.6 version contains code for the RAM work-around for the flash controller bug. The Studio 5 version does not. I have now verified that my flash programming code (based on the Studio 5 flashc driver) appears to work properly on our new product board, which has a Rev L processor.

Thanks everyone who took the time to try to help me out with this.

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

it took me a while to spot the errata, too

I was very pleased to find the workaround on the atmel homepage - it's called AVR32749: 32-bit AVR UC3A0512/A1512 rev E, H, I Software Workaround for Flash Read-after-Write Errat

use it and the exceptions will be gone