cancel
Showing results for 
Search instead for 
Did you mean: 

J-Link error

ybenharim10
Associate II
Posted on August 29, 2009 at 23:43

J-Link error

26 REPLIES 26
jj
Associate II
Posted on May 17, 2011 at 12:59

After you report to jilisegiar I suggest that you switch to your ''good'' Eval Bd and download & flash the simplest program possible via your JLink. Confirm that this works properly.

Then replace the ''good'' eval bd with the ''suspect'' one - and repeat the identical procedure. (you should be storing the program into Flash - do NOT employ any ''special/Ram'' methods) This will either work or generate the same - or perhaps new error messages. Believe this will lend the most light and ''speed'' your correction of this issue. Let us know -s'il vous plait...

ybenharim10
Associate II
Posted on May 17, 2011 at 12:59

I am not at work, so I can't give percise answers.

I think when I run JLinkARM_V402 I get command line prompt - I will check it when I get back.

Both boards now have the same problem (beware - infection).

ybenharim10
Associate II
Posted on May 17, 2011 at 12:59

OK I checked - when I run the J-Link command line, I get the command line with the same error message ''Wrong ROM table component id,...''

When I run J-Flash and choose erase chip menu, I get ''Wrong ROM table component id, ..''

jj
Associate II
Posted on May 17, 2011 at 12:59

jilisegiar seems strongest in this area - I've been lucky enough to never have encountered this (fairly cryptic) error.

So:

a) search IAR - email their tech support - seek detailed explanation

b) now 2 boards have the problem! Have you measured/scoped the power on your boards? I have that board and can't cause that problem.

c) that eval board has many jumpers. Is it possible that a jumper has

been moved/removed? (maybe by someone else)

d) has your code altered (by attempting to ''reclaim'') any of the JTAG pins? I always advise clients NOT to change the JTAG functionality ''without'' - very early in their code - including a JTAG/GPIO switch-over routine. You can read an input pin during the first second of board boot - if switch is active you switch GPIO to JTAG.

e) perhaps a long-shot - believe this eval board includes a pull-down on the JTAG clock. (and that STM32 ''also'' has an internal pull-down) This may compromise the signal level as seen at the uC. I would scope all of the JTAG pins - starting with the clock.

Wish I really knew - hope this helps - please keep us posted to ''save'' others...

jilisegiar
Associate II
Posted on May 17, 2011 at 12:59

Your problem can be solved if you can boot from RAM which is not possible with the IAR STM32-SK board.

I suggest the following workaround which may fix your problem:

1.Press the hardware reset button

2.Run the Jlink.exe utility.

--> if the problem persists try to keep the hardware reset button pressed and try again step2. Else go to step 3.

3. Try to load a working example:[IAR directory installation]\ARM\examples\ST\STM32F10x\IAR-STM32-SK\GettingStarted

ybenharim10
Associate II
Posted on May 17, 2011 at 12:59

It seems that you are right.

Previously I tried to run from RAM by only changing the linking configuration (icf) file.

I now changed the boot solder bridges located on the evaluation board near the ARM processor. soldering B0_1 and B1_1 on my board results with '1' input to the stm32's boot0 and boot1 pins.

I now can run from RAM with debugger, but I can't override the bad flash code, even when I try to Erase chip with Segger's J-Flash utility I get error dialog box:

J-Flash ARM V4.02 Error

Could not find any flash devices. Fail to connect. Could not erase chip, not connected.

jilisegiar
Associate II
Posted on May 17, 2011 at 12:59

Ok Now try to boot from RAM then load the following example:

[IAR directory installation]\ARM\examples\ST\STM32F10x\STM32-Eval\STM32F10xFWLib\FWLib\examples\GPIO\IOToggle

ybenharim10
Associate II
Posted on May 17, 2011 at 12:59

OK, I boot from RAM and run the IOToggle example.

But I still can't connect to flash from J-Flash...

ybenharim10
Associate II
Posted on May 17, 2011 at 12:59

The problem is solved!

The solution stage:

1. change board solder bridges to boot from RAM (boot0/boot1 pins = '1')

2. get J-link license - I don't know if this is necessary)

3. run j-link ARM and open processor's stm32f103B project

4. choose menu: Erase chip

5. return solder bridges to original configuration (boot0='0')

Thanks you for your comments!

jj
Associate II
Posted on May 17, 2011 at 12:59

Thanks for ''closing the loop'' for us. Unexplained is why/how your 2nd board worked for awhile - before it too became unresponsive.

Thank you jilisegiar - many will now know what to do in a similar situation. Forgive me - I'm unclear if - and then ''why'' - placing a program into RAM was required to ''erase'' the flash. Was this caused by an errant program which ''killed'' a clock/osc - or altered the JTAG? Thanks for any final light you can shed...

[ This message was edited by: jj.sprague on 20-01-2009 00:40 ]