Questions and issues regarding Flash IAP on LPC11C14

[lpcware]

Content originally posted in LPCWare by amrbekhit on Sat Oct 23 15:35:26 MST 2010
Hello all,

I've been using the IAP routines on the LPC11C14 and have some questions regarding its operation.

- According to the user manual, the IAP routines use the top 32 bytes of RAM. By "top" do they mean they use RAM locations 0x1000 1FE0 to 0x1000 1FFF, or do they mean 0x1000 0000 to 0x1000 001F?
- I have previously been using the IAP routines without any delays and have found that sometimes when calling the routines in quick succession, the processor will completely crash. I have since found that the erase time is 100ms and write time is 1ms. Adding a 1ms delay after a "Copy RAM To Flash" has solved the problem, but interestingly enough, no delay was needed after an erase. However, I was wondering whether the IAP routines provide any mechanism to determine whether they are busy or not? According to the user manual, the IAP routines can return BUSY (11), but I have never managed to get any of the IAP routines to return busy. I'd much rather use that rather than a delay.
- Even with the delays in place, I could still cause the processor to crash if I was overwriting the same 256-byte block without erasing between writes. What I was doing was initially erasing the sector, then filling a 256-byte RAM buffer with 0xFF, copying my data to the correct location and then writing the whole buffer. I would end up overwriting the same 256 byte block 32 times before I move onto the next block. However, if I fill my buffer entirely and then write it once, it all works fine. Why is this? I was under the impression that writing 0xFF to erased bytes is equivalent to doing nothing.

Thanks

--Amr

[lpcware]

Content originally posted in LPCWare by amrbekhit on Wed Oct 27 03:08:07 MST 2010
Right, I believe my crashing problems have been solved - I didn't disable interrupts during the flash routines. Disabling interrupts solves this problem and I am now no longer getting freezes.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Oct 26 00:43:21 MST 2010

---

Quote: amrbekhit
@CodeRedSupport: I'm actually using the Keil compiler, which places the initial stack pointer at the top of the allocated RAM (e.g. if you are using 0x400 bytes of RAM and have a stack of size 0x100, the initial stack pointer would be at address RAM_BASE + 0x500). However, the setting you are describing seems to imply that LPCXpresso places the initial stack pointer right at the uppermost address in RAM, which for the LPC11C14 would be 0x1000 1FFF. Is that correct?

---

Well as this is the LPCXpresso forum, the default expectation is that you are using the LPCXPresso tools ! ;)

With the LPCXpresso tools, the stack is indeed set by default to the top of RAM. As the MCU uses a full descending stack, the initial value it is set to is actually going to be 0x1000 2000, but the first stack location written to will actually be 0x1000 1FFC.

The linker option I referred to in my previous post allows you to offset the initial stack location from the default at the top of RAM, whilst still using the default managed linker script mechanism. But if required, it is quite possible to locate the stack elsewhere if required by switching off the managed linker script mechanism and using your own linker scripts.

Regards,
CodeRedSupport.

[lpcware]

Content originally posted in LPCWare by amrbekhit on Mon Oct 25 11:59:06 MST 2010
Thanks for the useful information everyone.

@domen: Thanks for the clarification. I am using the same procedure as you are on the LPC23xx.

@CodeRedSupport: I'm actually using the Keil compiler, which places the initial stack pointer at the top of the allocated RAM (e.g. if you are using 0x400 bytes of RAM and have a stack of size 0x100, the initial stack pointer would be at address RAM_BASE + 0x500). However, the setting you are describing seems to imply that LPCXpresso places the initial stack pointer right at the uppermost address in RAM, which for the LPC11C14 would be 0x1000 1FFF. Is that correct?

@kendwyer: I guess I'll just have to write individual 256 bytes blocks.

I've done a little bit more testing and I've found that the IAP_ERASE_SECTOR doesn't need a delay as the function itself takes approximately 100ms to complete. However, writing 256 bytes to flash through IAP_COPY_RAM_TO_FLASH only took a few microseconds, which I'm guessing is simply the execution time of the function call rather than the time of the erase, since the LPC11C14 datasheet states that the write time for a 256 byte block is 1ms. That explains why I never needed to have a delay after the erase function but needed one after the write. Has anyone managed to receive a BUSY result from IAP_COPY_RAM_TO_FLASH? Am I obliged to use a delay?

--Amr

[lpcware]

Content originally posted in LPCWare by kendwyer on Mon Oct 25 10:56:06 MST 2010
Hi
[I]
Even with the delays in place, I could still cause the processor to  crash if I was overwriting the same 256-byte block without erasing  between writes. What I was doing was initially erasing the sector, then  filling a 256-byte RAM buffer with 0xFF, copying my data to the correct  location and then writing the whole buffer. I would end up overwriting  the same 256 byte block 32 times before I move onto the next block.  However, if I fill my buffer entirely and then write it once, it all  works fine. Why is this? I was under the impression that writing 0xFF to  erased bytes is equivalent to doing nothing.[/I]

The Flash CRC will not be correct if the flash is programmed in that manner.

Ken

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Oct 25 00:48:43 MST 2010
If you need to reserve the top 32 bytes of the RAM for the IAP, you can do this by going to:

Project -> Properties -> C/C++ Build -> Settings -> MCU C Linker -> Target

and putting "32" into the Stack offset entry. This will then move the start of the stack down by 32 bytes as required. [Note that the value you put in this field should be a multiple of 8 bytes, to ensure the 8 byte stack alignment assumed by the ARM EABI.]

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by domen on Sun Oct 24 23:14:54 MST 2010
You couldn't just include some code with this? :P

Top 32 bytes means 32-bytes with highest address. Also watch out for stack it needs, and that those don't overlap (stack is usually configured on top!).

What's your prodecure?
Looking at some lpc23xx code, I use IAP_PREPARE_SECTOR, IAP_ERASE_SECTOR, IAP_PREPARE_SECTOR, IAP_COPY_RAM_TO_FLASH sequence