Build log:ADC example project HardFault exeception in LPCXpresso v5.1.2_2065

[lpcware]

Content originally posted in LPCWare by cakehuang on Thu Apr 11 05:06:32 MST 2013
Please check the log!

[lpcware]

Content originally posted in LPCWare by cakehuang on Tue Apr 16 05:45:38 MST 2013

---

Quote: whitecoe
As CodeRedSupport has already told you, there are lots of earlier examples here. Search for "thumb_func", or "assembler" or "asm". For example the below thread, and the ones it links to should help further...

http://knowledgebase.nxp.com/showthread.php?t=674

Anyway, what you need is something like...

     .global MasterReceive
     .thumb
     .thumb_func
 MasterReceive:
     PUSH    {r4,r5,r6,r7,lr}

Also, be aware that you really should be pushing pairs of registers to the stack to ensure that 8 byte alignment of the stack is preserved.

HTH!

---

Thank you.
It is working now under v5.1(v4.3 does not have this problem)
I also push one more register(r3) into stack to keep the stack boundary as 8 byte alignment.

Thank you all again for helping out.

[lpcware]

Content originally posted in LPCWare by whitecoe on Tue Apr 16 04:13:32 MST 2013
As CodeRedSupport has already told you, there are lots of earlier examples here. Search for "thumb_func", or "assembler" or "asm". For example the below thread, and the ones it links to should help further...

http://knowledgebase.nxp.com/showthread.php?t=674

Anyway, what you need is something like...

     .global MasterReceive
     .thumb
     .thumb_func
 MasterReceive:
     PUSH    {r4,r5,r6,r7,lr}

Also, be aware that you really should be pushing pairs of registers to the stack to ensure that 8 byte alignment of the stack is preserved.

HTH!

[lpcware]

Content originally posted in LPCWare by cakehuang on Tue Apr 16 03:53:13 MST 2013

---

Quote: cakehuang
It is working under vesion 5.1 after replacing the original linkscript file with the new one that you sent me.
Thank you so much for your help.
And please help to check my modified SSP example project to see what is causing the blx instruction. I searced in this forum for assembler example and found one. I tried to add ".thumb" in file of sspmasterread.s. But this does not help.
In this test case, I use SPI master to read. I wrote a funtion called "MasterReceive" in that asm file. Then I declared that function in c file and then call it. What I saw is the compiler produce this function call as "blx 0x***". I double checked the build log and found both c compiler and assembler select right core as m0.

---

Sorry that I fogot to attach this testing projectl

[lpcware]

Content originally posted in LPCWare by cakehuang on Tue Apr 16 03:36:59 MST 2013
It is working under vesion 5.1 after replacing the original linkscript file with the new one that you sent me.
Thank you so much for your help.
And please help to check my modified SSP example project to see what is causing the blx instruction. I searced in this forum for assembler example and found one. I tried to add ".thumb" in file of sspmasterread.s. But this does not help.
In this test case, I use SPI master to read. I wrote a funtion called "MasterReceive" in that asm file. Then I declared that function in c file and then call it. What I saw is the compiler produce this function call as "blx 0x***". I double checked the build log and found both c compiler and assembler select right core as m0.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Sat Apr 13 12:14:57 MST 2013

---

Quote: cakehuang
Thanks for your response.
Please check the attached zip file of this ADC example project. It contains the ADC and small_printf lib. In folder named " debug", you will find the axf and map.
[B]Please be noted that this example is OK under ver4.3 but both ver5.0 and v5.1 have this problem.[/B]

---

OK, I can see what is triggering your issue with this adc example. The example set this was taken from was produced by NXP some considerable time ago, and for some reason uses linker scripts that NXP produced, rather than the managed linker script mechanism that LPCXpresso projects would normally use.

The linker script is failing to pad one of its sections out to a 4 byte alignment, and a block of constant data is being pulled in from the small_printf project that the adc example uses that is not a multiple of 4 bytes is size. This is then causing a hiccup with the programming of your image into flash.

The flash programming issue does not occur with the a current internal build of the next LPCXpresso release (due later this month). But in the meantime, the attached linker script contains a small modification to ensure 4 byte alignment is preserved in your image - which should allow you to flash your image using LPCXpresso v5.1.2

To use this, simple extract the file from the zip file and place it into the 'linker' folder within the adc project. Then do a clean, followed by a full build.

---

Quote:

As what I had said that I had another hardware fault which is caused by "blx 0x****h". The destination address is a function that I wrote in assembly code. I just declared it as an extern function in C file. Then the compiler would produce this "blx 0x****h". Unfortunately, m0 does not have this branch instruction. The core selected by compiler/linker is indeed m0. But aganin, ver4.3 does not have this problem.

---

I would need to see a buildable example to confirm, but I suspect that you have not declared your assembler function as a 'thumb_func'. Search the forum for earlier threads containing assembler examples.

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by cakehuang on Fri Apr 12 20:37:25 MST 2013

---

Quote: frame
Well, I'm not much into assembler programming, but ARM lists a B.W instruction
[B]only[/B] for the M3, and not for the M0 (M0+).
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

While the offset seems to be in range, the op code might indeed be invalid for the M0.
That would be a case for for the CodeRed support then.

But as a workaround, you can use a well scaled integer calculation instead...

BTW, in case of a stack overflow, something else (like data) usually
gets interpreted as instruction, and thus causing hardfaults.

---

Yes, integer is of course an alternative.
And for the case you mentioned that the core try to interpret data as an instruction. Normally this happens when returning address inside the stack gets corrupted due to stack overfollow. Next after trying to return, PC would be replaced by some data value. PC might point to invalid address or  valid RAM space. Then it is possible to produce fault. In my case, what I saw is that PC is still inisde the flash space.

[lpcware]

Content originally posted in LPCWare by cakehuang on Fri Apr 12 20:16:03 MST 2013

---

Quote: CodeRedSupport
I've just tried building NXP's LPC11xx adc example project, and can't see any obvious issues with it that could be causing your fault.

Please can you post:

1) The axf file that you are debugging

2) the map file created when you built that axf

3) If possible, the actual project - main application project and any associated library projects - that you are building...

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

Regards,
CodeRedSupport

---

Thanks for your response.
Please check the attached zip file of this ADC example project. It contains the ADC and small_printf lib. In folder named " debug", you will find the axf and map.
[B]Please be noted that this example is OK under ver4.3 but both ver5.0 and v5.1 have this problem.[/B]

As what I had said that I had another hardware fault which is caused by "blx 0x****h". The destination address is a function that I wrote in assembly code. I just declared it as an extern function in C file. Then the compiler would produce this "blx 0x****h". Unfortunately, m0 does not have this branch instruction. The core selected by compiler/linker is indeed m0. But aganin, ver4.3 does not have this problem.

As you can see, I have three version installed on my PC but each in different folder/driver. I don't think installing path will produce this issue.
I had this issue for more than one month. Since then I had to work under ver4.3. But ver5.1 has some advance like it takes less time to build or lauch the debugger. That is why I would like to switch to ver5.1.

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Fri Apr 12 07:01:26 MST 2013
I've just tried building NXP's LPC11xx adc example project, and can't see any obvious issues with it that could be causing your fault.

Please can you post:

1) The axf file that you are debugging

2) the map file created when you built that axf

3) If possible, the actual project - main application project and any associated library projects - that you are building...

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

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by frame on Fri Apr 12 06:07:03 MST 2013

---

Quote:
3, I did not check the stack carefully. What I saw is that  "b.w 0x1e24"  is causing hardwarefault
This branch instruction will not consume any  more stack usage.

---

Well, I'm not much into assembler programming, but ARM lists a B.W instruction
[B]only[/B] for the M3, and not for the M0 (M0+).
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0432c/CHDCICDF.html

While the offset seems to be in range, the op code might indeed be invalid for the M0.
That would be a case for for the CodeRed support then.

But as a workaround, you can use a well scaled integer calculation instead...

BTW, in case of a stack overflow, something else (like data) usually
gets interpreted as instruction, and thus causing hardfaults.

[lpcware]

Content originally posted in LPCWare by cakehuang on Fri Apr 12 04:31:09 MST 2013

---

Quote: frame
Fine, but actually, that doesn't help much. The C code does not give new hints toward the reason.

The assembler instruction at the vicinity of the hardfault is interesting.
[FONT=Courier New]printf [/FONT]uses [B]huge [/B]amounts of stack, even [FONT=Courier New]small_printf[/FONT] consumes considerably.
Did you check the stack at this time ?
What keeps you from starting up your debugger ?

And, BTW, you don't need floating point (even [FONT=Courier New]double[/FONT]) at this point. This simple scaling
can as well be done in integer. Double calculations are a waste of performance,
it will take about 10 .. 50 times as long as using integer.

---

1, Please check the attached picture. First one is just before brance to library.Second one is just before hardware fault happen. If that instruction gets executed, hardfault occurs.
2, Before hardware fault, no printf ever gets exectued.
3, I did not check the stack carefully. What I saw is that  "b.w 0x1e24" is causing hardwarefault. This branch instruction will not consume any more stack usage.
4, If I use ver4, everything is OK. But since ver5 has great update, I would like to switch to this new version.
5, I am using adc to measure a signal ranging from 0v to 1.8v. Althrough I can avoid using floating point library in my real project like by using integer, I still want to use floating point which is more straight forward. And performance is OK as I am measuring PWM signal which has several kHz. 

6, In my real project, I had another hardware fault which is something like " blx 0xxxxxxxxx". This is disassembly code inside the debugger. But user manual of cortex m0 shows there is only "blx Rm" which means blx can only use register as destination address. This is also puzzling me a lot.

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Fri Apr 12 04:02:24 MST 2013
Don't forget that Cortex-M0 and Cortex-M3 do not have floating point hardware and therefore all floating point operations have to be emulated in software. This is implemented in function calls that will use more stack space.

Note also that Cortex-M4 has single-precision floating point hardware, so [B]float[/B] will execute in hardware, but [B]double[/B] will be emulated in software.

Emulating floating point in software is very much slower than doing it in hardware.

[lpcware]

Content originally posted in LPCWare by frame on Fri Apr 12 03:38:09 MST 2013

---

Quote:
double ValueVolts = Counts*SUPPLY_VOLTAGE/ADC_COUNT_MAX;

---

Fine, but actually, that doesn't help much. The C code does not give new hints toward the reason.

The assembler instruction at the vicinity of the hardfault is interesting.
[FONT=Courier New]printf [/FONT]uses [B]huge [/B]amounts of stack, even [FONT=Courier New]small_printf[/FONT] consumes considerably.
Did you check the stack at this time ?
What keeps you from starting up your debugger ?

And, BTW, you don't need floating point (even [FONT=Courier New]double[/FONT]) at this point. This simple scaling
can as well be done in integer. Double calculations are a waste of performance,
it will take about 10 .. 50 times as long as using integer.

[lpcware]

Content originally posted in LPCWare by cakehuang on Fri Apr 12 03:18:48 MST 2013
It is below bold line caused this issue. This is inside the library.
I did not change anything of this ADC example.

void ADCBar(int32_t Channel, uint32_t Counts)
{
uint32_t ValueBarLen = ((Counts * (MAX_BAR_LENGTH+1)) - (ADC_COUNT_MAX/2 - 1)) / ADC_COUNT_MAX;
char ValueBarBuf[BAR_OUTPUT_LENGTH+1];
[B][I]double ValueVolts = Counts*SUPPLY_VOLTAGE/ADC_COUNT_MAX;[/I][/B]

[lpcware]

Content originally posted in LPCWare by frame on Thu Apr 11 23:44:54 MST 2013

---

Quote:
Please check the log for lib_small_printf_m0.a

---

As developer, you should be able to do this yourself.

However, this build log seems ok, as -[FONT=Courier New]mcpu=cortex-m0[/FONT] is present.
You just have to make sure that the result of this build is the actual library you link against.
You wouldn't be the first one to be fooled by different lib versions in different folders.

There is still the possibility of a stack overflow.
You should be able to check the stackpointer against the limit while single-stepping into
and through the offending function.

[lpcware]

Content originally posted in LPCWare by cakehuang on Thu Apr 11 19:59:51 MST 2013
Please check the log for lib_small_printf_m0.a

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Thu Apr 11 06:00:17 MST 2013
Given that you said the error occurs in lib_small_printf_m0, you should be posting the build log for that...