Senior

Solved

BLE_SensorDEMO built in TrueSTUDIO is not working on idb007v1

Forum|Forum|8 years ago
February 16, 2018
13 replies
4400 views

Posted on February 16, 2018 at 20:28

Hi,

I'm trying to run an example program - BLE_Sensor DEMO - built from sources.

I am using TrueSTUDIO for STM32 (v.9.0.0). The sources are from BlueNRG-1.2_DK_2.6.0 kit.

Unfortunatelly, when I download the image, the board does nothing: no led blinking, no BLE communication.

However, when I download prebuilt image (from Firmware folder in the development kit) it works fine.

What I am doing wrong?

Kind regards,

Piotr

Low Power RF Solutions

This topic has been closed for replies.

Best answer by Piotr Romaniuk

Posted on February 20, 2018 at 22:37

TrueSTUDIO project from ST DevKit has missing architecture option:

-mcpu=cortex-m0

Without that linked libc contains instructions in ARM mode (but it should be only Thumb - because it is Cortex-M0).

That is why HardFault Exception occured.

How to fix it

The option should be added in:

Project Properties | C/C++ Build |Settings, tab Tool Settings

for each group:

Assembler, C Compiler, C Linker

in Miscellaneouos |Other options field.

Andrew Neil

Super User

Posted on February 20, 2018 at 10:26

when I download the image, the board does nothing

It's almost certainly doing something - so connect the debugger, and find out what it's doing!

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Piotr RomaniukAuthor

Senior

Posted on February 20, 2018 at 11:03

Hi Andrew,

I did, but debugging from TrueStudio, does not work either!

Please read my question:

https://community.st.com/0D50X00009Xkht2SAB

I expected that reference design from ST should work, but not to be debugged.

My configuration constains:

- the board from ST,

- TrueSTUDIO (ST recommended as one of the IDE)

- development kit from ST (library and TrueStudio project)

- jtag/programmer from ST

Regards,

Piotr

Andrew Neil

Super User

Posted on February 20, 2018 at 11:09

romaniuk.piotr wrote:

I did, but debugging from TrueStudio, does not work either!

Please read my question:

https://community.st.com/0D50X00009Xkht2SAB

Would have been helpful to include that in the OP, then.

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Piotr RomaniukAuthor

Senior

Posted on February 20, 2018 at 11:12

OP? What does it mean?

Andrew Neil

Super User

Posted on February 20, 2018 at 11:27

'Original Post', or 'Opening Post'

Also used as 'Original Poster', or 'Opening Poster'

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Piotr RomaniukAuthor

Senior

Posted on February 20, 2018 at 15:21

Closer look to program execution show that it does not return to main() from BlueNRG_Stack_Initialization().

Inside the function HardFault exception is generated.

Here is a stack trace:

[...]

main()

BlueNRG_Stack_Initialization

BlueNRG_Stack_Perform_Crystal_Check

BlueNRG_Stack_Initialize_Layers

PM_init

exception in __aeabi_fdiv() => HardFaultHandler

pc = 10041722 HardFault Handler

msp = 0x2000.5f98

2000.5f98 36 R0 <- msp points here

2000.5f9c 0 R1

2000.5fa0 0350.0000 R2

2000.5fa4 0000.6c00 R3

2000.5fa8 0000.0018 R12

2000.5fac 1004.705f LR - would return to PM_init

2000.5fb0 1004.08d8 in __aeabi_fdiv <--- exception location

2000.5fb4 0100.0000

2000.5fb8 2000.094c

2000.5fbc 2000.08d4

2000.5fc0 2000.094c

2000.5fc4 1004.1dc1 in BlueNRG_Stack_Initialize_Layers

2000.5fc8 2000.094c

2000.5fcc 0000.0040

2000.5fd0 0000.0001

2000.5fd4 1004.1feb in BlueNRG_Stack_Perform_Crystal_Check

2000.5fd8 2000.2604

2000.5fdc 0

2000.5fe0 0

2000.5fe4 ffff.ffff

2000.5fe8 ffff.ffff

2000.5fec 1004.1d51 in BlueNRG_Stack_Initialization

2000.5ff0 1004.b580

2000.5ff4 1004.17bb

2000.5ff8 1004.b580

2000.5ffc 1004.14fd

Andrew Neil

Super User

Posted on February 20, 2018 at 16:00

romaniuk.piotr wrote:

exception in __aeabi_fdiv() => HardFaultHandler

Sounds like something to do with Floating Point - so check your FP setup.

Trying to do hardware FP on a chip with no FP HW probably would give a Hard Fault ...

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Piotr RomaniukAuthor

Senior

Posted on February 20, 2018 at 16:32

Unfortunatelly not. I still cannot debug from TrueSTUDIO IDE.

Above data is from BlueNRG-ST-Link Utility. This tool has very limitted functionality, but enough for getting ARM core register and RAM contents.

I have taken function names from a listing generated by the linker.

Andrew Neil

Super User

Posted on February 20, 2018 at 17:18

Oh - that's a pain.

Have you tried on the Atollic forum?

Have you tried raising a case with ST?

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.

Piotr RomaniukAuthor

Senior

Posted on February 20, 2018 at 17:22

Yes I post the issue on Atollic forum, but not yet to ST.

Piotr RomaniukAuthorAnswer

Senior

Posted on February 20, 2018 at 22:37

TrueSTUDIO project from ST DevKit has missing architecture option:

-mcpu=cortex-m0

Without that linked libc contains instructions in ARM mode (but it should be only Thumb - because it is Cortex-M0).

That is why HardFault Exception occured.

How to fix it

The option should be added in:

Project Properties | C/C++ Build |Settings, tab Tool Settings

for each group:

Assembler, C Compiler, C Linker

in Miscellaneouos |Other options field.

jaylong

Associate II

Posted on June 15, 2018 at 21:17

I'm new to TrueStudio and am having trouble updating the -mcpu=cortex-m0 option...

In all cases the ''All Options:'' field is grayed out and I'm unable to modify the contents (see attached screenshot). Any ideas on how to get around this?

Thanks!

jay

Piotr RomaniukAuthor

Senior

Posted on June 15, 2018 at 21:32

Hi,

please select Miscellaneous subgroup in Assembler group, then white architecture option in Other options field.

The same, by analogy, for C and linker.

Regards,

Piotr

jaylong

Associate II

Posted on June 16, 2018 at 01:08

Thanks Piotr,

Just as a note to others still experiencing issues, I didn't have to modify the linker options, it was already configured correctly for me, this can be verified by looking at the 'All options:' field in the 'C Linker' submenu. Trying to add it a second time under the 'Other options' lead to build errors.

However, omitting this still didn't result in a working binary, it would compile fine but wouldn't execute properly. I additionally had to change the Assembler/C compiler/C linker->Target->'instruction set' from 'Thumb2' to 'Thumb'.

After these two changes I was able to compile, flash, and run the st examples.

jay

Piotr RomaniukAuthor

Senior

Posted on June 16, 2018 at 10:16

Hi Jay,

I am surprised that programs were not working with Thumb2 setting. According to ST documentation BlueNRG chips are Cortex-M0, and from ARM Cortex-M0 Technical Reference Manual (rev. r0p0) DDI0432C p.28:

'The implemented device provides:

• A low gate count processor that features:

— The ARMv6-M Thumb® instruction set.

— Thumb-2 technology

[...]'

I saw in gray options field is still -mthumb althrough I set Thumb2 in target instruction set.

Is there any change in options when you switch from thumb2 to thumb?

Please verify in build console window, comparing the contents for both builds.

Regards,

Piotr

jaylong

Associate II

Posted on June 20, 2018 at 19:39

Hi Piotr,

I'm sorry, you're right. There was no thumb vs thumb2 issue, there must have been some other problem with my previous configuration.

jay

Robert Scholz

Visitor II

Posted on June 21, 2018 at 10:06

Hi Piotr,

Thanks for the link.

I still have problem to build a running image for BLUENRG-1

I added -mcpu=cortex-m0 option to Assembler

In case of C-Compiler, -mcpu=cortex-m0 was already set.

In case of Linker I can not add -mcpu. I will get following error:

unrecognised emulation mode: cpu=cortex-m0 BLE_SensorDemo_BlueMSapp C/C++ Problem

Here my Linker Options:

-Wl,-cref,-u,-Xlinker,--defsym=ST_LINKER_OPTION=1,-mcpu=cortex-m0

What is wrong?

I'm using following example:

STMicroelectronics\BlueNRG-1_2 DK 2.6.0\Project\BLE_Examples\BLE_SensorDemo_BlueMSapp

TrueStudio 9.0.0

Thanks!

jaylong

Associate II

Posted on June 21, 2018 at 18:31

Hi Robert,

This is the same problem I was having. I found that -mcpu=cortex-m0 was already set in the

''All options:'' field in the ''C Linker'' submenu. If you add it a second time using the

''C Linker''->''Miscellaneous''->

''Other options:'' field, it leads to build errors.

Double check the ''All Options:'' field, see attached screenshot showing the -mcpu=cortex-m0 highlighted and already set. If it shows up here, you shouldn't need to add it using the Miscellaneous submenu.

jay

Robert Scholz

Visitor II

Posted on June 22, 2018 at 08:42

Hi Jay,

Thanks for screenshot. I think you have a BLUENRG-2 project, or? Can you build working SW for BLUENRG-1?

Here my linker options:

-mthumb -T'..\BlueNRG1.ld' -specs=nosys.specs -nostartfiles -nodefaultlibs -static -L..\..\..\..\..\..\Library\Bluetooth_LE\library -L'..' -Wl,-cref,-u,-Xlinker,--defsym=ST_LINKER_OPTION=1 '-Wl,-Map=${BuildArtifactFileBaseName}.map' -Wl,--gc-sections -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group

-mcpu is not included.

Is this the reason why the SW does not start/crash on BLUENRG-1?

Regards,

Robert

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded