LPC11U14 flash area bug!?

[lpcware]

Content originally posted in LPCWare by vostro1000 on Tue Jan 17 08:50:26 MST 2012
Hi! I've been working with lcxpresso 11U14 board but I think I found out a silicon bug :(

I have one part of code written... All runs fine etc... But if I change some variables on my program and try to( debug/write) the executable on lpc the debugger stuck it shows on status at the bottom :

[Download] Page 0 at (00000000/00000400) 1024 bytes

after target configuration process on the download process (and keep on a looping with this values and the debugger act led keeps flashing) till I disconect the usb cable( repower the system) and start the debug/run secton again :mad::mad:.
The codes runs fine but I need all the time to disconect and conect again the board!( For sure I quit debug section before start a new one)
But here come a interesting fact! I'am runnig with no optmisation selected!
But after with I select for the build to have optimisation -O1 this problem is gone I suspect it skip or don't write code on this certain flash area so all start to work fine! No need re-power and etc.. I don't know the next bytes that program grows if it will fail to write on this chip area again.

I alredy tested this several times and the problem apear only on the first scenario!
I alredy tried to full erase chip/page but the problem with first scenario still on!
Any help from nxp support guys!?

[lpcware]

Content originally posted in LPCWare by vostro1000 on Thu Jan 19 05:41:48 MST 2012

---

Quote: Zero
Thought I've done this already :rolleyes:

If I debug you code (Optimization -O0) disassembly shows something like:

48                              LPC_TMR16B0->TCR ^= 0x03;        /* start timer */
00000366: main+102               ldr r3, [pc, #76]       ; (0x3b4 <main+180>)
00000368: main+104               ldr r2, [pc, #72]       ; (0x3b4 <main+180>)
0000036a: main+106               ldr r2, [r2, #4]
0000036c: main+108               movs r1, #3
0000036e: main+110               eors r2, r1
00000370: main+112               str r2, [r3, #4]

Looks like innocent reading, XORing and writing back the new value Unfortunately reading bit 2-31 can result in undefined values :mad:
And writing back this value to reserved TCR bits can result in what? We don't know, NXP is just warning us. Wouldn't be the first time that writing some forbidden bits is activating something and your code is failing. Therefore I call this code risky :eek:

User manual:

---

Oh! Thanks for the tip! Now it's clear! But... This is not a cause of my problem anyway!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Wed Jan 18 13:25:02 MST 2012

---

Quote:
Can you explain me...

---

Thought I've done this already :rolleyes:

---

Quote:
If you debug my code you will see that after ''LPC_CT16B0->TCR ^= 0x03;" The value of TCR will be 1 so what's wrong with that?

---

If I debug you code (Optimization -O0) disassembly shows something like:

48                              LPC_TMR16B0->TCR ^= 0x03;        /* start timer */
00000366: main+102               ldr r3, [pc, #76]       ; (0x3b4 <main+180>)
00000368: main+104               ldr r2, [pc, #72]       ; (0x3b4 <main+180>)
0000036a: main+106               ldr r2, [r2, #4]
0000036c: main+108               movs r1, #3
0000036e: main+110               eors r2, r1
00000370: main+112               str r2, [r3, #4]

Looks like innocent reading, XORing and writing back the new value Unfortunately reading bit 2-31 can result in undefined values :mad:
And writing back this value to reserved TCR bits can result in what? We don't know, NXP is just warning us. Wouldn't be the first time that writing some forbidden bits is activating something and your code is failing. Therefore I call this code risky :eek:

User manual:

---

Quote:

31:2 - Reserved, user software should not write ones to reserved bits.
The value read from a reserved bit is not defined.

---

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 09:52:28 MST 2012

---

Quote: Zero
Sample:

 LPC_CT16B0->TCR ^= 0x03;        /* start timer */

You think you are reading this register and toggling 2 bits? Wrong :eek:

User manual:
So you know what you are doing? Then please inform the manufacturer that this warnings are useless and it's not necessary to scare people like me :rolleyes:
Otherwise avoid to touch this bits or you can get funny effects. Compiler optimization can save you again if it's optimizing out this risky parts of your code

---

Man take easy!
If you debug my code you will see that after ''LPC_CT16B0->TCR ^= 0x03;" The value of TCR will be 1 so what's wrong with that?? Can you explain me because if you care look at the code you see that I put TCR |=0x02 and the value still in the register until you change it isn't!?

The operation of  x^=a is equal  x = x ^ a isn't? this a bit-bit operator isn't?

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Wed Jan 18 09:23:30 MST 2012

---

Quote: vostro1000
#2 You will get trouble with that if you don't know what you are doing I always use this and it's fine for me and it's not useless

---

Sample:

 LPC_CT16B0->TCR ^= 0x03;        /* start timer */

You think you are reading this register and toggling 2 bits? Wrong :eek:

User manual:

---

Quote:

14.7.3 Timer Counter
The 16-bit Timer Counter is incremented when the Prescale Counter reaches its t
Table 229. Timer Control Register (TCR, address 0x4000 C004 (CT16B0) and 0x4001 0004
(CT16B1)) bit description
Bit Symbol Value Description Reset
value
0 CEN Counter enable. 0
0 The counters are disabled.
1 The Timer Counter and Prescale Counter are enabled for
counting.
1 CRST Counter reset. 0
0 Do nothing.
1 The Timer Counter and the Prescale Counter are
synchronously reset on the next positive edge of PCLK. The
counters remain reset until TCR[1] is returned to zero.
31:2
- Reserved, user software should not write ones to reserved bits.
The value read from a reserved bit is not defined.

---

So you know what you are doing? Then please inform the manufacturer that this warnings are useless and it's not necessary to scare people like me :rolleyes:
Otherwise avoid to touch this bits or you can get funny effects. Compiler optimization can save you again if it's optimizing out this risky parts of your code

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 09:20:50 MST 2012

---

Quote: CodeRedSupport
Thank you for the project files. These now build fine.

However I don't see any problems loading the project intothe debugger. I have tried changing the value of the parameters being passed to the PWM() function between builds, as suggested in the caprock.c in the workspace that you sent.

Next step would probably be to provide more details of exactly how to replicate the problem, plus provide a copy of the debug log from when you get the load failure as previously requested - I gave a pointer to an FAQ on to how to obtain this.

Also, out of interest, if you import the projects that you sent in new.zip into a fresh workspace, can you still replicate the problem?

Regards,
CodeRedSupport

---

Today I cannot replicate the problem... But as you can see from logs a lot of erros happens. It's a trick bug :cool:

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 18 09:01:24 MST 2012
Thank you for the project files. These now build fine.

However I don't see any problems loading the project intothe debugger. I have tried changing the value of the parameters being passed to the PWM() function between builds, as suggested in the caprock.c in the workspace that you sent.

Next step would probably be to provide more details of exactly how to replicate the problem, plus provide a copy of the debug log from when you get the load failure as previously requested -  I gave a pointer to an FAQ on to how to obtain this.

Also, out of interest, if you import the projects that you sent in new.zip into a fresh workspace, can you still replicate the problem?

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 08:34:21 MST 2012

---

Quote: Zero
Your code is including a lot of useless things:

#1 You don't need to set PWM outputs as GPIO outputs, that's nonsense.

#2 Your PWM Init is including a lot of |= and ^= :eek: Why are you doing that? If possible, set a value and don't AND it. Otherwise you are risking problems :rolleyes:

---

#1 OK! I will remove that"
#2 You will get trouble with that if you don't know what you are doing :) I always use this and it's fine for me and it's not useless :)

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 08:29:52 MST 2012
So check out this one!

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Wed Jan 18 07:25:31 MST 2012
Your code is including a lot of useless things:

#1 You don't need to set PWM outputs as GPIO outputs, that's nonsense.

#2 Your PWM Init is including a lot of |=  and ^=  :eek: Why are you doing that? If possible, set a value and don't AND it. Otherwise you are risking problems :rolleyes:

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Jan 18 07:19:18 MST 2012

---

Quote: vostro1000
Here you are full workspace from version 4.1.5 in that incude the all logs :) Instructions to replicate the problem are inside capmeter.c

---

There are reasons why I explicitly asked for zipped exported projects rather than  a zipped workspace.  The following FAQ explains how to export....

http://support.code-red-tech.com/CodeRedWiki/ImportExport

And as supplied your project does not build either :(

If you would please be kind enough to provide [B][I]exactly[/I][/B] what we asked for previously, then we will look into the issue you are seeing.

And please make sure the project builds too :D

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 07:05:51 MST 2012
Hi! I will attach .log from V 4.1.0 too maybe it helps also the workspace is the same...

[lpcware]

Content originally posted in LPCWare by vostro1000 on Wed Jan 18 06:36:01 MST 2012
Here you are full workspace from version 4.1.5 in that incude the all logs :) Instructions to replicate the problem are inside capmeter.c

Many thanks for your help!

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Jan 17 15:06:09 MST 2012
Please can you attach to this thread (zipped if necessary).

1) The debug log from a failing download

  [INDENT]http://support.code-red-tech.com/CodeRedWiki/DebugLog[/INDENT]

2) The map file generated by the linker for an image that fails to download. You can find this file in the Debug (or Release) subdirectory of your project.

3) If possible, an actual buildable project, together with instructions on how to replicate. Please use the Export option in the Quickstart panel to output a zip file containing your project.

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by vostro1000 on Tue Jan 17 14:38:07 MST 2012
Hi! I'am using the latest version 4.1.5 in past I was at 4.1 and the same erro happens :(

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Tue Jan 17 13:29:09 MST 2012
What version of LPCXpresso are you using?

This sounds like a rare issue with LPC11/12/13 flash programming failing with a near identical image already in flash, which was fixed in version 4.0.6.

Regards,
CodeRedSupport