2009-08-29 02:43 PM
J-Link error
2011-05-17 03:59 AM
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...2011-05-17 03:59 AM
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).2011-05-17 03:59 AM
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, ..''2011-05-17 03:59 AM
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...2011-05-17 03:59 AM
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\GettingStarted2011-05-17 03:59 AM
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.2011-05-17 03:59 AM
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\IOToggle2011-05-17 03:59 AM
OK, I boot from RAM and run the IOToggle example.
But I still can't connect to flash from J-Flash...2011-05-17 03:59 AM
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!2011-05-17 03:59 AM
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 ]