Writing to Flash in SuperPRO, PROplus

[basicchip]

>from the Yahoo Forum

I've attempted to write flash using the command
Write(address,A,256)
per the Basic documentation

Using a small test program, address = &H3000 to &H7000 works OK (return error code = 0), but address &H8000 and above fails (return error code = -5 ????). The Basic memory map documentation states that the 4K segments between &H3000 through &HF000 are available for write.

Further, when using &H7000 in my destination Basic program (approx 17K code, 3K data), the program faults with the message

FautSR 0xFFFFFFF9 SCB->CFSR=0x00008200

This is my first post to the group and sure would appreciate some help. Thanks!

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

The symptoms you describe are consistent with a PROplus. Are you sure you have a SuperPRO? The boards share the same base PCB, but have different parts loaded. And the Welcome message it shows when you start up BASICtools.

The PROplus Flash memory stops at &H8000 so writes past that will fail.

The available memory for program is 20K, so if you write to &H7000 you are overwriting the last part of your compiled code, so dropping into a Fault condition is not unexpected.

[basicchip]

PS Its possible you may have converted to floating point and installed the PROplus firmware (I know it will run, not so sure what writing to Flash through BASIC does with that).

The definitive way to ID any NXP CPU is with the IDnxp program we wrote and handles all the parts we've seen. That program is run by the Options->Connection menu item which runs that test.

The LPC1751 is used in the PROplus and the LPC1756 is in the SuperPRO

[rhilbish]

Thanks for the reply!!
I checked and my board has an LPC1756 chip, so I'm sure it's a SuperPRO. I ran into the memory limit problem you describe for the 1751 using a PRO board (LPC2103) which is the reason I upgraded to the SuperPRO. And you're right - the symptoms seem to be similar. I have not intentally installed any other firmware - I'm using the board as delivered with the latest download of ARMBasic. I truly don't understand what my problem is - everything else so far works fine and writing to flash would seem to be a straight forward process. Are there any subtitles that are not necessarily clear in the ARMBasic Programming Guide?

[rhilbish]

More info: I just tried a new SuperPRO board and got the same results. Here's precisely what I did.
(1) Started Basictools and got the message

"Welcome to ARMbasic kernel [8.15] with Floating Point for SuperPRO"

(2) Loaded my test program and got

"Programming Flash 1756
ARMBasic [8.16d] on the PC
*+*+
..(0.46Kcode + 0.1K string)96K 1.03/9K data programmed"

My test program simply allows me to enter a seed number, loads multiples of the number to 16 elements of an array (dim A(256) as integer), writes A to flash using the statement
ECode = Write(address,A,256),
prints the resultant write ECode, reads and prints A.

I ran my test program for a range of segment addresses. For addresses &H3000 to &H7000, everything worked fine (ECode = 0, results in A are correct). For &H8000, I got an ECode
of 0 (OK??) but A contained all -1 values. For &H9000 and above, I got ECode = -1 (??) and A contained -1 values. Incidentally, I also tried &H28000 which is also stated as being
available and got ECode = 256 and -1 values in A.

The Basic Programmers Guide in the memory section states for the SuperPRO that the memory between &H3000 .. &H10000 "These 4K blocks may be used by WRITE command". Any
ideas what I might be doing wrong? You noted some question about floating point and PROplus. Could my version of ARMBasic which apparently includes floating point use some
memory not documented?

Would really appreciate any suggestions. I'm at a standstill.

[basicchip]

I just ran a quick check and yes we had a problem with the sector map that affects writes to 0x9000 thru 0xffff

There was also a check to disable writes above 0x10000 to keep people from over-writing their code. Which I will disable, if people want to overwrite their code and blow up their program, well that's OK now.

With a trial version of firmware, this program works

Code: Select all

dim a(64)
for i=24 to 31		' also tested for 4 to 15
	a(0)=i
	write(i*&H1000,a,256)
next i
for i=24 to 31
	print *(i*&H1000)
next i

rhilbish contact me and I'll get a firmware upgrade in the next day or so (takes a bit to set it up and I'm actually on vacation this week).

[rhilbish]

Thanks so much for resolving on my problem, and sorry for interrupting your vacation! This certainly explains what I’ve seen.

The memory map in the ARMBasic Programmers Guide shows memory between &H1000 to &H21000 (&H28000??) as reserved for the users program and strings. At least from my viewpoint, I don’t see the need to open this up for potential overwrite, but of course I’ll defer to you on that. I assume that blocks above &H28000 would be as shown in the guide.

Please let me know what I need to do re the firmware upgrade and again thanks.

[rhilbish]

Oops - in my reply I meant &10000 to &H21000, not &H1000. Sorry.

[basicchip]

Actually its the SuperPRO where code is written starting at 0x10000, and those blocks are 32K, so the first available block is at 0x18000.

[basicchip]

Bruce

I found my problem, but don't understand why.

If you equate the return value from write as an integer, ie, b, then

dim a(256) as integer
dim b as integer

b = write(&Hxxx,a,256)

works. However, if you equate the return value to an element of an array, ie, b(0)

dim a(256) as integer
dim b(10) as integer

b(0) = write(&Hxxx,a,256)

the program stops. Compilier problem? Misunderstanding on my part?

Bob

[basicchip]

Yes this was a compiler bug, the index register used for the array offset is being used to pass a value to the WRITE routine. So this version of the compiler fixes that problem, it will become part of the standard release in the next week or so.