Friday, April 20th 2018, 1:02am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Asinus

Beginner

Date of registration: Apr 28th 2013

Posts: 5

1

Wednesday, February 12th 2014, 9:38pm

JLink Edu broken? Possibility for testing the device?

Is there a possibility to test an jlink edu to test for malfunction?

I've been using the jlink edu since months and it was really great. But suddenly the device failed: all programms I wrote got stuck in the hardfault handler of the controller. Stepping throug the code, I noticed, that the odyssey begins after the init in the startup code.
Nothing went wrong with the hardware, from one day to an other I couldn't debug anymore.

System is:

Win7/32
emIDE 2.14
STM32F103RB Olimex H103 Evalboard (but this error occurs on other boards too)
jlink V4.80f

Can anybody help?

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

2

Thursday, February 13th 2014, 11:21am

Hi,

I do not really think that your EDU is broken...
If it can communicate with the device and even program the flash, J-Link is working fine.
Do you have another board around for testing?

Quoted

Stepping throug the code, I noticed, that the odyssey begins after the init in the startup code.

Another hint that it has nothing to do with the EDU hardware...

Are you sure that you changed nothing on the target-application side?


Best regards
Alex

Asinus

Beginner

Date of registration: Apr 28th 2013

Posts: 5

3

Thursday, February 13th 2014, 11:52pm

Hi Alex,
"

Quoted

I do not really think that your EDU is broken...

If it can communicate with the device and even program the flash, J-Link is working fine.
That sounds good...

Quoted

Do you have another board around for testing?
Yes, I have two other boards and I tried them before too (in case the proc would be defective..). But the failure was reproducible.

Quoted

Are you sure that you changed nothing on the target-application side?
Hmm, sure I did changes in the source code, but nothing in the linker file or setups.

Finally I tried a new installation of the toolchain, but this made the same results :(

Kai

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

4

Friday, February 14th 2014, 1:37pm

Hi,

Could you send a sample project for the STM32F103 which can be used to reproduce the problem you are seeing?


- Alex

Asinus

Beginner

Date of registration: Apr 28th 2013

Posts: 5

5

Sunday, February 16th 2014, 3:20pm

Hi Alex,
see attached file. It is the basic setup for a simple datalogger.

Strange was, that, as I setup a new very simple project, it works, so the debugger istn't really not defective, it seems to me.
But loading any existing project, it turns on from start... ;(
So there must be a bug in the source or settings, but I really have no idea, where to have a a look for. And on the other side, all those projects worked well till last weekend.. then they stopped working all at one time.

Regards
Asinus has attached the following file:
  • FS_Test.zip (601.84 kB - 327 times downloaded - Last download: Yesterday, 8:58am)

Asinus

Beginner

Date of registration: Apr 28th 2013

Posts: 5

6

Monday, February 17th 2014, 12:05pm

... and the jlink edu IS defective... ;( ;( ;(

a friend of mine work's with the "big" jlink's and he tested it in his enviroment... though he don't touch the hard fault handler, the debugger don't respond anymore there.
He'll lend me his this evening to crosscheck, if it would work again.....

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

7

Monday, February 17th 2014, 4:06pm

Hi,

I gave your project a quick try and also end up in the HardFault handler.
So, is my J-Link also defective? I do not think so....

Why don't you debug this problem? Because this is what J-Link is for...

I have put a "return" into the HardFault handler and set a breakpoint on it.
Now I Let the target hit the breakpoint and leave the HardFault handler by instruction-stepping out of it via Alt + F11.
Now I see that the application crashed in

C/C++ Source code

1
void xvprintf ()


The exact place within xvprintf() where it crashes differs from session to session, but usually it is a

C/C++ Source code

1
*fmt++


So, I am still pretty confident that not J-Link is the problem here, but your application code.
I give no guarantee that the problem is really caused by the xvprintf() since the stack may already be overwritten and so messed up, when the HardFault handler is entered, that a proper call-stack may not be shown properly.
Take a simple project that does nothing except a generic Cortex-M3 startup + incrementing a counter in main() and I promise you:
You will not get into the HardFault() handler.

Quoted

see attached file. It is the basic setup for a simple datalogger.

Are you kidding me? This is anything but not a simple project.
It contains a "filesystem", complete SystemInit, printfs, ...
There are multiple, possible error sources.


Best regards
Alex

Asinus

Beginner

Date of registration: Apr 28th 2013

Posts: 5

8

Monday, February 17th 2014, 11:11pm

Hello Alex,
thanks for the hint... but it seemed strange to me, that projects which worked fine all time long, suddenly didn't anymore.

Quoted

Take a simple project that does nothing except a generic Cortex-M3 startup + incrementing a counter in main() and I promise you:

You will not get into the HardFault() handler.
That was, what I wrote above, and yes, you're right, I didn't ran into the fault handler... but anything more could chuck me out, and I really don't know, what... sometimes only a simple memset call can ran the target out into wilderness. So the thought was really a hardware defect.

Sorry for wasting your time.

SEGGER - Alex

Super Moderator

Date of registration: Dec 18th 2007

Posts: 1,516

9

Tuesday, February 18th 2014, 8:32am

Hi,

My suggestions:
Initialize the RAM with a test value before running through any low-level init etc.
If you get to the HardFault handler, check the RAM contents if they give any hint that an array near the stack was written out of its boundaries and overwrote stack contents etc.
Strip down the project until it works, then take in part by part to check when it stops working.


- Alex