Hello All,

Recently I was trying to use IAP mechanism to write
one selected flash sector. I prepared my IAP routine and tested it by
reading out device ID. The result was correct. Next, I tried to write
a
flash sector with given pattern. In order to do that I disabled all
system
interrupts and prepared ram buffer (256 bytes long). The buffer was
located in RAM at address 0x40006000. I filled in the buffer with
desired content. Next I prepared sector to write (command 50(dec))
after that I executed erase command (52(dec)). Flash sector was filled
in with 0x00. For both returned status code was 0. After that I issued
`prepare sector for write command' (50(dec)) again, and `Copy RAM
to flash' (51(dec)) (with given RAM buffer) Flash sector was not
written with correct data.
In next test I executed:
1. "prepare for write", "erase";
2. "prepare for write", "copy..";
3. "prepare for write", "erase";
4. "prepare for write", "copy";
After second "`Copy RAM to flash' operation, data in flash appeared
as expected.
In next step I reduced number of operations to:
1. "prepare for write", "copy";
2. "prepare for write", "erase";
3. "prepare for write", "copy";

Data in flash was also as expected after second `Copy RAM to flash'
operation. After a number of tests I figured out that only first `Copy
RAM to flash' gives wrong result. What may cause that?? Could it be
a problem with my system configuration? I use Keil uV3 + RealView
Compiler. In project settings I enabled the "ARM/thumb interworking"
flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
48MHz.

Did anyone hit similar problems?

Marcin Start a New Thread

I had similar problems. Try disabling MAM when you disable interrupts.

T

On 9/6/07, czesio_lpc wrote:
>
> Hello All,
>
> Recently I was trying to use IAP mechanism to write
> one selected flash sector. I prepared my IAP routine and tested it by
> reading out device ID. The result was correct. Next, I tried to write
> a
> flash sector with given pattern. In order to do that I disabled all
> system
> interrupts and prepared ram buffer (256 bytes long). The buffer was
> located in RAM at address 0x40006000. I filled in the buffer with
> desired content. Next I prepared sector to write (command 50(dec))
> after that I executed erase command (52(dec)). Flash sector was filled
> in with 0x00. For both returned status code was 0. After that I issued
> `prepare sector for write command' (50(dec)) again, and `Copy RAM
> to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> written with correct data.
> In next test I executed:
> 1. "prepare for write", "erase";
> 2. "prepare for write", "copy..";
> 3. "prepare for write", "erase";
> 4. "prepare for write", "copy";
> After second "`Copy RAM to flash' operation, data in flash appeared
> as expected.
> In next step I reduced number of operations to:
> 1. "prepare for write", "copy";
> 2. "prepare for write", "erase";
> 3. "prepare for write", "copy";
>
> Data in flash was also as expected after second `Copy RAM to flash'
> operation. After a number of tests I figured out that only first `Copy
> RAM to flash' gives wrong result. What may cause that?? Could it be
> a problem with my system configuration? I use Keil uV3 + RealView
> Compiler. In project settings I enabled the "ARM/thumb interworking"
> flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> 48MHz.
>
> Did anyone hit similar problems?
>
> Marcin
>


Start a New Thread

Hi,

how did you determine the correctness of the written data? Check the whole
256 - if only the first 32 byte are wrong you might be seeing the remapped
exception vectors from RAM. You could verify correctness of the written data
after mapping the flash back to 0x0.

Regards,

Dominic

On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> Hello All,
>
> Recently I was trying to use IAP mechanism to write
> one selected flash sector. I prepared my IAP routine and tested it by
> reading out device ID. The result was correct. Next, I tried to write
> a
> flash sector with given pattern. In order to do that I disabled all
> system
> interrupts and prepared ram buffer (256 bytes long). The buffer was
> located in RAM at address 0x40006000. I filled in the buffer with
> desired content. Next I prepared sector to write (command 50(dec))
> after that I executed erase command (52(dec)). Flash sector was filled
> in with 0x00. For both returned status code was 0. After that I issued
> `prepare sector for write command' (50(dec)) again, and `Copy RAM
> to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> written with correct data.
> In next test I executed:
> 1. "prepare for write", "erase";
> 2. "prepare for write", "copy..";
> 3. "prepare for write", "erase";
> 4. "prepare for write", "copy";
> After second "`Copy RAM to flash' operation, data in flash appeared
> as expected.
> In next step I reduced number of operations to:
> 1. "prepare for write", "copy";
> 2. "prepare for write", "erase";
> 3. "prepare for write", "copy";
>
> Data in flash was also as expected after second `Copy RAM to flash'
> operation. After a number of tests I figured out that only first `Copy
> RAM to flash' gives wrong result. What may cause that?? Could it be
> a problem with my system configuration? I use Keil uV3 + RealView
> Compiler. In project settings I enabled the "ARM/thumb interworking"
> flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> 48MHz.
>
> Did anyone hit similar problems?
>
> Marcin



Start a New Thread

Hi

I use IAP with exactly same chip/compiler setup as you have.

I never had a problem that you are describing, but I do not trust the debugger to view the flash memory in case of IAP routines. Use Flash Magic to view the memory - always very reliable.

After erase, sector should be 0xFF - not 0x00

Check the clock setting in IAP function arguments (last argument) - I set it to 12000 and it seems to work (still to work out if it is actually correct!)

I had problems with the same setup when Max JTAG clock was set to whatever it was set to by default. I reduced it to 100 KHz and most problems disappeared

Hope this helps.

Michael

Dominic Rath wrote:
Hi,

how did you determine the correctness of the written data? Check the whole
256 - if only the first 32 byte are wrong you might be seeing the remapped
exception vectors from RAM. You could verify correctness of the written data
after mapping the flash back to 0x0.

Regards,

Dominic

On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> Hello All,
>
> Recently I was trying to use IAP mechanism to write
> one selected flash sector. I prepared my IAP routine and tested it by
> reading out device ID. The result was correct. Next, I tried to write
> a
> flash sector with given pattern. In order to do that I disabled all
> system
> interrupts and prepared ram buffer (256 bytes long). The buffer was
> located in RAM at address 0x40006000. I filled in the buffer with
> desired content. Next I prepared sector to write (command 50(dec))
> after that I executed erase command (52(dec)). Flash sector was filled
> in with 0x00. For both returned status code was 0. After that I issued
> `prepare sector for write command' (50(dec)) again, and `Copy RAM
> to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> written with correct data.
> In next test I executed:
> 1. "prepare for write", "erase";
> 2. "prepare for write", "copy..";
> 3. "prepare for write", "erase";
> 4. "prepare for write", "copy";
> After second "`Copy RAM to flash' operation, data in flash appeared
> as expected.
> In next step I reduced number of operations to:
> 1. "prepare for write", "copy";
> 2. "prepare for write", "erase";
> 3. "prepare for write", "copy";
>
> Data in flash was also as expected after second `Copy RAM to flash'
> operation. After a number of tests I figured out that only first `Copy
> RAM to flash' gives wrong result. What may cause that?? Could it be
> a problem with my system configuration? I use Keil uV3 + RealView
> Compiler. In project settings I enabled the "ARM/thumb interworking"
> flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> 48MHz.
>
> Did anyone hit similar problems?
>
> Marcin

Yahoo! Groups Links Start a New Thread

Hello Again,

Thank you for suggestions. I went through all of them again.
Unfortunately I do not have any satisfying results.

I check the content of my flash with FlashMagic now.

The problem remains: IAP('erase' and 'copy ram to flash' commands)
starts to work correctly only after one dummy 'copy ram to flash'.

Marcin

--- In l..., Michael Melkonian
wrote:
>
> Hi
>
> I use IAP with exactly same chip/compiler setup as you have.
>
> I never had a problem that you are describing, but I do not trust
the debugger to view the flash memory in case of IAP routines. Use
Flash Magic to view the memory - always very reliable.
>
> After erase, sector should be 0xFF - not 0x00
>
> Check the clock setting in IAP function arguments (last
argument) - I set it to 12000 and it seems to work (still to work out
if it is actually correct!)
>
> I had problems with the same setup when Max JTAG clock was set to
whatever it was set to by default. I reduced it to 100 KHz and most
problems disappeared
>
> Hope this helps.
>
> Michael
>
> Dominic Rath wrote:
> Hi,
>
> how did you determine the correctness of the written data? Check
the whole
> 256 - if only the first 32 byte are wrong you might be seeing the
remapped
> exception vectors from RAM. You could verify correctness of the
written data
> after mapping the flash back to 0x0.
>
> Regards,
>
> Dominic
>
> On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> > Hello All,
> >
> > Recently I was trying to use IAP mechanism to write
> > one selected flash sector. I prepared my IAP routine and tested
it by
> > reading out device ID. The result was correct. Next, I tried to
write
> > a
> > flash sector with given pattern. In order to do that I disabled
all
> > system
> > interrupts and prepared ram buffer (256 bytes long). The buffer
was
> > located in RAM at address 0x40006000. I filled in the buffer with
> > desired content. Next I prepared sector to write (command 50(dec))
> > after that I executed erase command (52(dec)). Flash sector was
filled
> > in with 0x00. For both returned status code was 0. After that I
issued
> > `prepare sector for write command' (50(dec)) again, and `Copy RAM
> > to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> > written with correct data.
> > In next test I executed:
> > 1. "prepare for write", "erase";
> > 2. "prepare for write", "copy..";
> > 3. "prepare for write", "erase";
> > 4. "prepare for write", "copy";
> > After second "`Copy RAM to flash' operation, data in flash
appeared
> > as expected.
> > In next step I reduced number of operations to:
> > 1. "prepare for write", "copy";
> > 2. "prepare for write", "erase";
> > 3. "prepare for write", "copy";
> >
> > Data in flash was also as expected after second `Copy RAM to
flash'
> > operation. After a number of tests I figured out that only first
`Copy
> > RAM to flash' gives wrong result. What may cause that?? Could it
be
> > a problem with my system configuration? I use Keil uV3 + RealView
> > Compiler. In project settings I enabled the "ARM/thumb
interworking"
> > flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> > 48MHz.
> >
> > Did anyone hit similar problems?
> >
> > Marcin
>
> Yahoo! Groups Links
>
> Start a New Thread

--- In l..., Michael Melkonian
wrote:
>
> Hi
>
> I use IAP with exactly same chip/compiler setup as you have.
>
> I never had a problem that you are describing, but I do not trust
>the debugger to view the flash memory in case of IAP routines. Use
>Flash Magic to view the memory - always very reliable.
I was going to say something similar... Make sure, if using a JTAG
debugger, that it has actually re-read the flash. I've had the
problem (recently too) where it (IAR/JLINK) was giving me the
old pre-programmed results until I did something to re-read it.
At least that's what it seemed like. I hadn't re-programmed,
it just appeared correct next time I came back into the debugger.
boB

>
> After erase, sector should be 0xFF - not 0x00
>
> Check the clock setting in IAP function arguments (last argument)
- I set it to 12000 and it seems to work (still to work out if it is
actually correct!)
>
> I had problems with the same setup when Max JTAG clock was set to
whatever it was set to by default. I reduced it to 100 KHz and most
problems disappeared
>
> Hope this helps.
>
> Michael
>
> Dominic Rath wrote:
> Hi,
>
> how did you determine the correctness of the written data? Check the
whole
> 256 - if only the first 32 byte are wrong you might be seeing the
remapped
> exception vectors from RAM. You could verify correctness of the
written data
> after mapping the flash back to 0x0.
>
> Regards,
>
> Dominic
>
> On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> > Hello All,
> >
> > Recently I was trying to use IAP mechanism to write
> > one selected flash sector. I prepared my IAP routine and tested it by
> > reading out device ID. The result was correct. Next, I tried to write
> > a
> > flash sector with given pattern. In order to do that I disabled all
> > system
> > interrupts and prepared ram buffer (256 bytes long). The buffer was
> > located in RAM at address 0x40006000. I filled in the buffer with
> > desired content. Next I prepared sector to write (command 50(dec))
> > after that I executed erase command (52(dec)). Flash sector was filled
> > in with 0x00. For both returned status code was 0. After that I issued
> > `prepare sector for write command' (50(dec)) again, and `Copy RAM
> > to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> > written with correct data.
> > In next test I executed:
> > 1. "prepare for write", "erase";
> > 2. "prepare for write", "copy..";
> > 3. "prepare for write", "erase";
> > 4. "prepare for write", "copy";
> > After second "`Copy RAM to flash' operation, data in flash appeared
> > as expected.
> > In next step I reduced number of operations to:
> > 1. "prepare for write", "copy";
> > 2. "prepare for write", "erase";
> > 3. "prepare for write", "copy";
> >
> > Data in flash was also as expected after second `Copy RAM to flash'
> > operation. After a number of tests I figured out that only first `Copy
> > RAM to flash' gives wrong result. What may cause that?? Could it be
> > a problem with my system configuration? I use Keil uV3 + RealView
> > Compiler. In project settings I enabled the "ARM/thumb interworking"
> > flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> > 48MHz.
> >
> > Did anyone hit similar problems?
> >
> > Marcin
>
> Yahoo! Groups Links
>
> Start a New Thread

Hello Marcin

I will see if I can tidy up a routine that works happily and send it
to you. From memory (writing from home), I do:
Prepare flash
Erase
Prepare flash
Copy RAM to flash.

There is a small delay involved somewhere, e.g.
i = 200;
while (i--);

Or you can send me the code that doesn't work and I will see what I
can find.

Cheers

--- In l..., "czesio_lpc" wrote:
>
> Hello Again,
>
> Thank you for suggestions. I went through all of them again.
> Unfortunately I do not have any satisfying results.
>
> I check the content of my flash with FlashMagic now.
>
> The problem remains: IAP('erase' and 'copy ram to flash' commands)
> starts to work correctly only after one dummy 'copy ram to flash'.
>
> Marcin
>
> --- In l..., Michael Melkonian
> wrote:
> >
> > Hi
> >
> > I use IAP with exactly same chip/compiler setup as you have.
> >
> > I never had a problem that you are describing, but I do not trust
> the debugger to view the flash memory in case of IAP routines. Use
> Flash Magic to view the memory - always very reliable.
> >
> > After erase, sector should be 0xFF - not 0x00
> >
> > Check the clock setting in IAP function arguments (last
> argument) - I set it to 12000 and it seems to work (still to work out
> if it is actually correct!)
> >
> > I had problems with the same setup when Max JTAG clock was set to
> whatever it was set to by default. I reduced it to 100 KHz and most
> problems disappeared
> >
> > Hope this helps.
> >
> > Michael
> >
> > Dominic Rath wrote:
> > Hi,
> >
> > how did you determine the correctness of the written data? Check
> the whole
> > 256 - if only the first 32 byte are wrong you might be seeing the
> remapped
> > exception vectors from RAM. You could verify correctness of the
> written data
> > after mapping the flash back to 0x0.
> >
> > Regards,
> >
> > Dominic
> >
> > On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> > > Hello All,
> > >
> > > Recently I was trying to use IAP mechanism to write
> > > one selected flash sector. I prepared my IAP routine and tested
> it by
> > > reading out device ID. The result was correct. Next, I tried to
> write
> > > a
> > > flash sector with given pattern. In order to do that I disabled
> all
> > > system
> > > interrupts and prepared ram buffer (256 bytes long). The buffer
> was
> > > located in RAM at address 0x40006000. I filled in the buffer with
> > > desired content. Next I prepared sector to write (command 50(dec))
> > > after that I executed erase command (52(dec)). Flash sector was
> filled
> > > in with 0x00. For both returned status code was 0. After that I
> issued
> > > `prepare sector for write command' (50(dec)) again, and `Copy RAM
> > > to flash' (51(dec)) (with given RAM buffer) Flash sector was not
> > > written with correct data.
> > > In next test I executed:
> > > 1. "prepare for write", "erase";
> > > 2. "prepare for write", "copy..";
> > > 3. "prepare for write", "erase";
> > > 4. "prepare for write", "copy";
> > > After second "`Copy RAM to flash' operation, data in flash
> appeared
> > > as expected.
> > > In next step I reduced number of operations to:
> > > 1. "prepare for write", "copy";
> > > 2. "prepare for write", "erase";
> > > 3. "prepare for write", "copy";
> > >
> > > Data in flash was also as expected after second `Copy RAM to
> flash'
> > > operation. After a number of tests I figured out that only first
> `Copy
> > > RAM to flash' gives wrong result. What may cause that?? Could it
> be
> > > a problem with my system configuration? I use Keil uV3 + RealView
> > > Compiler. In project settings I enabled the "ARM/thumb
> interworking"
> > > flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> > > 48MHz.
> > >
> > > Did anyone hit similar problems?
> > >
> > > Marcin
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> Start a New Thread

Ok, here we go. This simplified routine is not fully tested, but it
does work on my system every time (clearly you cannot use it twice
in the row as it doesn't erase the sector). "ram" is a buffer of 256
bytes. May be this will help.

U32 FLASH_WriteToFlashSimple(char *data, U32 size)
{
U32 sector = 0x7C000;
U32 sector_number = 26; // set to sector 26
U32 i = 200; // delay
iap_entry=(IAP) IAP_LOCATION;

if (size > 256)
{
return IAP_STATUS_DST_ADDR_ERROR;
}

command[0] = IAP_PREPARE_SECTOR_FOR_WRITE; // prepare sector
for write from RAM or erase
command[1] = sector_number; // program sector 26
command[2] = sector_number;

// clear result memory - @todo - is this required?
memset(result, 0, 2);

// disable interrupts via VIC
disable_isr_vic();

// call IAP function
iap_entry (command, result);

while ((result[0] == IAP_STATUS_BUSY) && (i--));
if (result[0] == IAP_STATUS_SUCCESS)
{
memset(ram, 0, 256);
// zeroise the buffer
memcpy(ram, data, size);
// copy what was provided by the caller up to 256 bytes
command[0] = IAP_COPY_RAM_TO_FLASH; //
command
command[1] = sector;
// address in flash - beginning of the sector
command[2] = (U32)(&ram[0]); //
address in RAM
command[3] = 256;
// write bytes as required
//@todo - double check that the following clock data
is correct!
command[4] = 12000;
// system clock in KHz, Cclk == 12Mhz Pll

// clear result memory - @todo - is this required?
memset(result, 0, 2);
iap_entry (command, result); //
call IAP function
}

enable_isr_vic();

return result[0];
}
--- In l..., "michael_melkonian"
wrote:
>
> Hello Marcin
>
> I will see if I can tidy up a routine that works happily and send
it
> to you. From memory (writing from home), I do:
> Prepare flash
> Erase
> Prepare flash
> Copy RAM to flash.
>
> There is a small delay involved somewhere, e.g.
> i = 200;
> while (i--);
>
> Or you can send me the code that doesn't work and I will see what I
> can find.
>
> Cheers
>
> --- In l..., "czesio_lpc" wrote:
> >
> > Hello Again,
> >
> > Thank you for suggestions. I went through all of them again.
> > Unfortunately I do not have any satisfying results.
> >
> > I check the content of my flash with FlashMagic now.
> >
> > The problem remains: IAP('erase' and 'copy ram to flash'
commands)
> > starts to work correctly only after one dummy 'copy ram to
flash'.
> >
> > Marcin
> >
> > --- In l..., Michael Melkonian
> > wrote:
> > >
> > > Hi
> > >
> > > I use IAP with exactly same chip/compiler setup as you have.
> > >
> > > I never had a problem that you are describing, but I do not
trust
> > the debugger to view the flash memory in case of IAP routines.
Use
> > Flash Magic to view the memory - always very reliable.
> > >
> > > After erase, sector should be 0xFF - not 0x00
> > >
> > > Check the clock setting in IAP function arguments (last
> > argument) - I set it to 12000 and it seems to work (still to
work out
> > if it is actually correct!)
> > >
> > > I had problems with the same setup when Max JTAG clock was
set to
> > whatever it was set to by default. I reduced it to 100 KHz and
most
> > problems disappeared
> > >
> > > Hope this helps.
> > >
> > > Michael
> > >
> > > Dominic Rath wrote:
> > > Hi,
> > >
> > > how did you determine the correctness of the written data?
Check
> > the whole
> > > 256 - if only the first 32 byte are wrong you might be seeing
the
> > remapped
> > > exception vectors from RAM. You could verify correctness of
the
> > written data
> > > after mapping the flash back to 0x0.
> > >
> > > Regards,
> > >
> > > Dominic
> > >
> > > On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> > > > Hello All,
> > > >
> > > > Recently I was trying to use IAP mechanism to write
> > > > one selected flash sector. I prepared my IAP routine and
tested
> > it by
> > > > reading out device ID. The result was correct. Next, I tried
to
> > write
> > > > a
> > > > flash sector with given pattern. In order to do that I
disabled
> > all
> > > > system
> > > > interrupts and prepared ram buffer (256 bytes long). The
buffer
> > was
> > > > located in RAM at address 0x40006000. I filled in the buffer
with
> > > > desired content. Next I prepared sector to write (command 50
(dec))
> > > > after that I executed erase command (52(dec)). Flash sector
was
> > filled
> > > > in with 0x00. For both returned status code was 0. After
that I
> > issued
> > > > `prepare sector for write command' (50(dec)) again, and
`Copy RAM
> > > > to flash' (51(dec)) (with given RAM buffer) Flash sector was
not
> > > > written with correct data.
> > > > In next test I executed:
> > > > 1. "prepare for write", "erase";
> > > > 2. "prepare for write", "copy..";
> > > > 3. "prepare for write", "erase";
> > > > 4. "prepare for write", "copy";
> > > > After second "`Copy RAM to flash' operation, data in flash
> > appeared
> > > > as expected.
> > > > In next step I reduced number of operations to:
> > > > 1. "prepare for write", "copy";
> > > > 2. "prepare for write", "erase";
> > > > 3. "prepare for write", "copy";
> > > >
> > > > Data in flash was also as expected after second `Copy RAM to
> > flash'
> > > > operation. After a number of tests I figured out that only
first
> > `Copy
> > > > RAM to flash' gives wrong result. What may cause that??
Could it
> > be
> > > > a problem with my system configuration? I use Keil uV3 +
RealView
> > > > Compiler. In project settings I enabled the "ARM/thumb
> > interworking"
> > > > flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> > > > 48MHz.
> > > >
> > > > Did anyone hit similar problems?
> > > >
> > > > Marcin
> > >
> > >
> > >
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> Start a New Thread

Michael,

Thank you for your help. I've just found source of my problems. In
Erase flash command I did not pass the PCLK parameter.
As I described, the IAP was working fine after one dummy `Copy Ram to
flash'. In this dummy write the PCLK parameter was correct, however
its result was not correct because I didn't issue the erase command
before.

Anyway, now it works fine. Thanks once again.

Marcin

--- In l..., "michael_melkonian"
wrote:
>
> Ok, here we go. This simplified routine is not fully tested, but it
> does work on my system every time (clearly you cannot use it twice
> in the row as it doesn't erase the sector). "ram" is a buffer of
256
> bytes. May be this will help.
>
> U32 FLASH_WriteToFlashSimple(char *data, U32 size)
> {
> U32 sector = 0x7C000;
> U32 sector_number = 26; // set to sector 26
> U32 i = 200; // delay
> iap_entry=(IAP) IAP_LOCATION;
>
> if (size > 256)
> {
> return IAP_STATUS_DST_ADDR_ERROR;
> }
>
> command[0] = IAP_PREPARE_SECTOR_FOR_WRITE; // prepare sector
> for write from RAM or erase
> command[1] = sector_number; // program sector 26
> command[2] = sector_number;
>
> // clear result memory - @todo - is this required?
> memset(result, 0, 2);
>
> // disable interrupts via VIC
> disable_isr_vic();
>
> // call IAP function
> iap_entry (command, result);
>
> while ((result[0] == IAP_STATUS_BUSY) && (i--));
> if (result[0] == IAP_STATUS_SUCCESS)
> {
> memset(ram, 0, 256);
> // zeroise the buffer
> memcpy(ram, data, size);
> // copy what was provided by the caller up to 256 bytes
> command[0] = IAP_COPY_RAM_TO_FLASH; //
> command
> command[1] = sector;
> // address in flash - beginning of the sector
> command[2] = (U32)(&ram[0]); //
> address in RAM
> command[3] = 256;
> // write bytes as required
> //@todo - double check that the following clock data
> is correct!
> command[4] = 12000;
> // system clock in KHz, Cclk == 12Mhz Pll
>
> // clear result memory - @todo - is this required?
> memset(result, 0, 2);
> iap_entry (command, result); //
> call IAP function
> }
>
> enable_isr_vic();
>
> return result[0];
> }
> --- In l..., "michael_melkonian"
> wrote:
> >
> > Hello Marcin
> >
> > I will see if I can tidy up a routine that works happily and send
> it
> > to you. From memory (writing from home), I do:
> > Prepare flash
> > Erase
> > Prepare flash
> > Copy RAM to flash.
> >
> > There is a small delay involved somewhere, e.g.
> > i = 200;
> > while (i--);
> >
> > Or you can send me the code that doesn't work and I will see what
I
> > can find.
> >
> > Cheers
> >
> > --- In l..., "czesio_lpc" wrote:
> > >
> > > Hello Again,
> > >
> > > Thank you for suggestions. I went through all of them again.
> > > Unfortunately I do not have any satisfying results.
> > >
> > > I check the content of my flash with FlashMagic now.
> > >
> > > The problem remains: IAP('erase' and 'copy ram to flash'
> commands)
> > > starts to work correctly only after one dummy 'copy ram to
> flash'.
> > >
> > > Marcin
> > >
> > > --- In l..., Michael Melkonian
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > I use IAP with exactly same chip/compiler setup as you
have.
> > > >
> > > > I never had a problem that you are describing, but I do not
> trust
> > > the debugger to view the flash memory in case of IAP routines.
> Use
> > > Flash Magic to view the memory - always very reliable.
> > > >
> > > > After erase, sector should be 0xFF - not 0x00
> > > >
> > > > Check the clock setting in IAP function arguments (last
> > > argument) - I set it to 12000 and it seems to work (still to
> work out
> > > if it is actually correct!)
> > > >
> > > > I had problems with the same setup when Max JTAG clock was
> set to
> > > whatever it was set to by default. I reduced it to 100 KHz and
> most
> > > problems disappeared
> > > >
> > > > Hope this helps.
> > > >
> > > > Michael
> > > >
> > > > Dominic Rath wrote:
> > > > Hi,
> > > >
> > > > how did you determine the correctness of the written data?
> Check
> > > the whole
> > > > 256 - if only the first 32 byte are wrong you might be seeing
> the
> > > remapped
> > > > exception vectors from RAM. You could verify correctness of
> the
> > > written data
> > > > after mapping the flash back to 0x0.
> > > >
> > > > Regards,
> > > >
> > > > Dominic
> > > >
> > > > On Friday 07 September 2007 08:43:00 czesio_lpc wrote:
> > > > > Hello All,
> > > > >
> > > > > Recently I was trying to use IAP mechanism to write
> > > > > one selected flash sector. I prepared my IAP routine and
> tested
> > > it by
> > > > > reading out device ID. The result was correct. Next, I
tried
> to
> > > write
> > > > > a
> > > > > flash sector with given pattern. In order to do that I
> disabled
> > > all
> > > > > system
> > > > > interrupts and prepared ram buffer (256 bytes long). The
> buffer
> > > was
> > > > > located in RAM at address 0x40006000. I filled in the
buffer
> with
> > > > > desired content. Next I prepared sector to write (command 50
> (dec))
> > > > > after that I executed erase command (52(dec)). Flash sector
> was
> > > filled
> > > > > in with 0x00. For both returned status code was 0. After
> that I
> > > issued
> > > > > `prepare sector for write command' (50(dec)) again, and
> `Copy RAM
> > > > > to flash' (51(dec)) (with given RAM buffer) Flash sector
was
> not
> > > > > written with correct data.
> > > > > In next test I executed:
> > > > > 1. "prepare for write", "erase";
> > > > > 2. "prepare for write", "copy..";
> > > > > 3. "prepare for write", "erase";
> > > > > 4. "prepare for write", "copy";
> > > > > After second "`Copy RAM to flash' operation, data in flash
> > > appeared
> > > > > as expected.
> > > > > In next step I reduced number of operations to:
> > > > > 1. "prepare for write", "copy";
> > > > > 2. "prepare for write", "erase";
> > > > > 3. "prepare for write", "copy";
> > > > >
> > > > > Data in flash was also as expected after second `Copy RAM
to
> > > flash'
> > > > > operation. After a number of tests I figured out that only
> first
> > > `Copy
> > > > > RAM to flash' gives wrong result. What may cause that??
> Could it
> > > be
> > > > > a problem with my system configuration? I use Keil uV3 +
> RealView
> > > > > Compiler. In project settings I enabled the "ARM/thumb
> > > interworking"
> > > > > flag. For debugging I use Keil's uLink2 JTAG probe. CCLK is
> > > > > 48MHz.
> > > > >
> > > > > Did anyone hit similar problems?
> > > > >
> > > > > Marcin
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> Start a New Thread