Self programming and RWW,NRWW memory sections

Log in or register to post comments
Go To Last Post
12 posts / 0 new
Author
Message
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
#1
Posted by gahelton: Fri. Jun 15, 2007 - 03:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a MEGA168 that is setup with seperate boot and application sections. Boot code is setup as 8 pages (512 words, 1024 bytes). These are pages 120-127. Application code is used for the lower pages 0-119.

The RWW section is fixed from pages 0-111 with the NRWW section being fixed from pages 112-127.

Now for the problem. My bootloader code (running from the boot section) programs all pages in the RWW (application) section fine. However, it will not program any of the pages in the NRWW section. According to what I can find in the datasheets, the only limitation from programming the NRWW section while running code from the NRWW section, is that the CPU is stopped while the flash page in actually being programming after the SPM instruction. This is a limitation that I can deal with.

But why won't the 8 pages from 112-127 not program at all ? Is there another limitation of running code in the NRWW section while programming there as well ?

Thanks

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39868 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Jun 15, 2007 - 04:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Boot lock fuses?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Fri. Jun 15, 2007 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The boot lock fuses are not programmed. Even if they were, shouldn't the fuses only protect the "boot section" ?

Some of my confusion comes from the fact the the boot section is variable in size while the NRWW section is fixed to the largest size that boot could be. If the memory allocated for the boot section is smaller than the NRWW section. Then some of the application code will lie in the NRWW section. This NRWW, application code area is where I'm have problems programming.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100165 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jun 15, 2007 - 02:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't suppose you've got a Dragon? It'd make diagnosing something like this 1,000 times easier (IMHO!)

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Fri. Jun 15, 2007 - 04:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a Dragon, but I haven't hooked it up yet.

Today I use the JTAGICEMKII with debug wire.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100165 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jun 15, 2007 - 05:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Then if you have a DebugWire debugger surely you can SEE why the SPM code is not doing it's job on pages 112 onwards?

Top
draymond
draymond's picture
Level: Hangaround
Joined: Thu. Apr 12, 2001
Posts: 273 View posts
Location: California/USA
Posted by draymond: Fri. Jun 15, 2007 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the CPU is stopped while the flash page in actually being programming after the SPM instruction. This is a limitation that I can deal with.
How are you dealing with it? When the CPU is stopped it cannot do anything. How is the data being sent into the processor? Is there a handshake present that prevents data from being sent in while the processor is stopped?
We had a similar problem, no handshake was possible, so we ensured that the source of the data would pause between pages.
Dave Raymond

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Mon. Jun 18, 2007 - 06:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dealing with the CPU stopping is not a problem. The master device pauses for at least 5mS after each page programming command. This gives the micro time to finish the SPM command and program the flash page before the next one is sent.

Follow-up.

Part of my original problem was found. I didn't have as much area defined for boot as I thought. Once this problem was corrected, a new problem appeared. Now, all of the pages of the application section appear to program correctly. This can be verified with Studio with the Program memory view window. However, the JTAGICEMII will not reset or run correctly after flash programming. The boot section was not overwritten as far as I can tell. The vectors and code appears to be in place.

This "appears" to be be a tool problem instead of a problem with the micro. Even reloading code will not fix the problem. To get back to operation, Debugwire must be disabled then re-enabled. Then code must be uploaded again.

Has anyone else had a similiar problem with programming the last page of flash below the boot section (under bootloader control) with a JTAGICEMKII ?

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Mon. Jun 18, 2007 - 10:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Further investigation -

I used AVR Studio to read the contents of the flash after programming the last page of application flash (after the problem appeared). The actual contents of the boot section in the micro was compared against the hex file for the data that was supposed to be in the boot section. Two bytes at word address 0x1E31 was changed. No other differences were found.

It appears as if two bytes in the flash was actually modifed in an area where no erasure or programming should have occured. Not only that, but the changes in the bit patterns suggest some bits were erased and some bits were programmed (both changes from 0 to 1 and changes from 1 to 0). It would have been impossible for my code to accomplish this without reading the page data, erasing the page, changing the bits, then reprogramming the page. My flash programming code in boot does nothing like this.

Any thoughts ?

Top
gahelton
gahelton's picture
Level: Resident
Joined: Wed. Mar 19, 2003
Posts: 738 View posts
Posted by gahelton: Tue. Jun 19, 2007 - 11:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem solved -

1. My master device was sending new flash pages to program too fast. The master delay was set for 5mS between messages. However, this is not long enough. Each operation (erase and program) takes a maxmimum of 4.5mS each. Time between master flash programming messages was increased to 12mS.

2. After each flash page programming operation,a verification is performed against the data in my receive buffer. If was my belief that to re-enable the RWW section, the RWWSRE bit was set along with the SELFPRGEN, then SPM was executed. Then the RWWSB is polled until it's cleared to indicate that the RWW section is available. Well, that's WRONG. The correct way to do this is to check the RWWSB bit. If it's set, then attempt reset with the RWWSRE & SELFPRGEN with SPM. Continue sending RWWSRE & SELFPRGEN until RWWSB is cleared. One attempt will not work. In ImageCraft C, it looks like this:

while(SPMCSR & (1<<RWWSB) )
 {
 WriteSPM(0,0,( (1<<RWWSRE) | (1<<SELFPRGEN) ) );
 }


void WriteSPM(unsigned short pageadd, unsigned short data, unsigned char SPM_Value )
{
//***************************************************
// Data is input into the function in these registers
// SPM Value

I have no idea why bytes of flash in the boot sector were getting corrupted by not waiting for the RWW section to "come alive" before reading, but that is what happened.

Top
draymond
draymond's picture
Level: Hangaround
Joined: Thu. Apr 12, 2001
Posts: 273 View posts
Location: California/USA
Posted by draymond: Wed. Jun 20, 2007 - 04:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I believe that you are testing the wrong bit in the waitspm loop. It should be bit 0. In addition there should be no need to preserve the registers you do: Imagecraft considers these registers volatile within any function.
Dave Raymond

Top
scobb
scobb's picture
Level: New Member
Joined: Tue. Jan 27, 2004
Posts: 6 View posts
Posted by scobb: Wed. Jun 20, 2007 - 06:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a similar problem - well not quite. I may be trying to do something that can't be done. It is not clear.

I have the boot code working fine for upgrading the main code in the RWW section (from the boot code in NRWW).

I want to now update the boot code from the main section - i.e. run from RWW and update the NRWW section. This does not work, nor does updateing RWW from the RWW section (I just moved the destination address down to after my main code to see if the destination mattered). The resulting bytes do not change from 0xFF. The data being sent is handshaked, so it is not a problem with that timing.

Is this fundamentally not possible? Or, is there something different I must do? I am using the AppNote:AVR106 code. Again it does work fine the "normal" way.

Steve

Top