Skip to main content
ybenharim10
Associate III
August 29, 2009
Question

J-Link error

Posted on August 29, 2009 at 23:43

J-Link error

    This topic has been closed for replies.

    26 replies

    jj_it
    Associate II
    May 17, 2011
    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...

    jj_it
    Associate II
    May 17, 2011
    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...

    ybenharim10
    Associate III
    May 17, 2011
    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, ..''

    ybenharim10
    Associate III
    May 17, 2011
    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 III
    May 17, 2011
    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 III
    May 17, 2011
    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...

    jilisegiar
    Associate III
    May 17, 2011
    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

    jj_it
    Associate II
    May 17, 2011
    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 ]

    ybenharim10
    Associate III
    May 17, 2011
    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_it
    Associate II
    May 17, 2011
    Posted on May 17, 2011 at 12:59

    Sorry to be a pest - suspect that others share (or will in future) my concern.

    Assume that the ''bad'' program altered the JTAG pin/pins. I do ''not'' understand ''how'' then - changing the boot from flash to ram (so that you can load a new, ''correct'' program)- *** BY ITSELF *** restores the JTAG functionality. Believe that you use the JLink (JTAG debug probe) to load the STM32's ram with your new program - but HOW can this work if the JTAG pins are ''out'' of JTAG mode??? (I can see this working if you loaded the new program by Uart or any NON-JTAG method - was this what you did?)